Guides

Responsive Validity Proof & Optimistic ZK-Rollup

Luka Morph

Aug 30, 2023 — 9 min read

Introduction

Rollups in the industry are broadly categorized into two types: optimistic rollups and zk-rollups. Both have unique advantages and disadvantages.

Morph offers a blend of both with it’s innovative solution or new state verification method called “Responsive Validity Proof” (RVP).

Key Terminology:

RVP: Abbreviation for Responsive Validity Proof.
Sequencer: Also known as the rollup operator.

Optimistic Rollup

This concept means that Layer 2 (L2) optimistically accepts state changes submitted by the sequencer without verifying the authenticity of the state changes. Instead, there’s a challenge period before the state changes are finally confirmed on Layer 1 (L1).

During the challenge period, external entities (sometimes referred to as ‘validators’) will verify the sequencer’s submissions based on their own synchronized network status.

If the verification fails, validators will trigger a challenge process on L1 to prevent the incorrect states from being confirmed.

While all optimistic rollups claim to employ fraud proofs, only Arbitrum has effectively implemented it on mainnet. It’s worth noting that their challengers are limited to specific whitelisted addresses.

Fraud proofs in current optimistic rollup projects can be divided into two categories:

1. Non-interactive fraud proof

When a new state submitted by the sequencer is challenged, L1 executes all corresponding L2 transactions to generate a valid state for comparison.

If fraudulent behavior is detected, non-interactive fraud proofs require the L1 to fully re-execute all transactions in the relevant batch, incuring significant high gas costs.

In addition, due to L2 and L1 not always being completely equivalent, some transactions result in different outcomes when executed in L2 and L1. Other times, L1 cannot execute L2 transactions, leading to problematic differences.

In fact, Optimism (OP) abandoned this implementation given these issues, meaning the Ethereum-scaling giant network runs without an available fraud proof system.

2. Interactive fraud proof

To address the issues with non-interactive fraud proofs, multi-round interactive fraud proofs have been introduced.

The core idea is to determine the specific instruction execution that causes an error. Since transaction execution in the EVM is broken down into several instructions to complete state transitions, the process requires multiple rounds of interaction between the sequencer and the challenger. After identifying the issue, the next step is to verify potential fraud by executing the corresponding instructions on L1.

The advantage of this method is that L1 requires only a minor operation, drastically cutting computational expenses. Furthermore, by refining L1 execution to the EVM instruction level, the errors between L1 and L2 outcomes are significantly reduced.

Despite the obvious benefits of this system, some clear challenges still exist. The logic of interactive fraud proof is much more complex than its non-interactive counterparts. This complexity results in:

A more challenging implementation process
The need for an extended challenge period to ensure the completion of all complex interactions.
Elevated standards that may impact the motivation of challengers.

Regarding the first point, as of the time of writing this article, only Arbitrum has implemented a complete interactive fraud proof mechanism on its mainnet while other major optimistic rollup projects have operated without this mechanism for over a year. Meanwhile, several universal zk-rollup have already launched on the mainnet.

For the second and third points, it’s essential to understand the role of interactive fraud proofs in cryptoeconomics. We’ll explore the root causes of these challenges and how RVP can offer improved solutions in the following sections.

Why is RVP a better solution for optimistic rollup than interactive fraud proof?

Despite the potential of optimistic rollups, current approaches, including both non-interactive and interactive fraud proofs, leave room for refinement.

On one hand, engineering complexities mean many projects lack core mechanisms to ensure the security of user assets on the mainnet.

On the other hand, interlayer asset transfers (withdrawals) require users to face confirmation of up to a week, a far cry from user expectations.

Recognizing these challenges, Morph proposes a pioneering solution — the Responsive Validity Proof (RVP).

Understanding RVP

RVP seamlessly blends zk-based validity proofs with optimistic rollups.

When challengers discover inaccuracies in the data submitted by the sequencer, they can initiate a challenge request directed at the sequencer on L1.

