Endgame: How We Use ZK Technology to Protect the Security of MegaETH

Author: MegaETH Source: @megaeth_labs Translator: Shan Oppa, Golden Finance

At the core of all Optimistic Rollups lies a key assumption: submitted state proposals are considered valid by default until proven otherwise. However, this assumption only holds if the Rollup has a strong fraud proof mechanism in place. Chains lacking this mechanism become immediately unsafe if an invalid state goes unchallenged or if the settlement process is blocked due to malicious challenges.

Burden of Proof of Fraud

To support the above assumption, Optimistic's L2 must support a fraud proof mechanism (also known as dispute resolution protocol) that allows validators (challengers) to challenge potentially incorrect state proposals submitted by the sequencer (proposer). This mechanism must ensure two key characteristics:

1. All erroneous status proposals can be identified,
2. The wrong challenge will never succeed.

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

• Challenge Subprotocol: Handle disputes over individual state proposals.
• Tournament Mechanism: When multiple competing state proposals appear in the same block, it is used to filter out the unique correct proposal.

Each state proposal is a declaration of the execution results of a set of transactions, typically consisting of three parts:

• Initial State: The most recently finalized L2 state on Ethereum;
• Transaction Load: A series of L2 transactions that have occurred since that state;
• Final State: The proposer claims the results obtained after executing these transactions.

Therefore, a complete proposal essentially states:

"Assuming the current initial state is A, executing the following transaction list (payload), I believe the final state should be X."

We can visualize this structure in the form shown in the figure below:

At this time, the role of the challenge sub-protocol is to verify whether the claim is correct. If it is wrong, the challenge must be successful, and the proposal must be rejected.

Interactive Fault Proof (Binary Challenge Game)

In most current mainstream Optimistic Rollup systems, an interactive protocol is adopted: a back-and-forth confrontation between challengers and proposers.

Once a dispute is raised, both parties will binary split the intermediate results of the computation process (the claimed execution results of each step by the proposer) to gradually narrow down the possible range of errors. This process will continuously recurse until both parties pinpoint a single erroneous computation step (for example, a transaction executed incorrectly).

Once the specific error is determined, this step will be re-executed on the Ethereum mainnet to ascertain whether fraud truly exists.

But this mechanism has multiple issues:

• High Latency: Each interaction requires initiating a transaction on the Ethereum chain. A complete dispute resolution process can take hours or even days, especially during network congestion or when under scrutiny;
• High demands on proposers: Even if the proposer is honest and the challenge is baseless, he still has to participate in the entire dispute process, incurring significant computational and on-chain interaction costs;
• Easily exploited: Malicious challengers can continuously raise unreasonable challenges, forcing honest proposers to repeatedly waste time and gas costs to defend the correct state.

In reality, interactive proof of fraud is costly, vulnerable under high load, and easily abused.

Non-Interactive Proof of Fraud (ZK Challenge Model)

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

Specifically, this ZK proof indicates that the execution of the transaction sequence from the initial state does not yield the final state claimed by the proposer. The mechanism will be built on RISC Zero's zkVM and will draw on OP Kailua's non-interactive fraud proof hybrid architecture to achieve this.

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 with the entire process, and does not participate in disputes.

Of course, generating such a ZK proof is not an easy task—it requires the complete execution of the disputed computation process in the zk virtual machine, which is expected to consume around 100 billion computation cycles, with a worst-case cost of approximately $100. However, this cost only occurs when fraud is proven and, by design, is to be borne by the dishonest party. This model significantly alleviates the capital pressure on honest challengers and completely eliminates the risk of malicious sabotage in the binary mechanism.

ZK is used for fraud proofs, not state validity

In the cryptocurrency field, "zero-knowledge (ZK)" is often simplistically understood as synonymous with ZK Rollup — that is, a system that uses ZK proofs to verify state transitions off-chain and then publishes them on-chain. However, this understanding actually only covers half of the potential of ZK.

The purpose of MegaETH using zero-knowledge proofs is not to verify the correctness of the state, but to prove fraudulent activities. This allows us to introduce a trustless, non-interactive mechanism for detecting and challenging invalid state transitions, while retaining the efficiency and scalability of Optimistic Rollup.

We call this hybrid approach ZK Fraud Proof, which brings about a fundamentally different trust model.

Detection window remains unchanged, end time significantly shortened

For security and prudence considerations, MegaETH will still retain the 7-day challenge window typical of Optimistic chains, meaning that any participant has a full week to dispute a particular state root. However, the real difference occurs after a dispute has been raised. In the interactive model, if a challenge is raised on the 7th day, it may take several additional days to resolve the dispute. During this period, the finality of the chain on the Ethereum mainnet will be frozen, protocol progress will be interrupted, and the activity of the chain will also be affected.

In the case of using ZK fraud proofs, the entire dispute process will be completed in about 1 hour. The challenger generates a ZK proof, submits it to the Ethereum mainnet, and it takes effect immediately after verification, with the chain state quickly achieving finality. This effectively defends against a key attack vector: malicious challengers repeatedly initiating false disputes to obstruct the finality of the chain.

Data Availability Assurance Provided by EigenDA

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

This is exactly why we are using the ZK fraud model in conjunction with EigenDA (a decentralized, high-throughput data availability layer).

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

• The sequencer publishes block data to EigenDA while only submitting a small data summary to Ethereum. The cryptographic guarantees provided by EigenDA ensure that fraud proofs can be generated at any time, and that the sequencer cannot "hide" data to evade scrutiny;
• Any observer can retrieve 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 their invalid proposal will be rejected.

A trust model with cryptographic guarantees and scalability

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

With the verifiable computing capabilities provided by RiscZero and the support for raw data access ensured by @eigen_da, each state proposal has:

Reconstructability, verifiability, and the possibility of being challenged by anyone — regardless of scale.