New Stage 1 requirements for L2 proving systems

Methodology & Framework
1

The following requirements will become a part of the Stage 1 requirements within L2BEAT stages framework. They are compiled from the requirements announced on our forum previously plus additional condition on optimistic fault proof prestate reproducibility, I post it again for clarity and completeness.

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

  1. No red trusted setups. Stage 1 projects can’t have proving systems with trusted setups rated red (:red_circle:) according to L2BEAT trusted setups framework.

  2. Prover source code published. Stage 1 projects must publish a 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).

  3. Verifiers reproducible. For Stage 1 validity projects, source code for all used onchain verifiers must be available online, including the recursion and final wrap verifiers. The project must provide valid instructions on how to independently regenerate onchain verifier smart contracts (including correct verification keys) from the verifier source code.

  4. ZK and optimistic programs reproducible. For a Stage 1 validity project that relies on a zkVM, the sources for all zkVM programs used in securing funds on this chain must be published. For a Stage 1 optimistic project that relies on a particular initial state of fault proof program, the sources of the fault proof program must be published. In both cases, the project must provide valid instructions on how to regenerate onchain commitments to the programs from their sources.

Appendix: examples of projects satisfying and failing new criteria

  1. No red trusted setups. Facet V1, Zircuit and Loopring L2s rely on trusted setups incompatible with new Stage 1 requirements: https://l2beat.com/zk-catalog. All other projects pass.

  2. Prover source code published. To our knowledge, all projects already comply with this requirement.

  3. Verifiers reproducible. Boojum from Matter Labs is an example of project that exposes a convenient tool for regenerating verifier smart contracts. Another such example is this guide from the Polygon team to reproduce zkProver verifier smart contract. Lighter desert verifier is an example of a verifier that could not be reproduced because its sources are not published, so Lighter L2 would not be compliant with the new Stage 1 requirements.

  4. ZK and optimistic programs reproducible. Hashes of ZK programs securing ZK stack chains could be conveniently regenerated using this script. OP stack also provides clear guidelines on how to regenerate absolute prestate for its fault proof programs.

Also see similar section on the previous post.