From Zero to Hero: OP Stack Fault Proof Series 1 [ENG]

Fault Proof Mechanisms in Optimism’s Multi-Proof Architecture

Tokamak Network aims to deliver valuable information for current developers interested in Optimism and the evolution of the Ethereum ecosystem.

Source: Oplabs Link

This post is the first installment of the ‘The feature-complete version of OP Stack fault proofs Series,’ comprising 3 planned articles by Tokamak Network. This article introduces Optimism’s Fault Proof Program, detailing how its Multi-Proof Architecture enhances Layer 2 security and reliability by integrating robust fault proof mechanisms for accurate state transitions and efficient dispute resolution.

💡 Given the interconnected nature of the series, we recommend reading the articles sequentially for a cohesive understanding.

Series 2. Cannon’s Fault Proof System:
In this article, we provides an overview of Cannon(Optimism’s FPVM), which ensures Layer 2 state transition integrity via offchain execution and onchain verification. Key components like MIPS.sol, MIPSEVM, and PreimageOracle work together for efficient dispute resolution. [LINK]

Series 3. The Fault Dispute Game(FDG) / Bisection Game:
In this article, we explore how Optimism's Fault Proof System resolves Layer 2 state disputes using onchain (MIPS.sol) and offchain (MIPSEVM) components. We cover the roles of proposers and challengers, the PreimageOracle’s data management, and the incentive structures ensuring integrity and security. Additionally, we explain the bisection game, which breaks down disputes into single instructions for precise verification. [LINK]

Upgrade Proposal: Fault Proofs

Fig. Screenshot of “Upgrade Proposal: Fault Proofs” Proposal (Source: gov.optimism.io link)

The Optimism (OP) Stack has undergone a significant upgrade with the introduction of fault proofs, designed to enhance the security and reliability of the Optimism network. This upgrade, titled “Upgrade Proposal: Fault Proofs,” was launched on the OP Mainnet on June 10, 2024, following governance approval.

Core Changes

Changes in Challenge Period:

• Fault Proofs upgrade must wait for a 7-day challenge period before being finalized.
• Withdrawals challenged for validity are delayed by an extra 3.5 days. If the challenge is deemed malicious on the valid proposal, the delay can extend up to 9 more days, which is costly for the challenger. (Such cases are expected to be rare.)
• Standard withdrawal finalization time: 7 days (no change)
• If a validity challenge is received: an additional 3.5 days
• If the valid proposal is maliciously challenged: up to an additional 9 days

💡 Maximum possible withdrawal delay: 7 + 3.5 + 9 = 19.5 days

Changes in Withdrawal Process

• The L2OutputOracleis being removed and replaced by the OptimismPortal and DisputeGameFactory.
• Developers use these outputs to prove their withdrawals occurred on L2.
• With the introduction of fault proofs, developers will need to modify their client software to prove withdrawals in the first step of the two-step withdrawal process.

L2OutputOracle

• With the Fault Proof Mainnet upgrade, the OptimismPortal will point to the DisputeGameFactory contract instead of the L2OutputOracle contract.
• The most significant change for developers is that withdrawals will need to be proven against the rootClaim of a dispute game rather than referencing an output in the L2OutputOracle contract.

OptimismPortal

• The OptimismPortal smart contract, used on L1 to execute deposits and withdrawals, is changing its approach.
• Previously, developers referenced the L2OutputOracle to find the exact output that included their withdrawal.
• Now, developers must use the OptimismPortal contract to determine the respectedGameType and use this information to query the DisputeGameFactory for a list of recent DisputeGame contracts with the correct GameType.

DisputeGameFactory

• Developers are advised to search for a reasonable number of recent games (such as 100 recent games) and select the first proposal with a sufficient block number.
• They should then verify this proposal locally.
• The default GameType will allow for permissionless proposals (anyone can submit proposals), so there is no longer a strong guarantee that proposals will be valid.

What are Fault Proofs?

Fault Proofs, also known as fraud proofs or interactive games, are mechanisms used in blockchain systems, especially in Layer 2 rollups, to verify the correctness of state transitions. They ensure the validity and security of data and computations on a Layer 2 network by detecting and resolving disputes through a structured process. Fault Proofs enhance the security and integrity of rollups by providing a method to challenge and verify state transitions.

