How Optimistic Rollups Work for DeFi Protocols

Detailed Instructions

A user initiates a transaction, such as a token swap on a DeFi protocol, by signing and submitting it to an Optimistic Rollup sequencer. The sequencer is a node responsible for ordering transactions. Users typically interact with the sequencer via an RPC endpoint provided by the rollup client. The transaction is executed locally on the L2 state to generate an immediate result, providing a fast user experience. The transaction data, including the signature, calldata, and nonce, is then batched with other pending transactions.

• Sub-step 1: Construct the transaction with the correct chainId for the L2 network (e.g., 10 for Optimism).
• Sub-step 2: Sign the transaction using a wallet like MetaMask, which is configured for the L2.
• Sub-step 3: Submit via RPC to the sequencer's public endpoint (e.g., https://mainnet.optimism.io).

javascriptCopy
// Example of sending a transaction via ethers.js
const tx = await signer.sendTransaction({
  to: '0x...',
  value: ethers.utils.parseEther('0.1'),
  gasLimit: 100000
});
await tx.wait(); // Waits for L2 confirmation

Tip: The sequencer provides instant, soft confirmation, but the funds are not yet secured by Ethereum.

Detailed Instructions

The sequencer periodically aggregates hundreds of L2 transactions into a single batch. This batch is compressed to minimize L1 gas costs, primarily by storing only essential transaction calldata. The sequencer then publishes two critical pieces of data to the L1 rollup contract: the state root and the calldata. The state root is a Merkle root hash representing the new L2 state after executing all transactions in the batch. The calldata is posted to Ethereum's calldata, which acts as cheap, permanent data availability storage.

• Sub-step 1: Aggregate transactions into a batch, ordering them by sequence.
• Sub-step 2: Compute the new state root by executing the batch and hashing the resulting state trie.
• Sub-step 3: Submit to L1 by calling appendSequencerBatch() on the L1 CanonicalTransactionChain contract.

solidityCopy
// Simplified interface for the L1 batch submission contract
interface ICanonicalTransactionChain {
    function appendSequencerBatch() external;
    // Batch data is passed as a tightly-packed byte array
}

Tip: At this point, the state root is considered "asserted" or "proposed," but not yet final. It enters a challenge window.

Detailed Instructions

After a state root is posted to L1, a challenge window (typically 7 days) begins. During this period, the new state is considered optimistic—assumed to be correct but not verified. Any verifier (a full node watching the chain) can dispute an invalid state root by submitting a fraud proof. The fraud proof is a succinct cryptographic argument that demonstrates a specific transaction in the batch was executed incorrectly. It does this by challenging a single execution step, forcing the L1 contract to re-execute that step using the published calldata. If the fraud proof is valid, the fraudulent state root is deleted and the sequencer's bond is slashed.

• Sub-step 1: Monitor state roots submitted to the L1 rollup contract.
• Sub-step 2: Detect a discrepancy between the posted state root and your local node's computation.
• Sub-step 3: Construct and submit a fraud proof by calling the fraudProofVerifier contract function with the necessary Merkle proofs.

Tip: For users, this means withdrawals are delayed until the challenge window passes, as funds are not fully secured until then.

Detailed Instructions

If no fraud proof is submitted during the challenge window, the state root is finalized. This means the L1 contract accepts it as canonical and true. Finalization enables trustless withdrawals from L2 to L1. To withdraw, a user initiates an L2 transaction that burns tokens or exits a position. A withdrawal message is emitted as a log. After the challenge window passes, the user must prove this message's inclusion in the finalized L2 state to the L1 bridge contract using a Merkle proof. The L1 contract verifies the proof and releases the equivalent funds on Ethereum.

• Sub-step 1: Initiate withdrawal on L2 (e.g., call withdraw() on the standard bridge).
• Sub-step 2: Wait for the challenge period (e.g., 7 days for Optimism) to complete.
• Sub-step 3: Prove inclusion on L1 by submitting the Merkle proof to the L1StandardBridge.finalizeETHWithdrawal() function.

solidityCopy
// Example L1 function to finalize a withdrawal
function finalizeETHWithdrawal(
    uint256 _l2BlockNumber,
    uint256 _l2MessageIndex,
    bytes32 _l2TxHash,
    bytes32 _merkleProof
) external;

Tip: Fast withdrawals via liquidity providers are possible but involve trust in a third party to front the funds before finalization.

Detailed Instructions