The responsibility then falls on the sequencer to produce the requisite ZK-proof within the predefined time (challenge period) and submit it for L1 contract verification. A successful verification nullifies the challenge, while failure substantiates the challenger.

General Architecture of Responsive Validity Proof

While the overview provides a glimpse into RVP’s architecture, the complete process does involve more complexity.

Our future articles will delve deeper into the mechanics of RVP, while the current focus has been on the compelling reasons to embrace the system.

Benefits of RVP over Interactive Fraud Proof

Accelerated Challenge Period: With RVP’s unique cryptoeconomic design, the challenge period can be reduced significantly from 7 days to just 1–2 days.
Substantial Cost Saving: Based on validity proof, rollups leveraging RVP do not need to include the majority of transaction bytes, leading to considerable savings in L2 transaction submission costs.
Simplified Challenger Role: Challengers primarily focus on maintaining and identifying the L2 status. The only added responsibility is the triggering challenges, while sequencers bear the burden of proving their accuracy through ZK-proof generation and verification.
Fluid Architectural Transition: Migrating to a full ZK-rollup becomes straightforward with RVP. The only adjustment required is shifting the sequencer’s ZK-proofs submission approach from responsive to proactive.

How can RVP shorten the challenge period of optimistic rollup?

Understanding the purpose of a challenge period in optimistic rollups is crucial. At its core, the challenge period (or withdrawal period) serves as a window of opportunity for challengers to identify any malicious submissions by sequencers. It allows them ample time to execute the fraud proof and challenge procedure to ensure malicious submissions are not accepted.

The duration of the “withdrawal period” is influenced by two main factors:

The time required by both the sequencer and challenger to complete the challenge process.
The assurance that any malicious behavior that disrupts the regular challenge process (such as sequencers purposefully blocking the challenger’s transactions on L1), can be circumvented within this timeframe.

RVP addresses these factors through two key strategies:

Streamlined Challenge Process:

For a hypothetical multi-round interactive fraud proof that requires 10 rounds of interaction, at least 20 blocks of time would be needed to settle the challenge. This doesn’t even account for the intervals of waiting for the other party to respond and process results between each interaction, which further elongates the timeline.

RVP, in contrast, has a complete challenge process that requires only one interaction — the sequencer uploads the ZK-proof for the batch and verifies it on L1.

This removes a fundamental issue that previously affected the length of the challenge period: whether the challenger would have enough time to detect and prove the inaccuracy of the batch rolled up by the sequencer.

Stopping the Sequencer’s Malicious Behavior:

In the interactive fraud-proof system, the challenged party may have the means and motivation to interfere with the challenger’s progress.

For example, they could deploy a DDoS attack on L1 to obstruct the challenger’s interaction with L1 and ability to complete the challenge process.

With RVP however, the challenger only needs to trigger a challenge, meaning a sequencer has no means of impeding the challenge process. The sequencer then is forced into a position where its only recourse is to prove its legitimacy through the ZK-proof.

Why Are Operating Costs Lower for RVP-based L2s?

One major advantage of ZK-rollups over optimistic rollups is the ability to compress transactions submitted to L1 more effectively.

For example, the length of an Ethereum transaction is ~110 bytes, with the signature accounting for ~68 bytes. In optimistic rollups, since the transaction needs to be replayed, the transaction’s signature must be included to ensure the replayed transaction on L1 remains valid.

ZK-rollups, on the other hand, lean on the ZK-proof to validate transaction legitimacy. This mechanism allows for the retention of only fundamental transaction data, thereby greatly reducing the cost of L2 submissions.

RVP taps into the same ZK-proof modality to affirm transaction integrity. This means the ZK-rollup advantage can be harnessed to compress transactions during batch data submission.

Furthermore, in the absence of challenges, the sequencer can bypass any considerations on the cost of submitting and verifying ZK-proofs. As a result, an RVP-based rollup has a superior cost efficiency than its existing optimistic rollup and ZK-rollup counterparts.