Key Components of the Fault Proof System

Fault Proof Program (FPP) is responsible for generating proofs of faults. It identifies discrepancies between the claimed post-state and the actual state derived from the pre-state and the witness data. Essentially, it verifies the correctness of the state transitions proposed by the output proposer.

Fault Proof Virtual Machine (FPVM, Cannon) is a specialized virtual machine that executes the Fault Proof Program. It provides a secure and deterministic environment to run the FPP, ensuring that the fault proofs are consistent and verifiable by all participants in the network.

• The FPP focuses on executing and verifying state transitions, while the FPVM provides the environment to ensure these executions are done correctly and verifiably.

The Dispute Game Protocol is a mechanism for resolving disagreements over state transitions. When a challenger identifies a discrepancy and submits a fault proof, the dispute game protocol is triggered. This protocol involves a series of interactions and verifications to assess the validity of the fault proof. If the proof is valid, the incorrect state transition is rejected, thereby ensuring the integrity of the blockchain.

💡 Each of these three components can be implemented in different ways, which can be combined into various proof stacks, contributing to proof diversity when resolving disputes.

Fault Proof Mechanisms in Layered Blockchain Systems

Fig. Roles and Data Flow in Op-stack

Network

Layer 1(Ethereum): The base layer, containing a sequence of blocks that store transaction data and state changes.

Layer 2(Optimism): Layer 2 reads headers, transactions, and receipts from L1. These L1 elements are converted into payload attributes that Layer 2 can process.

• The L2 Consensus Layer processes the payload attributes derived from L1.
• The L2 Execution Layer uses these attributes to execute transactions and update the state.

Core Components

Rollup: The Sequencer is responsible for sequencing transactions(Receipts).

Batcher: An entity that collects transactions and submits them in batches to Layer 1. This process helps to ensure efficiency and cost-effectiveness in the Rollup system.

Verifier: An entity that ensures the accuracy and consistency of the sequenced data by verifying that Layer 2 is fully derived from Layer 1. The verifier checks the batches of transactions and computations, submitting proofs or validations to confirm that the state transitions on L2 correctly reflect those on L1. If any issues are found during the verification process, the verifier also alerts the challenger to address these discrepancies.

Output Proposer: A specialized verifier who processes data from Layer 1 and derives the corresponding results for Layer 2. The Output Proposer then posts these results back to L1, asserting, “This is the derived result from Layer 1 after processing.”

Challenger: If a Verifier disagrees with the state or claims made by the Output Proposer, it assumes the role of a Challenger. The Challenger monitors L1 for incorrect claims made by the Output Proposer. If an incorrect claim is detected, the Challenger submits a counter-proposal to correct it, ensuring the integrity and correctness of the sequenced data.

A single node can perform both the roles of a Verifier and a Challenger. This means that one node can verify transactions while simultaneously challenging the verification results of other verifiers. This system is designed to enhance the security and fairness of the network. The separation or concurrent execution of the verifier and challenger roles provides various incentives to network participants, helps reduce incorrect verifications, and maintains the integrity of the network. Therefore, while the same node can fulfill both roles, it is important to understand that each role functions differently depending on the specific situation.

💡 Fault proofs are essential in preserving the integrity of the Rollup process by ensuring that any incorrect claims by the Output Proposer are identified and corrected by the Challenger. A single node can perform both the roles of a Verifier and a Challenger, meaning that one node can verify transactions while simultaneously challenging the verification results of other verifiers.

State-Transition Process

Fig. State Transition and Dispute Process

Agreed Pre-State: This is the initial state that everyone in the network agrees upon. It serves as the starting point for the state transition.

Witness Data: New data derived from Layer 1, including headers, transactions, and receipts, which are input into the Layer 2 system for processing.

Disputed Post-State: The output state that has been claimed by the Challenger and needs to be verified. This state is the result of applying the witness data to the agreed pre-state and is subject to challenge and verification.

The State Transition Program(FPP): This program takes the agreed pre-state and applies the witness data to produce the next state in a local environment. The process includes several steps:

1. Extract and process L1 headers, transactions, and receipts from the agreed pre-state.
2. Derive L2 payload attributes from the L1 data.
3. Apply these attributes in the L2 Consensus Layer to arrange the sequence of transactions as they were processed on L1.
4. Use the Execution Layer to process this ordered sequence and produce the new state.