A watcher or verifier node monitors the Canonical Transaction Chain (CTC) on the L1 for new state root commitments. They run a local replica of the rollup's state transition function. When a new state root is posted, the verifier computes the expected root from the previous state and the published batch of transactions. If the computed root does not match the committed root, a fraud proof challenge can be initiated. This requires the verifier to have access to the full transaction data, which is typically posted as calldata to L1.

• Sub-step 1: Continuously sync the rollup's L1 contract (e.g., StateCommitmentChain).
• Sub-step 2: Re-execute the disputed transaction batch locally using the rollup client.
• Sub-step 3: Compare the resulting state Merkle root with the one published on-chain.

Tip: Running a verifier requires archival data access and significant computational resources to re-execute transactions quickly.

Detailed Instructions

The verifier calls the startChallenge or equivalent function on the rollup's FraudVerifier contract on Ethereum. This function requires specifying the disputed state root and the previous state root to define the scope of the challenge. The caller must post a challenge bond (e.g., several ETH) which is slashed if the challenge is incorrect. This action starts a challenge period (e.g., 7 days) during which the sequencer can respond. The transaction must include the precise batch index and output root to dispute.

• Sub-step 1: Prepare a transaction to the verifier contract address (e.g., 0x5e4e65926ba27467555eb562121fac00d24e9dd2 on Optimism).
• Sub-step 2: Encode the function call with arguments: previousRoot, disputedRoot, batchIndex.
• Sub-step 3: Send the transaction with the required bond amount as msg.value.

solidityCopy
// Example interface for initiating a challenge
interface IFraudVerifier {
    function startChallenge(
        bytes32 _preStateRoot,
        bytes32 _postStateRoot,
        uint256 _batchIndex
    ) external payable;
}

Tip: Ensure your node's clock is synchronized, as challenges are time-bound.

Detailed Instructions

After challenge initiation, the verifier must provide the specific transaction and state data that demonstrates the fraud. This often involves an interactive fraud proof system like bisection. The verifier submits the first step by specifying the instruction index within the disputed batch where the execution diverges. The required data includes the pre-state, the transaction input, and the opcode at that step. This data is submitted via a contract call like provideProof. The system then enters a multi-round game where the challenger and sequencer iteratively narrow down the point of disagreement.

• Sub-step 1: Isolate the first instruction where local execution differs from the claimed outcome.
• Sub-step 2: Fetch and package the relevant pre-state witness (Merkle proof) for that instruction.
• Sub-step 3: Call bisect or provideFirstStep on the verifier contract with the packaged data.

Tip: The fraud proof must be submitted within the challenge period; delays can result in a lost bond.

Detailed Instructions

The verifier and the sequencer (or their delegates) engage in a multi-round bisection protocol managed by the L1 contract. In each round, the contract presents a claim about execution over a range of instructions. The opposing party must respond by either agreeing or providing a sub-range where they disagree. This continues until the dispute is narrowed to a single opcode execution step. The final step requires a one-step proof, where the disputed opcode's execution is verified on-chain in the EVM. This proof uses a verification key for a zk-SNARK or directly executes the opcode logic in a contract.

• Sub-step 1: Monitor the contract for the sequencer's response after your initial proof.
• Sub-step 2: Counter-respond with a bisection step that further isolates the faulty computation.
• Sub-step 3: Prepare the final one-step proof data for the singular disputed instruction.

solidityCopy
// Conceptual structure for a bisection response
struct BisectionResponse {
    bytes32[] stateHashes; // Intermediate state roots for the sub-range
    uint256 challengedStepIndex; // Index within the previous range
}

Tip: The cost of L1 gas for the final one-step proof can be high, but is typically reimbursed from the slashed bond.

Detailed Instructions

Once the interactive game concludes at a single step, the FraudVerifier contract performs the final verification. If the challenger's one-step proof is valid, the disputed state root is proven fraudulent. The contract will then delete the invalid state root from the canonical chain and slash the sequencer's bond. The slashed funds are used to reward the challenger (often a portion of the bond) and burn the remainder. If the challenger fails to prove fraud or times out, their bond is slashed and awarded to the sequencer. The resolution transaction finalizes the state, ensuring only valid roots are recognized.

• Sub-step 1: Wait for the contract to call finalize or for the challenge period to expire.
• Sub-step 2: Verify the transaction receipt to confirm the state root was deleted.
• Sub-step 3: Check that the challenger's address received the reward from the slashed bond.

Tip: Successful challengers must account for Ethereum gas costs, which may offset the reward if the sequencer bond is small.