How Does RVP Run in Morph?

Disclaimer: Please note that Morph is currently being working in progress, so this is the latest version of the protocol design, subject to possible future updates.

General Procedure

1. Validators are expected to perpetually verify the transactions and new state sequencers submitted to Layer 1.
2. The validators will trigger the challenge upon discovering discrepancies in transactions and states.
3. Sequencers are obligated to respond to the challenge by providing ZK-proof and passing verification successfully.
4. A sequencer’s inability to conclude the verification procedure within a certain period affirms fraudulent behavior.

Pre-Challenge

Sequencer

Upon the sequencer’s election, immediate staking of a preset asset quantity is required.

This acts as a cryptographic economic assurance for the legitimacy of their batch submission.

If the sequencer’s batch is validated as fraudulent, their stake will be seized, and, given the circumstances, they may be expelled from the sequencer network.

Validator

Validators obtain each batch submitted by the sequencer through the calldata of the committed sequencer transaction, extracting the transaction data and the batch state as claimed by the sequencer.

Initially, validators authenticate these transactions independently. If this verification fails, they have the right to initiate a challenge.

Validators execute batch transactions based on their previous batch state to derive a new state tree, from which a new stateroot is extracted.

By comparing the new stateroot (validator) with the batch stateroot (sequencer), it can figure out whether the sequencer has committed fraud.

If both stateroots are identical, the validator takes no action and waits for the following sequencer batch submission verification.

If a discrepancy is identified, the validator initiates a challenge via the challenge method of the challenge contract while depositing a specific amount of assets to the challenge contract as collateral.

Challenge Procedure

Upon receipt of a challenge request, the contract on Layer 1 formulates a challenge comprising the initiating challenge address, the time of challenge initiation, stake amount, challenge batch, challenge status, and other relevant data, sparking a challenge event.

The sequencer can ascertain if the submitted batch is under challenge by tracking the event.

If challenged, the sequencer is mandated to perform the following tasks before the expiration of the challenge period:

1. Call ZK prover to begin a request to generate the ZK-proof for the batch and provide corresponding parameters.
2. Obtain the ZK-proof from the ZK prover upon its generation.
3. Submit the ZK-proof to the Layer 1 contract for verification.

As long as the challenge period is not ended, the sequencer is permitted to initiate proof verification operations.

How to determine if a challenge is successful?

A challenge is deemed successful under any of these circumstances:

• The sequencer fails to submit a ZK-proof within the challenge period.

• The sequencer submits a ZK-proof during the challenge period but fails its verification.

• The sequencer submits a ZK-proof during the challenge period while it is still under verification until the end of the challenge period and fails.

These scenarios summarize the sequencer’s failure to submit a valid ZK-proof within the challenge period.

A challenge is only regarded as failed if:

• The sequencer submits a ZK-proof within the challenge period, which ultimately passes the proof validation.

Post-Challenge

If the challenge fails

A successful challenge by a validator rewards them generously while fortifying network security.

However, fraudulent challenges can disrupt the network’s smooth functioning.

For instance, a malicious challenge against the sequencer may compel the sequencer to incur the cost of ZK-proof generation and delay the confirmation of the challenged batch.

Thus, validators are required to stake funds when initiating challenges. The validator’s staked funds will be wholly compensated to the sequencer if the challenge proves unsuccessful, signifying no fault with the challenged batch.

If the challenge succeeds

Typically, a sequencer seeks to reap long-term benefits by reliably offering services. However, fraudulent situations cannot be completely ruled out.

Dependent on the causes, successful challenges necessitate varying responses:

First of all, regardless of the reason for the successful challenge, the main contract is temporarily halted to prevent subsequent batches from being submitted to Layer 1.

This pause operation is executed by the account controlling the main contract, regulated by decentralized governance, and all other ongoing challenges are dismissed, with stakes returned to each party.

A successful challenge signifies that no valid ZK-proof was validated within the designated time, typically due to the following:

1. The sequencer’s liveness issue resulted in delayed proof submission.
2. The sequencer submitted an incorrect commitment, causing the inability to generate the correct proof.
3. Collective fraudulent actions by the sequencer compromised Layer 2 consensus, causing the inability to generate the correct proof.
4. Layer 2’s vulnerability resulted in a dysfunctional mechanism.

Specific scenarios necessitate professional investigation and ultimate on-chain reflection via decentralized governance voting.

The handling methods for these four situations are as follows:

The sequencer’s liveness issue resulted in delayed proof submission.

• The decentralized governance-controlled address generates a corresponding ZK-proof for verification, and the sequencer corresponding to this batch will be penalized with a portion of their staked funds transferred to the corresponding challenger, with an additional portion of their staked funds penalized and transferred to the decentralized governance treasury for covering the cost of ZK-proof and other purposes.
• In this scenario, the Layer 2 status synchronized by each node is not problematic. Hence no action is required from other network participants.
• Upon ZK-proof verification, the main contract is restarted by decentralized governance and resumes normal operation.

The sequencer submitted an incorrect commitment, causing the inability to generate the correct proof.

• The corresponding batch’s sequencer will have a portion of their staked funds penalized and transferred to the corresponding challenger, with an additional portion of their staked funds penalized and transferred to the decentralized governance treasury.
• The investigation team will continue to validate the previous batch’s state, ultimately providing a batch validity report to decentralized governance. Once decentralized governance approves, Layer 2 will be restarted, and all Layer 2 states will be deemed valid.

Collective fraudulent actions by the sequencer compromised Layer 2 consensus, causing the inability to generate the correct proof.

• All sequencers involved in wrongdoing will have a portion of their staked funds penalized and transferred to the corresponding challenger and an additional portion of their staked funds confiscated and transferred to the decentralized governance treasury.
• The investigation team will continue to authenticate the validity of previous batches and ultimately provide a batch validity report to decentralized governance. Once decentralized governance approves, Layer 2 will be restarted with all Layer 2 states being valid.
• All nodes are required to continue operating according to the new Layer 2 state.

Layer 2’s vulnerability resulted in a dysfunctional mechanism.

• After validating that a fault lies with the Layer 2 service itself (e.g., coding error), the relevant party responsible will compensate the loss towards decentralized governance and refund the corresponding challenge’s stake to both parties.