The Endgame: How We Secure MegaETH with ZK

Author: MegaETH Source: @megaeth_labs Translation: Shan Ouba, Golden Finance

At the core of all Optimistic Rollups, there is a key assumption: Submitted state proposals are valid by default until they are proven wrong. However, this assumption is only true when Rollup has a strong fraud proof mechanism. A chain that lacks this mechanism will immediately become unsafe once an invalid state is not questioned or the settlement process is blocked due to malicious challenges.

The Burden of Fraud Proofs

To support the above assumptions, Optimistic's L2 must support a fraud proof mechanism (also known as a dispute resolution protocol), which allows validators (challengers) to challenge potentially incorrect state proposals submitted by sorters (proposers). This mechanism must ensure two key properties:

1. All incorrect state proposals can be identified,

2. Incorrect challenges will never succeed.

From a technical perspective, this mechanism consists of two core components:

• Challenge subprotocol: handles disputes over a single state proposal.

• Tournament mechanism: when multiple competing state proposals appear for the same block, it is used to filter out the only correct proposal.

Each state proposal is a statement of the results of a set of transaction executions, usually consisting of three parts:

• Initial state: the most recently confirmed L2 state on Ethereum;

• Transaction payload: a series of L2 transactions that have occurred since that state;

• Final state: the result that the proposer claims to have obtained after executing these transactions.

So, a complete proposal essentially says:

"Assuming the current initial state is A, execute the following list of transactions (payload), I think the final state should be X."

We can visualize this structure in the form of the following figure:

At this point, the role of the challenge subprotocol is to verify whether the claim is correct. If it is wrong, the challenge must succeed and the proposal must be rejected.

Interactive Fault Proof (Binary Challenge Game)

In most of the current mainstream Optimistic Rollup systems, an interactive protocol is adopted: the challenger and the proposer engage in a back-and-forth confrontation.

Once a dispute is raised, the two parties will binary decomposition of the intermediate results of the calculation process (the results of each step claimed by the proposer) to gradually narrow down the scope of possible errors. This process will continue to recurse until both parties locate a single erroneous calculation step (for example, a transaction was executed incorrectly).

Once the specific error is determined, the step will be re-executed on the Ethereum mainnet to determine whether there is indeed fraud.

However, this mechanism has multiple problems:

• High latency: Each step of interaction requires initiating a transaction on the Ethereum chain. A complete dispute resolution process may take hours or even days, especially when the network is congested or censored;

• High requirements for proposers: Even if the proposer is honest and the challenge is unfounded, he still needs to participate in the entire dispute process, paying a considerable computational and on-chain interaction cost;

• Easy to be used maliciously: Malicious challengers can continuously make unreasonable challenges, forcing honest proposers to repeatedly waste time and gas costs to defend the correct state.

In reality, interactive fraud proofs are costly, fragile under high load, and easy to be abused.

Non-interactive Fraud Proofs (ZK Challenge Model)

MegaETH takes a completely different path: it requires the challenger to generate only a concise zero-knowledge proof (ZKP) to prove that the final state claimed by the proposer is invalid.

Specifically, this ZK proof shows that executing a sequence of transactions from the initial state will not result in the final state claimed by the proposer. The mechanism will be built on RISC Zero's zkVM and will be implemented by borrowing OP Kailua's non-interactive fraud proof hybrid architecture.

The proof is submitted to Ethereum through a single transaction, and the on-chain validator contract will confirm its validity. The proof proposer does not need to participate in any work, cannot interfere in the entire process, and does not participate in disputes.

Of course, generating such a ZK proof is not easy - it requires running the disputed calculation process in the zk virtual machine in its entirety, which is expected to consume about 100 billion computing cycles and cost about $100 in the worst case. But this cost only occurs when fraud is proven, and by design, it is borne by the dishonest party. This model greatly reduces the capital pressure of honest challengers and fundamentally eliminates the risk of malicious damage in the binary mechanism.

ZK is used for fraud proof, not state validity

In the field of encryption, "zero knowledge (ZK)" is often simplified as a synonym for ZK Rollup - that is, using ZK proofs to verify state transitions off-chain and then publishing them to the system on the chain. But this understanding actually only covers half of ZK's potential.

MegaETH uses zero-knowledge proofs not to verify the correctness of the state, but to prove fraud. This allows us to retain the efficiency and scalability of Optimistic Rollup while adding a trustless, non-interactive mechanism for detecting and challenging invalid state transitions.

We call this hybrid approach ZK fraud proofs, and it brings a fundamentally different trust model.

Detection window unchanged, significantly reduced finality

For security and prudence, MegaETH will still retain the 7-day challenge window of a typical optimistic chain, which means that any participant has a full week to dispute a state root. But the real difference occurs after the dispute is raised In the interactive model, if a challenge is raised on the 7th day, it may take a few additional days to complete the dispute resolution. During this period, the finality of the chain on the Ethereum mainnet will be frozen, protocol progress will be interrupted, and the chain's liveness will be affected.

With ZK fraud proofs, the entire dispute process will be completed in about 1 hour. Challengers generate ZK proofs, submit them to the Ethereum mainnet, and verify them immediately, and the chain state quickly gains finality. This effectively protects against a key attack vector: Malicious challengers repeatedly initiate false disputes to block the finality of the chain.

Data availability guaranteed by EigenDA

To ensure the integrity of the fraud proof process, challengers must be able to easily and reliably access the original block data to reproduce the challenged calculation process.

This is why we use the ZK fraud model with EigenDA, a decentralized, high-throughput data availability layer.

Through this structure, the entire process is streamlined to the safest and most efficient form:

• The sorter publishes the block data to EigenDA, and only submits a small data summary to Ethereum. The encryption guarantee provided by EigenDA ensures that fraud proofs can be generated at any time, and the sorter cannot "hide" the data to evade review;

• Any observer can retrieve the block data from EigenDA, reconstruct the complete block and execute it in zkVM;

• Once fraud is detected, the observer can generate a concise ZK fraud proof and submit it to the verification contract on Ethereum; the sorter will be punished and its invalid proposal will be rejected.

A Cryptographically Secure, Scalable Trust Model

MegaETH replaces cumbersome interactive fraud games with succinct, non-interactive ZK fraud proofs. This approach eliminates the risk of harassment attacks, significantly reduces final confirmation time, and ensures that disputes can be resolved in an efficient and scalable manner.

With RiscZero providing verifiable computational power and @eigen_da ensuring access to raw data, every state proposal is:

reconstructable, verifiable, and challengeable by anyone - at any scale.