-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing components in instance commitments #17
Comments
@willemolding do we also need finalizedHeaderRoot to be exposed by rotation circuit? |
Gas cost analysisGeneral references
Instance commitment in rotation circuitWe use instance commitment to reduce the number of public inputs of a given circuit, which is proportional to a number of To further reduce the number of actual public inputs, we compose them into a single big integer via Given this rationale, we are presented with a choice to whether use this technique in a
Calculations
ConclusionOption (B) seems cheaper. The cost of zero bytes makes a significant difference, otherwise, option (A) would've been cheaper. This cost can potentially be omitted if verifier contract generation is tweaked, by changing a certain range of pubInputs to be Note, Telepathy does not perform instance commitment for rotation circuit, ie. they use option (A). Their verifier contract also used Instance commitment truncationAs explained earlier, truncation allows to only expose of a single instance, thereby having a single Calculations
ConclusionTruncation makes sense, duh. Onion hashing vs. Input concatenationIn zkLightClientStep function Succinct Labs chooses to do "onion" (chained) hashing instead of a single sha256 hashing over concated inputs. Following is the calculation to understand their reasoning. Given that SHA256 (precompile 0x02): For a single operation in option (a) - For ( n-1 ) operations in option (b) - For Codebytes32 attestedSlotLE = SSZ.toLittleEndian(update.attestedSlot); // 8 non-zero bytes, 24 zero bytes
bytes32 finalizedSlotLE = SSZ.toLittleEndian(update.finalizedSlot); // 8 non-zero bytes, 24 zero bytes
bytes32 participationLE = SSZ.toLittleEndian(update.participation); // 8 non-zero bytes, 24 zero bytes
uint256 currentPeriod = getSyncCommitteePeriod(update.attestedSlot); // 8 non-zero bytes, 24 zero bytes
bytes32 syncCommitteePoseidon = syncCommitteePoseidons[currentPeriod]; // 32 non-zero bytes
bytes32 h;
h = sha256(bytes.concat(attestedSlotLE, finalizedSlotLE));
h = sha256(bytes.concat(h, update.finalizedHeaderRoot));
h = sha256(bytes.concat(h, participationLE));
h = sha256(bytes.concat(h, update.executionStateRoot)); // 32 non-zerobytes
h = sha256(bytes.concat(h, syncCommitteePoseidon)); Calculation
Conclusion
Also note, that option (a) is mildly cheaper in the circuit. Optimisation ideaWe don't need to use zero-padded 32 bytes for uint64 values (attestedSlot, finalizedSlot, participation) as it is up to us how to commit to public inputs. It doesn't have to use SSZ-chunked inputs. Thus, if we are hashing without zero-bytes - 96 < 152 - option (a) |
I actually don't know the answer to this. I think it depends on exactly what the rotation circuit is doing. If it is only proving the equivalence of a SSZ and Poseidon root then no.. but then we somehow need to link that root to a finalized header which could be done by doing a short SSZ proof in the contract. My feeling is that this would probably be more expensive so we do want to include the finalizedHeaderRoot as input and do that proof inside the rotation circuit right? |
Yes, it's best to outsource as much computation to the rotation circuit since its proofs will be posted infrequently and we are doing proof compression anyway i.e. inner circuit where committee update logic is done can be increased significantly without increasing verifier work. Will add that in the |
At the contract/verifier level the only way to know the inputs that statements are being proven about is through the instance commitments.
For integrating with a smart contract this means a contract function takes inputs and hashes these down to an instance commitment. The result of the verification then informs the contract about the relationships between these inputs.
I think that some input constraints are missing from the circuits that prevent the contract from being able to verify what it needs to for the protocol to work.
Rotation Circuit
The instance commitment is currently just a single poseidon commitment to a set of sync committee keys. I think this needs to be hashed with an SSZ root of the committee keys to allow the contract to verify that the two are equivalent. See the following example in telepathy:
SyncStep Circuit
This one seems pretty good but I think this is missing the commitment to the beacon block root. I see the code is there but commented out. Without this it is impossible to link the result of a rotation with the result of a step and so the protocol cannot move forward.
The text was updated successfully, but these errors were encountered: