The best of both worlds: zk rollup pre-consensus mechanism

How to achieve secure instant finality and long authentication intervals in zkRollup

The best of both worlds: zk rollup pre-consensus mechanism

1) Too long not to read.

This paper outlines a pre-consensus mechanism that enables immediate finality and reduces the cost of verifying gas without affecting the immediate funding exit of zkRollup.

2) Background and motivation.

Instant finality can be achieved with zkRollup for sufficiently short commitment intervals (e.g., 10 minutes). In this scenario, the trust risk of aggregators increases as the interval grows, and the cost of achieving finality (in the case of the Groth16 algorithm, the cost of verifying gas per commitment exceeds 200,000 gas) decreases as the interval grows.

Let us first show that the pairwise verification cost of zkRollup exceeds 200,000 gas (a value of $100 to $500). That is, it costs the aggregator that much gas to verify and finalize the commitment for each commitment interval in zkRollup.

We cannot ignore this cost because zkRollup’s commitment interval is very short. We need commitments to achieve immediate exit finality. We can achieve immediate finality (economic finality, zero confirmed transactions) as long as the commitment interval is short and the malicious aggregator is not motivated to rollback transactions.

Although we can use recursive zero-knowledge proofs and efficient proof computation systems to aggregate multiple transactions, it is also difficult for us to change the commitment interval. If we blindly extend the commitment interval, we will compromise security.

Then, we need to think about how to achieve secure immediate finality and longer verification intervals in zkRollup.

3) Method.

The operational cost of aggregators stems from the high gas cost of zero-knowledge proof verification on the contract and the short commitment interval.

Therefore, we can extend the verification interval without compromising security and availability.

3.1) Step 1: Skip zero-knowledge proof pairwise verification

First, the easiest solution we can think of is to skip the pairwise computation and introduce a simple fraud proof against the commitment.

The aggregator submits to the contract whatever is needed to prove or verify the zkRollup promise, but at this point does not perform the pairing computation, and thus does not need to pay 200,000 gas. after some time, this promise is verified; each state in this promise will become a public input for the next promise. The aggregator needs to lock up some Ether to incentivize the verifier. Once the verifier discovers fraud, the aggregator is punished.

The promise is a hash of the public input, zero-knowledge proof data, the previous state root, the next state root, the transaction hash, and the aggregator address.

The original image is provided by the on-chain event and the commitment is kept within the contract store.

This approach has great advantages.

Everyone can be a watchtower, the equivalent of a “verifier” in Optimistic Rollup, without having to run a full node or do any special start-up setup.

Data availability issues do not occur because all the data needed to validate or perform fraud proofs is in the events issued on the chain. When performing fraud proofs, we do not need Layer 2 transaction data and transaction results because they are all contained in the public input and proof of the zero-knowledge proof.

If a malicious aggregator submits a malicious Merkle root and drops all transaction data and Merkle tree data, we do not need to run the full node to perform the fraud proof. We only need to examine the zero-knowledge proof data and execute the pairwise verification function to detect such malicious behavior.

However, the above approach has security issues.

If a 51% attack occurs on Layer 1 that legitimizes a malicious Merkle root, it is difficult for us to stop it.

Since the execution cost of a 51% attack increases with the block-out time of the underlying blockchain, we need a long enough verification period to effectively make a 51% attack more difficult. The ideal validation period is 7 days, since the exit period of ORU is also 7 days, which can be calculated based on the mining cost and the actual attack reward.

In this case, there is no reason to give up ORU in favor of the above scenario.

3.2) Step 2: Pre-consensus commitment without zero-knowledge proof verification, finality by recursive zero-knowledge proof pairing

We can solve the above security problem by the following way.

We consider this commitment without zero-knowledge proof verification as pre-consensus. Pre-consensus will restrict finality by zero-knowledge proof verification.

(consensus commit ) => (pre-consensus commit ) => (pre-consensus commit ) => …. => (pre-consensus commit ) => (consensus commit )

All pre-consensus commits will limit the consensus by pairing. As a result, Layer 2 users can enjoy secure and immediate transaction finality. We need to verify the consensus commitment using all pre-consensus commitments with recursive zero-knowledge proofs. There are two circuits here: a pre-consensus circuit and a recursive circuit. The pre-consensus circuit contains the logic of the dApp that uses the zkRollup scheme. The recursive circuit only needs to get the pre-consensus data from Layer 1 as the common input.

The recursive zero-knowledge proof can be used to perform horizontal merging of pre-consensus over time: at the same time, it can be used to vertically aggregate a large number of transactions into a pre-consensus commitment.

If any false pre-consensus commitment affects the consensus verification with pairing, we can always pair it for fraud proofs via zero-knowledge proofs. Once the proof is successful, the aggregator removes the commitment using the zero-knowledge proof verifier function and then restarts the transaction aggregation and creates the pre-consensus commitment.

If they are in a hurry, asset holders can spend 200,000 gas to reach consensus via pre-consensus, and then they can exit immediately. (Of course, they can also wait for the aggregator to reach consensus. As mentioned in “Step 1”, they do not need any special setup to achieve consensus finality, since all inputs are aggregated and searchable by on-chain events. No matter how many pre-consensus commitment proofs are verified, the gas cost of recursive verification does not increase, because these proofs are hashed into the entry hash.

51% An attacker cannot knock down a malicious Merkle root because each root is eventually verified on-chain by contract code logic implemented by the zk circuit.

4) Summary.

This pre-consensus protocol with fraud proof and associated data accessibility allows zkRollup to have a long commitment interval (e.g., 6 hours). This approach can result in significant savings in the cost of gas required for verification computation.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-05-07 09:33
Next 2021-05-07 09:45

Related articles