Author: protolambda, Researcher at OP Labs
Translation: Frank, Foresight News
In order to create the most powerful and secure interoperable Layer2 network, Optimism Collective is pursuing decentralization through various means.
The upcoming fault-tolerant system of OP Stack will be a major step towards technical decentralization. The open-source and modular design of OP Stack is creating an unprecedented stage for the social decentralization of the L2 ecosystem.
- Discussion on the Integration of Indian Gaming and Web3 Technology
- Understanding the Intent-Centric Architecture that Focuses on Results Only
- Why does Binance Wallet consume gas like crazy? Exploring the technical and security factors behind it.
In this article, we will explore the principles of social decentralization and how L2 architecture enables Layer 2 to expand this principle to include proof diversity and client diversity. We will also introduce how Optimism Collective utilizes this architecture to build its fault-tolerant system.
“Ethereum-inspired” Social Decentralization
The Ethereum protocol benefits from social decentralization, especially by providing selectivity in the solutions, allowing a wide range of contributors to participate in building a strong decentralized network.
For node software, this means client diversity: the more clients there are, the less impact a single point of failure has on the validator network.
Core developers of Layer1 describe this contribution model as a “bazaar,” which is noisy and seemingly chaotic, but highly efficient and vibrant. By adopting a thoroughly open protocol development approach, the widest range of contributors can participate and improve the protocol.
Optimism Collective has a unique advantage in implementing and iterating Ethereum’s social decentralization: OP Stack achieves social decentralization by providing open specifications and open-source software under the MIT license, and Optimism Collective can iterate on it by creating superchains.
A Deeper Understanding of L2 Architecture
Ethereum has an open specification at L1 and a modular client architecture that separates the consensus layer and the execution layer.
OP-Stack implements the same architecture at L2:
The consensus layer is supported by op-node and Magi, both clients follow L1 and export execution inputs;
The execution layer is supported by op-geth, op-erigon, and op-reth;
However, L2 architecture adds a new layer to this stack: the proving layer.
This is the layer that securely bridges L2 outputs back to L1. Just as having multiple clients is the best practice to ensure consensus and execution on both L1 and L2, for the proving layer of L2, using multiple proof methods ensures optimal security.
Similar to validators reaching consensus with different clients, the canonical count of on-chain proofs indicates that L2 state transitions have been validated in different ways, greatly reducing the possibility of complete failure due to errors.
Currently, there are three common types of proofs: attestations, fraud proofs (also known as challenge proofs), and zero-knowledge validity proofs. The latter two share a common pattern, expressing L2 state transitions in a synchronous form and proving their execution given L1 data and the previous L2 state as input.
Isolation Proof System Components to Achieve Proof Diversity
The proof system can be further decomposed into independent components:
- A “program” that defines the synchronous L2 state transition;
- A “virtual machine” (VM) that runs and verifies the program;
- A “pre-image oracle” that takes L1 data and L2 pre-state as input;
Many of today’s zero-knowledge proofs are still tightly coupled to these components, creating a ZK-EVM that runs on a single L1 transaction data. However, the OP stack decouples them to isolate complexity and achieve client diversity, making the whole system more powerful.
Interactive fault proofs add a bisection game to the virtual machine trace to verify the proofs on-chain, while VM-based zero-knowledge proofs perform arithmetic and folding on execution and provide validity proofs. (See Risc0 and O(1)-Labs’ VM-based zero-knowledge proofs designed in response to Optimism ZK RFPs).
The program defines the actual state transition as the “client” and defines the input retrieval (L1 data and L2 pre-state) as the “server”. The program runs independently with the server/client without a virtual machine, similar to regular blockchain nodes, and shares a lot of code.
For example, the Go op-program client is built by importing op-node derived from op-geth and EVM, while the server gets its data from L1 and L2 Ethereum RPC.
Overview of FPVM Features
Fault Proof Virtual Machine (FPVM) is one of the modules in the OP Stack’s fault proof stack.
In addition to providing the correct interfaces (especially those related to the pre-image oracle), the virtual machine does not implement anything specific to Ethereum or L2. The Fault Proof Program (FPP) client running inside the FPVM is the part that expresses L2 state transitions.
Through this separation, the virtual machine remains minimal: changes to the Ethereum protocol, such as adding EVM opcodes, do not affect the virtual machine.
Instead, when the protocol changes, the FPP can simply update to import new state transition components into the node software, similar to playing a new version of a game on the same console. The L1 proof system can be updated to prove different programs.
The virtual machine is responsible for executing low-level instructions to simulate the FPP. The virtual machine has low requirements: the program is synchronous, and all inputs are loaded through the same pre-image oracle, but all of these still need to be proven on the L1 EVM chain.
To achieve this, only one instruction can be proven at a time. The bisection game reduces the task of proving complete execution traces to just one instruction.
For each FPVM, the instruction proof may look different, but it usually looks similar to Cannon, which proves the following instructions:
- To execute the instruction, the virtual machine simulates something like an instruction cycle in a thread context: reading the instruction from memory, interpreting it, and the register file and memory may undergo some changes;
- To support basic program runtime requirements such as pre-image oracle and memory allocation, execution also supports a subset of Linux system calls. Read/write system calls allow interaction with the pre-image oracle: the program writes the hash as a request and retrieves the pre-image by reading it piece by piece;
Cannon, the first FPVM, achieves the MIPS virtual machine in this way. For more information about the virtual machine, please refer to the relevant documents and cannon-specs. The interface between FPVM and FP programs is standardized and documented in the specification.
From FPVM to ZKVM
Proof-of-fault is not the only type of state transition proof. ZK validity proof is an attractive choice because it has the potential for fast cross-chain bridging (due to the fact that ZK validity proof does not have on-chain challenge games, so there is no dispute window). In order to support advanced Ethereum stacks and host different client implementations, we still need to decouple the virtual machine and the program.
This is the approach taken by the ZK RFP project to prove that a minimal RISC-V (by Risc0) or MIPS (by O(1) Labs) virtual machine can host the same program used in the proof-of-fault.
Supporting ZK-VM does require some small adjustments to allow the pre-image oracle to load data in a non-interactive way, but by generalizing the virtual machine, ZK proofs are more future-proof when facing OP Stack changes.
Opportunities for External Contributors
OP Stack welcomes additional virtual machine and program options, as well as additional independent proof systems, from proofs to zero-knowledge proofs. Just like client diversity, proof diversity is the result of collective efforts.
The ongoing additions to the OP Stack proof layer include:
- The RISC-V FPVM “Asterisc” written in Go language developed by protolambda;
- The rust FP program based on Magi and op-reth contributed by Base and OP Labs contributors;
- The rust ZK program based on zeth (ZK-reth branch) built by Risc0;
With the development of Cannon, op-program, bisection-game, and the infinite creativity of the open-source community, there will be many additional opportunities to contribute to the stack through testing implementation and participation in bug bounty programs.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
