Fraud proofs are a very important part of Optimistic rollup stack. For transactions like ETH withdrawal and tokens from Optimism chains, a withdrawal proof needs to be submitted which shows that the withdrawal was actually included in the OP chain.
Fraud proofs permissionlessly allow users to submit and challenge the proposals about the state of the rollup chain that are used to prove such withdrawal transactions.
This allows more decentralization on the rollup chain by following
allowing anyone to make proposals about the state of L2
allowing anyone to challenge proposals made by other users
allow users to send message from L2 to L1 without need of trusted party
allow users to trigger withdrawals from L2 to L1 without need of trusted party
The fault proof game is permissionless, but the Optimism security council acts as a guardian role checking for faults in the fault proof game. So each proposal must want for a delay during which the council checks and prevents invalid proposals from being used to withdraw ETH or tokens.
They can also choose to shift the system to use a PermissionedDisputeGame in which only specific proposer and challenger roles can submit and challenge proposals.
The Proposals or also known as State Proposals are claims about the state of the rollup that are submitted to Ethereum through the DisputeGameFactory contract. They can be used for many things but most commonly are used by end users for proving they made a withdrawal on the rollup. Now because anyone can submit a proposal, invalid proposals needs to be challenged. There is a 7 days challenge period during which users can challenge the proposal if they think it is incorrect.
There are some security guards also built around the fault proof game
an off chain monitoring system has been set to monitor all proposed roots and ensure they align with the correct state
A root is finalized through a game an additional delay called airgap window is added before withdrawals can occur. During this the guardian role can reject the root
A contract called DelayedWETH has been set up to hold the bonds and only allow payouts after a delay so that the bonds can be redirected towards the correct recipient in the case of game resolving incorrectly.
Workings of Fault Proof components
The Fault Proof system is made of 3 main components
Fault proof program
Fault proof virtual machine
Dispute game protocol
These components work together to challenge malicious or faulty activity on the network to preserve trust and consistency of the system.
Fault Proof program
The default implementation of this system is op-program that implements a program that runs through the rollup state-transition to verify an L2 output from L1 inputs.
This verifiable output can then resolve a disputed output on L1. The program is a combination of of op-node and op-geth. It has both the consensus and execution parts of the protocol in a single process. The fault proof program runs in a deterministic way, so that 2 invocations with the same input data not only gives the same result but also the same program execution trace.
This deterministic execution allows it to be run on an onchain VM as a part of the dispute resolution process.
Fault Proof VM
The VM is decoupled from the Fault Proof Program to enable higher level of composability and parallelization of upgrades to both components. The Fault proof program which is the client side runs within the Fault proof VM expresses the L2 state transition.
The VM is very minimal, such that Ethereum protocol changes like EVM op-code additions do not affect the VM. Instead the fault proof program can be updated to import new state-transition components. The VM is tasked with lower level instruction execution. The program needs to be emulated. Generally proving instruction looks as follows
To execute the instruction, the VM emulates something similar to an instruction-cycle of a thread-context. The instruction is read from the memory, interpreted and register-file and may change the memory.
To support the pre-image oracle (from where all the data is retrieved) and basic program runtime needs memory-allocation, support for a subset of linux syscalls. The program writes a hash as request for a pre-image and then reads the value in small chunks at a time.
Dispute game protocol
In this protocol, different types of games can be created, managed and upgraded via the DisputeGameFactory. This allows for new features like aggregate proof systems and ability to expand the protocol. The game is the core primitive to the dispute protocol. It models a simple state machine and it is initialized with a 32 byte commitment to any piece of information of which the validity can be disputed.
They contain a function to resolve this commitment to either true or false which is left for the implementer of the primitive to define. The games rely on 2 fundamental properties
incentive compatibility. The system penalizes false claims and rewards truthful ones to ensure fair participation
resolution, each game has a mechanism to definitively validate or invalidate the root claim
That’s about it, a high level overview of the Fault proof in optimism rollup chain.
Top comments (0)