[Research] zk-rollup Overview

ZK-rollups VS optimistic rollups

Zero-knowledge rollups (ZK-rollups) are similar to optimistic rollups in that they combine a large number of Layer 2 transactions that were executed off-chain and submit them as one transaction onto Ethereum. 

However, instead of assuming transactions are valid until proven otherwise, ZK-rollups use validity proofs to instantly prove if transactions are valid or not. 

 

The optimistic roll-up, discussed earlier, can be delayed because anyone who withdraws funds is allowed to challenge the exit transactions as evidence of fraud.

However, there is no delay when moving funds from ZK Rollup to Ethereum because exit transaction is executed when the ZK Rollup contract confirms the proof of validity.

In other words, instead of posting all transaction data on-chain like a optimistic rollup, a ZK rollup only needs to provide proof of validity to complete a transaction on Ethereum.

 

 

ZK-rollups overview

Users in the ZK-rollup sign transactions and submit to L2 operators for processing and inclusion in the next batch. In some cases, the operator is a centralized entity, called a sequencer, who executes transactions, aggregates them into batches, and submits to L1. The sequencer in this system is the only entity allowed to produce L2 blocks and add rollup transactions to the ZK-rollup contract.

 

(Here, "rollup transaction" is a aggregation of transactions and made into batches.)

 

The rollup transitions to a new state after the execution of a new set of transactions. The operator who initiated the state transition is required to compute a new state root and submit to the on-chain contract. The new state root that the ZK-rollup operator submits to the L1 contract is the result of updates to the rollup’s state. 

But a more important process remains. Looking at the process so far, it is possible that a malicious operator may submit an invalid new state root.

Therefore, it is necessary to verify whether the new state root derived by the operator is calculated correctly in the L1 contract. In other words, the rollup contract won’t automatically accept the proposed state commitment until the operator proves the new Merkle root resulted from correct updates to the rollup’s state. The ZK-rollup operator does this by producing a validity proof, a succinct cryptographic commitment verifying the correctness of batched transactions.

 

Validity proofs allow parties to prove the correctness of a statement without revealing the statement itself—hence, they are also called zero-knowledge proofs. ZK-rollups use validity proofs to confirm the correctness of off-chain state transitions without having to re-execute transactions on Ethereum. These proofs can come in the form of a ZK-SNARK(Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) or ZK-STARK(Zero-Knowledge Scalable Transparent Argument of Knowledge).

 

 

https://ethereum.org/en/developers/docs/scaling/zk-rollups/#validity-proofs

Home | ethereum.org

The general process for validity proof is well documented in the material above. So let's go a little deeper into validity proof by looking at the example of scrolling.

 

 

Scroll’s architecture

The current architecture consists of three infrastructure components :

 

 

• Scroll Node: Constructs L2 blocks from user transactions, commits them to the Ethereum base layer, and passes messages between L1 and L2. 
• Roller Network: Generates the zkEVM validity proofs to prove that transactions are executed correctly.
• Rollup and Bridge Contracts: Provides data availability for Scroll transactions, verifies zkEVM validity proofs, and allows users to move assets between Ethereum and Scroll.

 

Considering the previous context, the scroll node means the role of "zk-operator" or sequencer. However, in scroll, it is characterized by being divided into Sequencer, Coordinator, Relayer, and Roller. 

Briefly, as mentioned above, the sequencer retrieves the batch of transactions and generates a new state root. However, the proof validity is done through Coordinator and Roller.

We'll go deeper into this later, let's just focus on the rollup process. 

 

 

Before accepting transactions, the Sequencer(operator) will perform the usual checks. This includes confirming that:

• The sender and receiver accounts are part of the state tree.
• The sender has enough funds to process the transaction.
• The transaction is correct and matches the sender’s public key on the rollup.
• The sender’s nonce is correct, etc.

 

L2 blocks in Scroll are generated, committed to base layer Ethereum, and finalized in the following sequence of steps:

 

1. The Sequencer generates a sequence of blocks. For the i-th block, the Sequencer generates an execution trace T and sends it to the Coordinator. Meanwhile, it also submits the transaction data D as calldata to the Rollup contract on Ethereum for data availability and the resulting state roots and commitments to the transaction data to the Rollup contract as state.
2. (Proof generation) The Coordinator randomly selects a Roller to generate a validity proof for each block trace. 
3. (Proof generation) After generating the block proof P for the i-th block, the Roller sends it back to the Coordinator. Every k blocks, the Coordinator dispatches an aggregation task to another Roller to aggregate k block proofs into a single aggregate proof A. 
4. (Proof verification) Finally, the Coordinator submits the aggregate proof A to the Rollup contract to finalize L2 blocks i+1 to i+k by verifying the aggregate proof against the state roots and transaction data commitments previously submitted to the rollup contract.

 

 

As in step 4, the Coordinator submits the computed validity proof to the verifier contract on L1. The contract's verification circuit verifies the proof's validity and also checks public inputs that form part of the proof:

• Pre-state root: The ZK-rollup’s old state root (i.e., before the batched transactions were executed), reflecting the L2 chain's last known valid state.
• Post-state root: The ZK-rollup’s new state root (i.e., after the execution of batched transactions), reflecting the L2 chain's newest state. The post-state root is the final root derived after applying state updates in the proving circuit.
• Transaction inputs: Data associated with the transactions executed as part of the submitted batch.

 

If the proof satisfies the circuit (i.e., it is valid), it means that there exists a sequence of valid transactions that transition the rollup from the previous state to a new state. If the pre-state root matches the root stored in the rollup contract, and the proof is valid, the rollup contract takes the post-state root from the proof and updates its state tree to reflect the rollup's changed state.