Fraud Proofs: The Eclipse Perspective

Fraud proof protocols are the backbone of optimistic rollup security, enabling users to challenge any incorrect L2 state proposed by the sequencer. Today, these protocols safeguard around $20B in assets on Arbitrum One and OP Mainnet. Though rarely triggered in practice—serving primarily as a deterrent—fraud proofs remain widely misunderstood. We at Eclipse believe it's time to demystify this topic as we move towards L2 stage 1. Let's explore the latest fraud proof protocols and examine what makes each one unique.

How To Secure An L2

L2 chains have fundamentally different security properties than L1 blockchains. While Ethereum relies on consensus across thousands of nodes, L2s intentionally reduce this decentralization to achieve higher performance through relying on powerful servers and specialized hardware. Without strong decentralization guarantees, can we verify that the L2 is operating honestly, according to its predefined semantics?

Let’s take a simplified model of a blockchain (L1 or L2).

To verify the output of such a system, you need to:

1. Take the state of the chain at block N
2. Take all transactions that make up block N+1
3. Execute the state machine rules of the chain over these inputs
4. Compare the output state with the one generated by the block producer

When applying this logic to an L2, the ideal setup would be to verify the L2 state transitions directly on L1. If L1 had infinite storage and computing power, we could simply run these steps on-chain through a smart contract that emulates the L2 state machine. However, this is not feasible in practice, otherwise we would not need L2s in the first place. Therefore, we must make compromises.

There are two main security models for L2s nowadays: validity rollups and optimistic rollups. These two models try to emulate this ideal verification but delegate the verification to off-chain systems. Think of it as the classic eager vs lazy approach: validity rollups promptly submit a verifiable proof of their correct behavior to L1, while optimistic rollups simply post transaction data to the DA layer and rely on third parties to verify the L2 state by rebuilding it, then challenge the L2 state on L1 if they find a discrepancy. The table below compares the key trade-offs of each approach.

Optimistic rollups have a significant cost advantage today—generating and verifying proofs on-chain remains substantially more expensive. Even though the industry is working hard to reduce proving costs, Eclipse will continue operating as an optimistic L2 for the foreseeable future.

Anatomy of a challenge

Let's return to fraud proofs. First, a bit of terminology: verifiers verify the state of the chain, challengers open challenges to the L2 state and defenders are honest, well-behaving challengers.

How can a challenger demonstrate to the L1 that there's a discrepancy in the L2 state? To keep things simple for now, let's assume the L1 knows about individual L2 blocks. Each L2 block consists of a transaction sequence stored on the DA layer and a block header with metadata stored in an L1 smart contract. This block header must include at least these essential fields:

1. A cryptographic commitment to the sequence of transactions for the block, the transaction commitment.
2. A cryptographic commitment to the state of the chain after executing these transactions, the state commitment.

Verifiers will fetch block transactions from the DA layer, check that the transaction sequence matches the transaction commitment and that the state after executing these transactions matches the state commitment. Out of the door, we see that we have two possible types of fraud: transaction fraud and state fraud. Most optimistic chains handle transaction frauds as degenerate cases of state frauds.

As we cannot recompute the state entirely on-chain, the strategy used by most optimistic rollups is to divide and conquer: they ask challengers to identify the first computation where they disagree with the L2. This is typically achieved through an interactive bisection game: challengers will collaborate to identify this disagreement, and divide it in a way that this computation step is small enough to be re-executed on-chain. The advantage of bisection is to reach an agreement in $O(\log(N))$ steps.

We then re-execute this computation step in a process called the one-step proof: a CPU emulator smart contract re-executes one or more assembly instructions, and the result determines the winner of the challenge. The exact granularity of the one-step proof varies on the proof system, with some executing a single assembly instruction while others prefer coarser steps.

To summarize, once a challenge is started:

1. Divide the total block computation in steps small enough that they can be executed on-chain
2. Interactively bisect with another challenger to find the first step of disagreement
3. Re-execute this step on-chain and let the smart contract determine the winner.

Thanks to this protocol, optimistic rollups are secure as long as there is an honest defender with enough funds to take part in the bisection game and then execute the one-step proof.

The challenge window

This brings us to the challenge window—the maximum time period during which a block can be challenged.

The diagram below shows the L2 chain as represented on L1, with the canonical L2 fork in green and two different forks (B’ and D) submitted by challengers in red.