Verification Process:

1. Compare the state produced by the Local State Transition Program with the Target Post-State.
2. If they match, no further action is needed.
3. If they do not match, the dispute game begins to resolve the discrepancy.

Multi-Proof Architecture

Fig. Self-Customization Model for Multi-Proof Architecture

The Multi-Proof Architecture is a framework developed by Optimism to enhance the security and reliability of Layer 2 solutions. This architecture integrates multiple fault proof mechanisms, allowing various components to be freely mix-matched and customized according to specific needs. By leveraging these adaptable components, the Multi-Proof Architecture ensures that L2 state transitions are accurate and verifiable, providing a robust and trustworthy environment for Layer 2 operations. This flexibility enables users to tailor the architecture to meet diverse requirements, enhancing both the security and efficiency of the system.

Key Components and Their Roles:

Op-node:

Role: Acts as the coordinator within the Layer 2 environment.

• Block Creation: Manages the creation of new blocks.
• Block Validation: Validates the newly created blocks.
• Block Propagation: Ensures the blocks are propagated across the network.
• L2-L1 Interactions: Manages interactions between Layer 2 and Layer 1, ensuring seamless communication and data transfer.

Other Version: Magi is a new rollup client for the Optimism OP Stack, written in Rust, designed to enhance network security and resilience by providing an alternative to the existing Op-node client. It acts as the consensus client, feeding new blocks to the execution client to advance the chain, and aims to increase client diversity and decentralization in rollup networks. Currently in early development, Magi seeks contributions to improve features such as sync speed and data availability, ultimately aiming to become a robust, production-ready client.

Op-geth:

Role: Based on Ethereum’s Go client (Geth), Op-geth primarily handles the execution and validation of transactions.

• EVM Execution: Executes the Ethereum Virtual Machine (EVM) operations.
• Smart Contract Processing: Handles the processing of smart contracts.
• Transaction Validation: Validates transactions within the Layer 2 environment.
• State Transitions: Manages the state transitions to ensure they are correctly executed and reflected.

💡 Together, Op-node and Op-geth work in harmony to ensure that state transitions within Layer 2 are correctly sequenced and executed. Op-node coordinates the overall process, while Op-geth performs the critical tasks of executing EVM operations and validating transactions.

Cannon:

Role: Serves as a Fault Proof Virtual Machine (FPVM) within Optimism’s fault proof system.

• Execution Trace Generation: Emulates a minimal Linux-based system on the MIPS32 architecture to generate execution traces for state transitions.
• Data Collection: Collects data from external servers to ensure the execution traces can be reproduced and verified by others.
• On-Chain Fault Proof Creation: Allows the creation of on-chain fault proofs with verifiable instructions.
• Integrity Assurance: Ensures the integrity of Layer 2 state transitions by providing a reliable mechanism for verifying execution traces.

Other Version: Asterisc (RISC-V) is an experimental fault proof VM for the OP Stack that uses RISC-V programs to create interactive fraud-proofs, compatible with Cannonbut designed for broader future applications. It includes a Go-based RISC-V emulator (rvgo) and a Solidity/Yul mirror (rvsol) for on-chain execution, supporting 32-bit and 64-bit instruction sets but avoiding complex operations for simplicity and determinism. Asterisc focuses on minimalism, security, and first-class Golang support, making it a simpler, more future-proof alternative to Cannonand is currently about 80% complete.

“Setup” and “Finalization”

Fig. Interaction Flow of Op-program Server/Client and FPVM

Op-geth (op-program server):

Role: Server component that interacts with both Layer 1 and Layer 2 via RPC.

Function: Acts as the PreimageOracle server, providing necessary pre-image data for fault proof computations.

FPVM — Fault Proof Virtual Machine (Cannon):

Role: Generates execution traces.

Function: Collects data from an external server to allow trace reproduction. These traces are used to create verifiable on-chain fault proofs, ensuring the virtual machine’s execution integrity.

Solidity Implementation:

• Cannon includes a Solidity implementation of MIPS.
• This implementation verifies a single instruction using a few hundred lines of code.

Go Implementation:

• Cannon also includes a Go implementation of MIPS.
• This implementation is used to produce witness data efficiently and handle billions of instructions effectively.

Using Cannon:

