Vitalik Buterin (Ethereum Co-founder) – Multi-Provers for Rollup Security (Oct 2022)


Chapters

00:00:14 Beyond Training Wheels: Achieving Trustlessness in Roll-ups
00:04:30 Multiprover Rollup Security Models
00:11:00 Multi-Prover Rollup Architecture Strategies
00:14:53 Combining ZK, Optimistic Rollups, and Governance for Secure and Scalable
00:20:42 ZK Multiproving and the Future of Ethereum

Abstract



Revolutionizing Blockchain Security: Exploring the Future of Roll-Up Systems Through Multi-Prover and Governance Strategies

In the rapidly evolving landscape of blockchain technology, the quest for robust security and trust minimization in roll-up systems is paramount. Central to this challenge is the reliance on “training wheels” such as multi-signatures and governance overrides, which currently compromise the trustlessness of these systems. With the inherent complexity and potential bugs in roll-up code, notably in large-scale ZKVM circuits, the industry faces a crucial need for practical, secure alternatives. This article delves into promising strategies like high-threshold governance overrides, multi-prover approaches, alternative fraud prover implementations, and hybrid governance models. These approaches collectively aim to enhance security and resilience against vulnerabilities, while balancing the trade-offs between bug prevention and governance involvement, marking a pivotal shift towards more secure and decentralized blockchain architectures.

Main Ideas and Expanded Discussion:

High-Threshold Governance Override:

A proposed solution to enhance trust in roll-ups involves implementing a high-threshold governance override system. This system necessitates a group of guardians who, under stringent conditions (e.g., 6 out of 8 agreeing), can override the proving system to address clear bugs. Despite offering a degree of trust minimization, this method is not immune to governance attacks, especially if the majority of guardians act dishonestly. Current roll-ups operate with training wheels, allowing human intervention to override the proof system in case of code bugs. The complexity of code, such as the ZKVM circuit code, consisting of 34,469 lines, introduces the challenges of ensuring bug-free operation.

The Multi-Prover Approach:

An innovative solution lies in the multi-prover approach. It involves using multiple, distinct proving systems, akin to the diversified implementations of the Ethereum protocol. This strategy boasts a lower correlation of vulnerabilities, increased resilience against bugs and attacks, and enhanced security. However, it also presents challenges in coordinating these systems and managing the complexity of integrating different proof systems while mitigating potential new vulnerabilities. Instead of relying on a multi-signature of people, a multi-signature of different proving systems can be used to increase resilience against bugs and malicious behavior. Multiple implementations of the Ethereum protocol, like Prism and Lighthouse, provide a more resilient network in case of bugs in one implementation. Combining fraud-proof and ZK rollups can be particularly powerful due to their fundamentally different assumptions and low correlation in potential bugs or vulnerabilities.

Alternative Fraud Prover Implementations:

Exploring further, alternative implementations of fraud provers are considered. These include compiling the Geth source code into a minimal virtual machine for dedicated fraud proving and utilizing different languages for more efficient implementations. Additionally, multi-prover strategy variants, such as self-canceling and prover deactivation mechanisms, draw inspiration from smart contract wallet designs. These strategies add layers of security and resilience to the rollup systems. Fraud provers can be created by compiling source code into a minimal virtual machine, like MIPS, and creating a fraud prover for that machine. Different approaches exist for creating a ZK AVM, such as direct compilation and compiling to an intermediate language. In a multi-prover strategy, multiple provers are used to verify state roots. If a prover accepts multiple conflicting state roots, it is turned off to ensure the system’s integrity. If a prover remains inactive for a certain period, it is also turned off to prevent deadlocks. The concept of self-canceling provers is inspired by smart contract wallet designs, where a withdrawal can be canceled within a specific timeframe. This approach is applied to roll-ups using multiple provers instead of personal wallets using private keys. The idea of social recovery for provers allows for a mechanism to switch a prover if it is unable to perform its duties effectively. This approach is similar to social recovery for personal wallets, where multiple parties can help recover access to funds.

Two-Prover Plus Governance Tiebreak:

This model proposes a novel block validation mechanism that synergizes two provers – ZK and optimistic – with a governance tiebreak as a final resort. It balances the benefits of both ZK and optimistic approaches and minimizes the role of governance to an emergency backup, thus providing strong security guarantees while also mitigating the risk of bugs in either prover. It consists of a ZK prover and an optimistic prover. The two-of-three mechanism involves ZK, optimistic, and governance. Two approaches are suggested for integrating provers and governance: The 24-hour time window approach and the immediate block acceptance approach. The 24-hour approach accepts SNARKs within 24 hours for block acceptance, with fraud proofs and SNARK games running concurrently, and governance providing the correct answer in case of disagreement. The immediate block acceptance approach runs all three provers simultaneously, accepting blocks upon agreement between two provers, enabling fast block finalization with ZK-SNARKs. This system is resilient against governance corruption and provides bug protection, minimizing the simultaneous occurrence of bugs in different constructions of provers.

Multi-Aggregator Minimization and ZK EVM Limitations:

A focus on minimizing the codebase requiring formal verification is crucial, striving for simplicity to reduce potential vulnerabilities. The limitations of ZK EVMs, especially their susceptibility to bugs over a prolonged period, are acknowledged, emphasizing the need for systems designed to effectively tolerate and mitigate these issues. Simple programs with polynomial verification may be feasible for bug-free proofs, but EVM-level complexity introduces significant challenges. Vitalik Buterin seeks practical alternatives to achieve trustlessness or trust minimization despite the challenges of code risk.

ZK VMs: Progress and Challenges:

The rapid development of ZK Virtual Machines has been both promising and challenging. While prototypes have emerged faster than expected, there is still a period of uncertainty due to the potential bugs in proof systems, circuit compilers, or ZKVM code itself. Balancing security against bugs and bad governance is a critical concern, with the focus gradually shifting towards minimizing governance involvement except in emergencies. ZK EVMs are prone to bugs for a considerable period. Accepting this reality is crucial for system design and security.

ZK Multi-proving for Layer 1:

Envisioning a future where running an Ethereum node is feasible on devices like smartphones, this approach involves using SNARKs to verify block hashes, potentially making the process more decentralized and resource-efficient. Achieving this goal requires advancements in ZK-EVMs, a ZK-Ethereum consensus layer, and recursive ZK-ZK, all reliant on trust in advanced polynomial math. ZK multi-proving, generating proofs for a block using multiple ZK-EVM engines, enhances client diversity and security on Layer 1. However, technical challenges exist, such as the need for a SNARK capable of verifying everything. Vitalik envisions a future where different clients and ZKVM engines coexist, enabling client diversity and security.

Multiple Implementations for Layer 1 ZK-SNARKs:

A multi-faceted approach involving different clients and ZKVM engines for Layer 1 ZK-SNARKs could significantly enhance Ethereum’s security and diversity. However, the implementation strategy and the prioritization of Ethereum consensus components for ZK-proofing remain open questions.

Hybrid and Multi-proving Future:

The foreseeable future of both Layer 1 and Layer 2 in blockchain seems to be leaning towards a combination of multi-proving and hybrid-proving systems. This transition might occur in phases, with institutional stakers using regular nodes and home stakers experimenting with ZKProvers, representing a significant step towards a more secure, decentralized, and resilient blockchain ecosystem. A hybrid-proving system combining traditional and ZK-based methods may emerge, with institutional stakers using regular nodes and home stakers experimenting with ZKProvers. This transition is expected to occur in phases, eventually leading to a multi-proving and hybrid-proving system on both Layer 1 and Layer 2.



The exploration of multi-prover approaches, governance strategies, and alternative implementations in roll-up systems marks a critical juncture in the pursuit of enhanced blockchain security and decentralization. While these strategies offer promising pathways to minimize trust and maximize resilience, they also pose unique challenges and require careful consideration and ongoing development. The future of blockchain security lies in a balanced, multi-faceted approach that adeptly navigates the complexities of technology and governance.


Notes by: oganesson