I hope you like bisection

Before we dive into the various fraud proof protocols and their qualities, we need to add a layer of complexity. Posting to the DA layer and to L1 for every L2 block remains prohibitive. In practice, L2s batch blocks together to reduce the frequency of posting and reduce costs. This results in the L1 metadata containing information about batches of blocks instead of individual blocks.

‍

But still, posting on L1 for every L2 block would be too expensive, and so most L2s post blocks in batches and store the batch metadata (ex: block range, state commitments, link to DA blobs, etc) on L1. The result is that L1 ends up only knowing about block batches, not individual blocks.

Therefore, challengers contest the state of the chain at the batch level. While we could theoretically perform the bisection game at the batch level, in practice this requires collecting too many execution traces. Therefore, some fraud proof protocols split the descent into two bisection games: the first identifies the first block in a batch where the challengers disagree, and the second identifies the computation step to run as one-step proof. This is the case for Arbitrum BoLD and Cartesi PRT.

Delay attacks

Another important consideration is whether it is possible for an attacker to delay L1 finality for an arbitrary period of time. Such attacks are called delay attacks. In earlier dispute protocols, the bond posted by the challenger was directly redistributed to the defender. It was therefore trivially cheap to perform a delay attack, as a defender could challenge itself and delay L1 finality essentially forever. New protocols address this in two ways:

1. Do not redistribute the entirety of the bond to the defender, increasing the cost of such an attack
2. Use dispute protocols that are bounded in time.

The 7-day challenge window

Two rounds of interactive bisection and a one-step proof do sound like a fair bit of work, but that cannot take 7 days, can it? The duration of the challenge window is a question as old as fraud proof protocols (which is not that old, all things considered). The main risk to fraud proof protocols is the liveness requirement for the defender(s). If they are unable to participate in the dispute, the dispute may be resolved in favor of an attacker.

In fact, the challenge window is 7 days because of the doomsday threat of state-level attackers. The feared scenario is that an extremely well-funded attacker could censor L1 by spamming transactions with high priority fees, effectively blocking the progress of the defenders. Many people have tried computing an upper practical limit to such an attack, but in theory it is only limited by the TVS of the chain under attack.

The usual conclusion is that it would take 7 days for L1 validators to reach social consensus over what to do in such a scenario. In practice, this remains to be seen as such a censorship attack is profitable in the short-term for validators.

Adaptive Dispute Cutoff

Are we doomed to wait 7 days in fear of an attacking state? Not really. An interesting proposal is Adaptive Dispute Cutoff, a protocol that proposes to measure L1 gas fees and determine whether there actually is an ongoing censorship attack.

The concept is the following: compute the gas consumed on L1 since an assertion over a specific block height was made. The protocol defines a threshold of gas that leaves enough compute/time for a challenger to post a contradicting assertion. If this threshold is reached, the assertion can be finalized, way faster than 7 days.

How does ADC detect censorship? Simply by not counting blocks where gas price is over a predefined limit. The algorithm also adds a correction factor for congestion. By detecting congestion and censorship, ADC is an interesting solution to reduce the finality window by an order of magnitude while sticking to the 7-day window in case of strong censorship attacks.

Fraud proof protocols: a survey

Now that we understand what a fraud proof is, let’s take a look at actual implementations! Fraud proof protocols are complex by nature and require proper auditing as any weakness potentially puts billions of dollars at risk. We will use the following criteria to evaluate fraud proof protocols.

1. Safety: what are the conditions for the defender to protect the correct L2 state? Under this category, we will focus mostly on the defender/attacker funding ratio, i.e. the relative funding of the defenders vs the attacker. In some situations the defender can defend the chain against multiple attackers by posting a single bond. But running N challenges in parallel still costs in gas fees, and a ratio close to 100% means that a well-funded attacker could overspend the defender. This factor is essential in determining whether a fraud proof protocol can be permissionless or must be restricted.
2. The finality window: the worst-case duration of challenges for a specific block, not to be confused with the challenge window. A high finality window means that users will be unable to withdraw their funds from the L2 for a long period of time, possibly penalizing users.
3. Decentralization: how easy it is for anyone to submit challenges. The main factor here is the value of the bond that challengers have to pledge to submit a challenge. If the bond is high, then only a few actors are able to open challenges. This limits the number of participants, increasing the risk that no defender is able to participate.

