You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/nf_4.md
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -682,3 +682,14 @@ Withdraws the stake of a de-registered proposer, actually, the amount withdrawn
682
682
## Production deployment
683
683
684
684
TBD once environment is confirmed
685
+
686
+
## Appendix
687
+
688
+
### Note on `VerifierKey.sol`
689
+
690
+
There is a VerificationKey.sol contract in blockchain_assets/contracts i.e. the normal place for a Solidity contract. This contract's job is to put the verification key into memory, which it does via assembly code, directly placing the values into memory locations. This is to support the RollupVerifier contract, which also uses assembly code that expects to find a key in particular locations. VerificationKey.sol is only relevant for the full Rollup prover. Neither the Mock prover nor the unit tests reference it.
691
+
VerificationKey.sol is never actually used directly. When the Deployer runs, it overwrites the contract file with a new one, which is similar in format, but contains the Rollup verification keys that have been computed during key generation. Note that this overwriting only happens when we are using a full rollup prover. This explains why VerificationKey.sol is not updated in Git, even though the keys change: the updated file is never seen by Git because we never push from a machine that is running a full rollup prover.
692
+
The overwriting is an unusual approach. Normally one would have a static VerificationKey.sol which contains a function that lets us update the key on deployment. However, the current approach is taken because we want to control exactly how the key data is stored in memory so that we can benefit from the speed increase we get from assembly. Achieving this is much easier if all the key data is hard-coded. We therefore generate the code in Rust so that we can have hard-coded keys (in Solidity) that can be still changed (in Rust) at deployment if they need to be updated.
693
+
The unit tests compute their own keys and use a test contract (test_contracts/TestVerifier.sol) which is kept separate from the 'production' contract. This seems sensible because we don't want the unit test to change the main contract as it's more a test of the key generation.
694
+
Is there a better way? Probably not. It's the use of Assembly, which creates the requirement to store a large amount of key data in specific locations, that makes this a sensible approach in this case.
695
+
We don't actually need VerificationKey.sol so it could be removed from the repository, in principle. However RollupVerifier.sol expects it to be there. Having a work around for that seems more trouble than keeping a 'placeholder' VerificationKey.sol.
0 commit comments