1. The OP program is hosted to collect data from Layer 1 and Layer 2 nodes.
2. The collected data is used to create pre-images.
3. These pre-images are served to Cannon.
4. Cannon passes the pre-images into the emulated program.
5. The program processes Ethereum data and generates the proof result.

Op-node (op-program client):

• Role: Client that handles setup, data derivation, and finalization.
• Function: Works with the pre-image oracle client to ensure accurate data transformation and fault proof validation.

Detailed Steps of the FPP

①. Initialize from L1 Start:

• Start with the First Pre-image: This step begins the process using the initial state from Layer 1. The “first pre-image” is the initial data or state that acts as the starting point for all further computations.

②. Synchronize Inputs:

• Couple L1 and L2 Inputs: In this step, inputs from both Layer 1 and Layer 2 are synchronized. This coupling ensures that the data and transactions recorded on L1 are accurately reflected in L2. This step is crucial for maintaining consistency and correctness across the two layers, making sure that the L2 state transitions are based on up-to-date L1 data.

③. Derive L2 Block Inputs:

Fig. Execution priority as opposed to data flow during the derivation pipeline.

• Utilize Op-Node Derivation Pipeline: This step involves processing the synchronized inputs through the Op-node derivation pipeline. The pipeline processes the coupled L1 and L2 inputs to generate the necessary data for creating new L2 blocks. This derived data includes all the information required to construct valid L2 blocks, ensuring that the state transitions are accurate and complete.

💡 Derivation pipeline: The sequencer generates L2 blocks, and the batch submitter compresses and sends the generated L2 block information to L1. The process of reconstructing the L2 chain based on the information sent to L1 is termed ‘block derivation.’ This enables validators to perform sanity checks on the blocks generated by the sequencer. more details

④. Process L2 Block Inputs:

• Execute via Execution Engine: The derived inputs are processed through the execution engine, which performs the necessary computations to generate valid L2 blocks(In a Local Env.). The execution engine ensures that the computations adhere to the rules and logic defined in the protocol, resulting in accurate state transitions and block creation. This step is essential for maintaining the integrity of the L2 blockchain.

⑤. Compute L2 Block Outputs:

• Determine the Output-Root: The final step is to compute the output root, which represents the final state after processing the Layer 2 blocks. This output root is essential for future computations and state transitions, ensuring they are correctly recorded and verifiable. The process involves comparing the output root submitted by the sequencer with the one generated by the Fault Proof Program (FPP) in a local environment to verify accuracy.

💡 The FPP facilitates state transitions from a pre-state to a post-state, based on the Interactive Bisection Game. It involves:

• Referencing Latest Layer 1 Data: Ensuring all data is current and posted.
• Utilizing Agreed-Upon State: Building on an undisputed state for clarity and consistency.
• This setup promotes transparency and accurate state transitions. The FPP meticulously handles each step, ensuring reliable and verifiable transitions from Layer 1 to Layer 2.

Conclusion

The “Upgrade Proposal: Fault Proofs” is a significant advancement for the Optimism (OP) Stack, enhancing network security and reliability by ensuring correct state transitions and efficient dispute resolution. Key changes include adjusting the challenge period, overhauling the withdrawal process, and replacing the L2OutputOracle with the OptimismPortal and DisputeGameFactory. The integration of the Fault Proof Program (FPP), Fault Proof Virtual Machine (FPVM, Cannon), and the Dispute Game Protocol, along with the Multi-Proof Architecture, solidifies the system’s robustness. This upgrade fosters greater confidence among developers and users, reinforcing Optimism’s position as a leading Layer 2 solution.

Reference

Upgrade Proposal: Fault Proofs

• https://gov.optimism.io/t/final-protocol-upgrade-7-fault-proofs/8161/12
• https://blog.oplabs.co/the-fault-proof-system-is-available-for-the-op-stack/

Youtube

https://www.youtube.com/watch?v=RGts3PSg4F8

docs

• https://docs.optimism.io/builders/notices/fp-changes
• https://docs.optimism.io/stack/protocol/fault-proofs/overview
• https://docs.optimism.io/stack/protocol/fault-proofs/mips
• https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/specs/cannon-fault-proof-vm.md
• https://medium.com/tokamak-network/optimism-bedrock-wrap-up-series-4-eng-c08e1c0dd069