Comparative table

Here is a summary of the features of the different fraud-proof protocols we analyzed. In the next sections, we will discuss each one in more detail.

Arbitrum BoLD

The BoLD (Bounded Liquidity Delay) is the latest dispute resolution protocol. It was deployed on mainnet early February 2025. BoLD is a permissionless protocol, meaning that anyone can start a challenge on-chain, unlike the current fraud proof protocol of Arbitrum which is permissioned (only a few selected actors can start a challenge).

The main selling point of BoLD is that it guarantees a bounded dispute resolution delay of 6.4 days. It also guarantees correctness if there is at least one honest participant in the dispute.

Under the hood, BoLD is a cooperative N vs N protocol. Challengers first post a bond (3600 ETH) to post an assertion about the state of the system at a certain block. Any participant can then choose to defend this assertion by helping with its bisection. Let’s take a look at a challenge with 3 different assertions.

The 3 forks all submit a different state at height 2048, and in particular they also commit to a history of the state from height 0 to height 2048. This is called the execution history commitment and is what enables full concurrency, i.e. multiple assertions can be made at the same time and any player can advance the bisection of the assertion of his choice. Bisection is achieved by posting an intermediate state and a Merkle inclusion proof of this state in the execution history commitment.

When an intermediate state is added, the two edges to the left and right may become presumptive edges. A presumptive edge is the shortest path that starts from a specific block, determining the challenge winner if challengers stop pursuing their bisection. This system ensures the dispute resolves in favor of the honest defender, provided they remain active and advance the bisection of the honest assertion one step ahead of other assertions.

In simpler terms, defenders don't need to complete the entire bisection game—they just need to stay one step ahead of competing assertions.

If challengers keep playing the game, we reach the end of the bisection and find the first block where two or more assertions disagree. For each block, BoLD will recursively enter a second level of bisection over computation steps, ending in a one-step proof emulated on-chain.

The honest strategy is simple:

1. Make an honest assertion if nobody has
2. If a top-level edge can be confirmed, confirm it
3. If an honest edge is not presumptive:
   
   1. If it is a one-step edge, one-step prove it
   2. Otherwise, bisect it.

BoLD's main weakness lies in its unlimited number of participants combined with its second level of bisection. A well-funded attacker can create N first-level assertions, forcing the defender to participate in N second-level bisections and post N second-level bonds.

The funding ratio between attacker and defender can be defined as the ratio between first-level and second-level bonds. Since the second-level bond must exceed a specific threshold to protect against hardware and blockspace exhaustion attacks, this results in high bonds. This makes BoLD less decentralized than other fraud proof protocols.

Despite its high bonds, BoLD remains vulnerable to well-funded attackers since the Total Value Secured could be large enough for an attacker to justify spending hundreds of millions of dollars to potentially gain billions. With BoLD's funding ratio at 15%, defenders need tens of millions of dollars available to adequately protect the network against such attacks.

Cartesi PRT and Dave

The weakness of BoLD to well-funded attackers comes from the fact that the number of participants is unbounded and that the user does not recuperate his funds before the end of the dispute. What if we set a fixed number of participants to the dispute, and had multiple rounds instead of one?

This is the main idea behind Cartesi’s Permissionless Referee Tournament and subsequent protocols: split the bisection game in multiple rounds with a fixed number of participants. The unfolding of each round is exactly the same as BoLD. The difference lies in the fact that participants are grouped in brackets, and the winner of each bracket goes to the next level. This bracket tournament structure gives PRT an $O(log(N))$ finality (N being the number of participants).

The main problem with PRT is the risk that the defender gets ejected out of the game by a censorship attack on the game it is participating in. This forces PRT to wait one week for each round of the game, giving it awful finality.

This is where Dave comes to the rescue, with a simple idea: amortizing the censorship budget of a well-funded attacker over all the rounds of the game instead of one by one. The concept is simple. Let’s say that matches now are bounded to 1 day. The defender may therefore lose 7 matches if the attacker spends his entire censorship budget, but will never lose more than 7 matches. Therefore, instead of eliminating losing participants, Dave organizes rematches to make sure that the defender is not being censored. This effectively reduces the worst-case finality window of Dave vs PRT and makes it more acceptable.

Optimism Fraud proofs

