New Stage 1 requirements for ZK setups

[sergeyshemyakov]

We propose to add the following items to the Stage 1 requirements. They all relate to ZK verifier setups used by L2s.

The main motivation is to hold ZK verifier setups to the same standards of transparency and trustlessness as other components of the rollup tech stack, and to enable every user to independently verify the full correctness of onchain ZK verifiers.

New proposed requirements

1. Stage 1 projects can’t have proving systems with trusted setups rated according to L2BEAT trusted setups framework.

2. For Stage 1 projects, source code for all used onchain verifiers must be available online, including the recursion and final wrap provers. If a project relies on a zkVM, then source code for all zkVM programs used in securing funds on this chain must be published. Additionally, the project must provide instructions on how to independently regenerate onchain verifier smart contracts (including correct verification keys, if applicable) from the verifier source code. If zkVM programs are used and their identifiers (program hashes, program verification keys, etc.) are stored onchain and checked by the verifier, instructions on how to regenerate these identifiers must also be published.

Clarification

The items above apply to all smart contracts and proof systems that secure the canonical messaging bridge (rollup proof system itself, but also ZK DA verifiers) and could be used by project operators with the current onchain configuration. In particular, if an operator can choose between several verifiers by a switch in transaction calldata, all of these verifiers must comply. We encourage teams to explicitly disable old versions of ZK verifiers that are not intended to be used anymore.

Above, by prover we mean the cryptographic algorithm that takes input data and generates the proof to be verified, not including any infrastructure around proof generation (e.g. GPU parallelization, distributed computing, optimizations for witness generation). A prover could be e.g. a Plonk SNARK or a zkVM STARK. A final wrap prover is the prover that checks a validity proof and generates a proof of successful check to be posted onchain. By zkVM program we mean the part of zkVM input that encodes the operations being proven, expressed in any high-level language that could be compiled into the native ISA of this zkVM.

Examples

• Taiko publishing where to find program sources for program hashes: https://github.com/taikoxyz/raiko/blob/main/RELEASE.md

• Scroll publishing where to find program sources and how to regenerate commitments: Prover Architecture (Post-Euclid)

• Succinct guide on reproducing vkey hashes: https://succinctlabs.github.io/op-succinct/advanced/verify-binaries.html

• Polygon guide on how to regenerate verifier smart contracts: https://github.com/agglayer/agglayer-contracts/blob/main/verifyMainnetDeployment/verifyMainnetProofVerifier.md

• ZKsync boojum guide on how to regenerate verification keys for the onchain verifier: https://github.com/matter-labs/zksync-era/tree/main/prover/crates/bin/vk_setup_data_generator_server_fri

[sergeyshemyakov]

After some discussions, I decided to move out the requirement to have prover sources available into a new requirement, so the different reasons for published prover and verifier sources are more apparent. Verifier code must be available to independently check that the correct logic is being verified onchain, prover code must be available so that users are able to prove blocks themselves if the operator faces a liveness failure.

Additional proposed requirement

3. Stage 1 projects must publish the source code for all used provers, so users are able to prove state transitions in the case if the prover operated by the project itself goes down. This does not concern projects that are guaranteed to always self-prove blocks under the Stage 1 assumptions (e.g. because the prover and proposer roles are fulfilled by the Security Council minority that is assumed to behave honestly for Stage 1).