What is ZK Rollup? (2) | TriathonNow!
We discussed the Bitcoin lightning network in the previous post. So can we transplant it to the Ethereum ecosystem? Let’s explore this in detail.
There are groups of people exploring to do this. And Plasma is among them. It is a mapping of the Lightning Network on Ethereum. However, Plasma was unable to do so at a later stage of development for the following reasons.
In the Lightning Network,
- Both parties deposit the chain.
- All transactions between the two parties are off-chain and only need to be verified and recorded by the two parties.
- If a party wants to withdraw, it submits the current “status” of the chain and waits for some time to get its deposit back; during this time, the other party can object and submit a “fraud proof” to prove that the status submitted by the other party is not up-to-date and take away the deposit staked by the other party.
It is called the private channel.
While because of the smart contracts, transactions are all processed by Ethereum Virtual Machine, aka EVM. One transaction may influence many other transactors. So the off-chain transactions will be woven into a network instead of numerous channels. Every node’s status will be recorded in the network and every transaction will affect its status. There is certainly no way for any regular user to handle so many transactions and keep the status updated. So here comes the Rollup.
Rollup bundles or “rolls up” transaction data into a single block, processes it off the chain and then verifies it on the chain. There are mainly two types: Optimistic Rollup and ZK Rollup.
Optimistic Rollup(OR) updated the Plasma solution and targeted solving two sticky problems.
Since all transactions are recorded on the chain entirely, users just do not verify them. Therefore, Plasma’s data availability problem does not exist. Even if the original verifier runs away, anyone can become the new verifier by verifying it again based on the records recorded on the chain.
In addition, the quite cumbersome appeals process that existed before is gone. If someone is working with a verifier to do evil, they will inevitably cause the status information (such as account information) after a particular batch of transactions to not match up with those transactions themselves.
And since the summary of status information and transactions are on the chain, the complaining party can quickly point out the inconsistency between the two with the summary information of status changes.
But it’s not free. Originally, off-chain technology like Lightning Network or Plasma is “infinitely scalable.” For example, 10,000 transactions could occur in the state channel of two parties in the LN. As long as the amount was less than the deposit, there would always be two transactions on the chain, the ones where both parties deposited to open the state channel, but in the OR, there would still be 10,000 transactions recorded on the chain, and none of them would be missing.
Take it more technically, without considering the appeals, the occupation of on-chain resources by a certain number of transactions(say n) in the LN is O(1), that is, after creating a channel or moving assets to layer 2, no matter how many transactions there are, they will not occupy the off-chain resources. As for the OR, the occupation of resources on the chain is O(n), which is no improvement in terms of order of magnitude. In other words, initially, 10,000 transactions occupy 10,000 copies of resources. Now 10,000 transactions still occupy 10,000 copies of resources.
While the OR adopts the Fraud Proofs, although it solves the critical problem faced by Plasma, there was a challenge period for users to withdraw funding, roughly a week.
ZK stands for zero-knowledge. It is zero-knowledge proof or zero-knowledge protocol. Rollup, which is implemented based on zero-knowledge proofs, abandons the Fraud Proofs and implements the chain with Validity Proofs, free from the challenge period to withdraw their funds instantly.
In ZK-Rollup, the chain summarizes the transactions and all state changes after a batch of transactions. So, what needs to be proven in the zero-knowledge proof is “I know a series of transactions after which the summary of the state of all transactions will change from A to B.” For example, “I know that a certain series of transactions will change Alice and Bob’s accounts from (1000, 1000) to (900, 1100) after all the processing steps of those transactions.” For this assertion, the verifier can generate a proof P by a zero-knowledge proof.
Then, P and the state summaries A and B are sent to the chain along with all the transactions so that all the nodes do not need to verify these transactions but can determine the authenticity of state A to state B by verifying P.
This approach differs from the OR in one significant way:
Again there are a bunch of transactions that are packaged up again. These transactions will change the status of all accounts from A to B, and again the calculation of the specific change is taken off-chain and replaced with proof.
The difference is that ZK-Rollup uses the logic of “Validity Proof” while the OR uses the logic of “Fraud Proof,” i.e.
In the OR, one or more verifiers guarantee using signatures that “state A will become state B after these transactions, I verified it.”
Then, within a challenge period (usually a week or two), if someone says “your guaranteed result does not match the actual transaction execution” and provides evidence, the incorrect result will be rolled back and the challenger will receive a portion of the deposit staked by the guarantor on the chain.
In ZK-Rollup, the validator generates a proof P. It uploads it to the chain together with state A and B and transaction through a zero-knowledge proof off the chain, which is equivalent to “state A will become state B after these transactions, and you can confirm this by verifying P.”
In ZK-Rollup, no challenge period is needed because cryptography ensures that verifying P is equivalent to verifying that state B is derived via transaction.
In a word, ZK-Rollup hugely improves the transaction speed of Ethereum. In zkSync, Layer 2 packages multiple transactions into one block and then transfers them to Layer 1’s smart contract for verification, which is equivalent to Layer 1 doing what it used to do with one block with one transaction the performance will be improved by hundreds of times.
Now zkSync 2.0 has been publicly tested on the testnet. I believe we will be able to use it on the mainnet shortly. Are you ready?