feat(protocol): proof verification aggregation #17938
Conversation
feat(protocol): proof verification aggregation
🚨 Report Summary
For more details view the full report in OpenZeppelin Code Inspector |
| // Size is: 89 bytes | ||
| // 4 bytes + 20 bytes + 65 bytes (signature) = 89 | ||
| if (_proof.data.length != 89) revert SGX_INVALID_PROOF(); | ||
| // 4 bytes + 20 bytes + 20 bytes + 65 bytes (signature) = 109 |
There was a problem hiding this comment.
Since the current SGX prover doesn't support multiple blocks, can we ensure the length of _ctx and _tran are both 1 for now so we can upgrade contracts ealier?
There was a problem hiding this comment.
The inputs into the verification are still changed so a bit tricky. If length is 1 we could use the old verification path, but then this would be a special case and proof aggregation on a single proof would not be valid. Seems easier if aggregation is always used even if there's only a single proof, otherwise we need multiple verification paths.
| } | ||
|
|
||
| IVerifier(verifier).verifyProof(ctxs, trans, proof); |
There was a problem hiding this comment.
I have a compilation error, due to this outter verifyProof(), the verifier variable is not know. It is coming from the tier configuration itself (now, in our current design).
And also this yields into another problem, with an example:
The block tiers (and hence the tier verifiers) can be for example:
block nr. 102: SGX only
block nr. 103: SGX+RISC0
block nr. 104: SGX+SP1
block nr. 105: SGX only again
And thus, the verifier contract address itself differs from block to block. so aggregating multiple, continuous blocks and verify with one go, will only work (in the current design at least!) if we have the exact same logic (contract) to verify (so same tiers), otherwise no.
There was a problem hiding this comment.
I think you can only aggregate proofs for the same tier together, but the proofs may correspond to blocks that are not consecutive.
There was a problem hiding this comment.
Yes, but then with ever 500-100th zk tier blocks in practice it will be useful for tee only. (At least for now.)
There was a problem hiding this comment.
I think I have now added the required checks to make sure only the same proofs can be aggregrated.
|
Is this aggregation between zk proofs(r0, sp1) inside Raiko? Or it’s mean compatibility with proof aggregation layers? |
It is aggregation of the same proof types within raiko (so a batch of SP1 proofs OR a batch of SGX proofs OR ...) |
|
Ok I will leave it here 🫡 |
| _ctx[i].metaHash, | ||
| taikoChainId() | ||
| ); | ||
| emit ProofVerified(_ctx[i].metaHash, public_inputs[i + 1]); |
There was a problem hiding this comment.
Technically true only but:
- this is the only way to emit events per transition (one by one) since we are going thru the aggregated proofs.
- if something fails, the TXN reverted anyways
There was a problem hiding this comment.
Assumption indeed that all the proofs are verified correctly in some way afterwards.
| // Collect public inputs | ||
| bytes32[] memory public_inputs = new bytes32[](_ctx.length + 1); | ||
| // First public input is the current instance public key | ||
| public_inputs[0] = bytes32(bytes20(oldInstance)); |
There was a problem hiding this comment.
Is this necessary? I mean as oldInstance is always recovered from signature, why we need explicit list oldInstance here?
There was a problem hiding this comment.
We need to have it available in the aggregation proof, because that's the address we need to verify against for the first block proof. We need to get it from somewhere to be able to correctly verify that proof, because we don't have it available anymore in the SGX instance itself (could be many blocks ago, and we only store the latest key pair in SGX).
|
This PR is stale because it has been open for 45 days with no activity. |
Proof aggregation minimizes the onchain costs for proof verification, which is very important for zk proof verfication. Without aggregation the onchain costs would be very expensive, with proof aggregation we mostly only pay the offchain proof generation cost which is already pretty cheap.
Currently this PR just outlines one easy way to get proof aggregation working with minimal changes.
raiko PR: taikoxyz/raiko#347