The Optimism fraud proof protocol (OPFP for short) was released in June 2024 on OP Mainnet. OP fraud proofs use a single-level bisection game, in a single round. This gives the protocol a bounded finality of one week, much like BoLD. As with all fraud proof protocols, challengers make claims about the state of the rollup at a specific height.

In OPFP, the defenders and challengers build a Merkle tree over the computation traces of the blocks concerned by the dispute. They then descend the challengers’ tree(s) to determine the portion of the tree they have in common and therefore the first assembly instruction they disagree on. OPFP uses the terms “attack” and “defend”.

A branch node in the tree is attacked if a player determines that this node is invalid. In this case, we descend left in the tree. To defend a node, you move back to the parent node then go right then left.

Upon reaching a leaf, this instruction is executed in the on-chain MIPS emulator (the Cannon VM), which decides the winner of the challenge.

The main problem with this protocol is that the defender(s) must bisect every claim of the challenger(s), which requires them to put up as many bonds as the challenger(s) in the worst case (one bond per node). Furthermore, as OPFP does not use compute commitments, This results in the defender needing slightly more funding than the attacker. This poses a problem for state-level attackers, as they could easily outspend the defenders and take control of the chain.

ZK to the rescue: Kailua

The common point between all the fraud proof protocols we mentioned so far is that they require a second level of bisection in practice. This second level of bisection forces these protocols to choose between security, decentralization and bounded finality. This all comes down to a simple problem: the granularity of the one-step proof is too low! What if, instead of proving one/a few assembly instruction(s), we could prove an entire block, or a batch of blocks, in one step?

Turns out that we can actually do this using ZK proofs. This is where Kailua comes in. Kailua is a fraud proof protocol compatible with OP stack that implements its generic dispute game interface as a ZK proof generation and verification.

Kailua does away with interactive bisection games entirely. Instead, it requires the challenger to post a valid ZK proof of execution for its assertion. Assertions must be posted within the challenge window, and the ZK proof for a specific assertion can be posted anytime. There is no explicit timeout for the challenge, but defenders are incentivized to post a ZK proof for the honest assertion. The best part is that the cost for the defender is constant: it only needs to create and validate the proof for the correct state once to disprove all contradictory assertions. No need for multiple bonds, multiple smart contract calls, etc. Generate one proof, send it on-chain and the dispute is resolved. 

What is even more interesting is that Kailua opens the perspective of hybrid rollups, that can transition between optimistic and validity rollup according to the needs of the network. If proving costs continue to go down, starting an L2 as optimistic then switching to validity mode later down the line becomes a viable option.

As it is with any novel cryptographic systems, a bug in the underlying ZK system of Kailua could lead to invalid proofs being accepted. As these systems mature, these bugs become rarer, and RiscZero notes that work is underway to complete formal verification of its code. We can also rely on multiple zkVM implementations or even TEEs to mitigate this risk in the meantime, similarly to Taiko’s multi-prover setup.

Conclusions

We hope this exploration of fraud proof designs has been insightful. Now you might wonder: where does Eclipse fit in?

We have selected ZK fraud proofs and will adapt Kailua to the SVM. This hybrid approach for Eclipse creates opportunities to reduce L1 finality times and possibly even transition to a full validity rollup. It marks a crucial milestone toward achieving stage 1 L2 status—stay tuned for upcoming details on our implementation plans! 

We want to acknowledge many insightful conversations with members of the technical staff at RiscZero and Cartesi in writing this post.

References

A gentle introduction: BoLD | Arbitrum Docs

The BoLD Challenge Protocol

[2212.12439] Permissionless Refereed Tournaments

Kailua: How it Works | RISC Zero

Why multi-prover matters. SGX as a possible solution. — Taiko Labs

Fraud Proofs Are Broken - Layer 2 - Ethereum Research

Why wait a week? Fast Finality Optimistic Rollups - Layer 2 - Ethereum Research

Optimistic rollups, the challenge period and strong censorship attacks

Videos

‍The Dave fraud-proof algorithm — triumphing over Sybils with a laptop and a small co... | Devcon SEA

Ed Felten (Offchain Labs) - "Permissionless Validation Using the BoLD Protocol"

Fraud proofs war by Luca Donno | Devcon SEA

(PDF) Dave: a decentralized, secure, and lively fraud-proof algorithm

‍