RVP’s Challenger-Firendly Approach

At its core, RVP operates on the principle of validity proof, which is anchored in proving the legitimacy of the data being contested.

Therefore, in the RVP framework, the sequencer bears the responsibility of generating and verifying proofs. The challenger’s role is merely to initiate a challenge by staking.

In contrast, fraud proof, and more specifically interactive fraud proof, requires challengers to navigate a series of interactions with the Layer 1 contract to complete the challenge. This process is often cumbersome and complex, with much more stringent demands on the challenger.

In the landscape of L2 projects, the potential of high returns fuels sequencers’ motivation to cheat. Conversely, challengers find themselves in a position where their direct benefits are relatively much lower than sequencers’ (therefore, in some project designs, L2’s “stakeholders” — like operators of fast bridges — step in as challengers), resulting in a diminished incentive for challengers.

In light of this, lowering the requirements for challengers and increasing the accountability of sequencers is a more rational approach.

It is worth noting that in such a model, challengers may escalate a sequencer’s cost by initiating unwarranted challenges. If a challenge is unsuccessful, the challenger will not receive any benefits and must compensate the sequencer for the cost incurred in creating the ZK-proof. This creates a self-regulating mechanism, mitigating concerns of abundant malicious challenges.

Why Must Sequencers Take On the Responsibility of Submitting ZK-proofs?

There is a proposal suggesting challengers could demonstrate the falsehood of a sequencer’s submission by presenting their own version with an associated ZK-proof. The two can then be compared side-by-side to easily identify any fraudulent activity by the sequencer. Unfortunately, there are obvious challenges in this approach.

The core issue lies in the necessity for challengers to generate ZK-proofs from the transactions provided by the sequencer. If these are invalid transactions, challengers cannot create ZK-proofs that can pass L1 validation based on erroneous data. Ultimately, the responsibility to prove their own submissions must fall on the sequencer.

Why Not Employ ZK-rollup, Considering the Many zkEVM Projects Already on Mainnet?

The ZK-rollup framework, which forcibly requires verification of every state submission by a sequencer (through a significant number of cryptographic calculations), offers a higher level of security in theory. However, the approach has the following drawbacks:

High Transaction Costs

Projects such as zkSync and Polygon zkEVM have already launched on the mainnet, suggesting that generating and verifying ZK-proofs is no longer the most challenging factor. Instead, current ZK-proofs are limited by cost and efficiency issues preventing the ability to fully shoulder the responsibility of scaling Ethereum as of now.

Considering zkSync Era, the average netowork transaction cost is currently between 0.5~1 USD. When the gas fees of L1 increase significantly, a transaction can even reach 3~10 USD. This is noticeably higher compared to transaction costs associated with optimistic rollup platforms like Arbitrum and Optimism.

In contrast, RVP does not bear such high costs under normal network operations, instead, it effectively leverages the characteristics of ZK-proofs by compressing transaction data. It is only if a challenge arises that costs will be elevated. In real-world scenarios, normal network operations account for more than 99.9%, approaching 100%.

Block Finalization Times

Theoretically, ZK-rollups have no withdrawal periods as the entire L2 state transition verification process through ZK-proofs should be completed within minutes or seconds.

However, current technical limitations have significantly slowed down the time required for ZK-proof to be verified on L1. For example, with zkSync Era, L2 block finalization takes about 20–24 hours, not a marked improvement over the optimized withdrawal periods.

Seamlessly Transition from RVP to ZK-rollup

L2 scaling solutions incorporating RVP technology can be designed using the ZK-rollup framework. This makes seamlessly transitioning from an RVP-based L2 to a standard ZK-rollup L2 straightforward.

The only necessary adjustment is changing the sequencer’s ZK-proof submission method from responsive to proactive. As the technology matures, with RVP at the core, L2s can effortlessly transition to ZK-rollups.