Ontology Tech Viewpoint | Who’s Optimistic about ZK-Rollups
The explanation of the Ethereum Merge clearly states that upgrading via “The Merge” mainly brings about a change in the network consensus mechanism. The highly anticipated expansion was completed by the close collaboration between Ethereum and the various Layer2 solutions.
All of a sudden, all the major events in the Layer2 arena were put back on the agenda. Meanwhile, zkSync, one of the most famous Layer2 projects, once again became the focus of the market by launching its version 2.0 MainNet on October 28.
This article will be based on the possibilities of Ethereum scalability to help you further understand the ZK-Rollup solutions in Layer2.
Capacity expansion scheme
All of you have heard about the expansion of Ethereum, whether you are a new employee or a veteran practitioner. Words like Rollup and Layer2 should be familiar to you.
As decentralized applications (dApp) deployed on Ethereum gradually increase, congested networks and high gas fees make Ethereum expansion imperative.
However, due to the impossible trilemma of the blockchain (only two from expansion, decentralization, and security can coexist), it is difficult to expand capacity at the Layer1 level, so Layer2 takes advantage of the challenge. The core idea is to put a large number of actual interactions off the chain for execution and calculation, and then finally finish validity verification through a very small number of interactions on Ethereum.
In the Layer2 expansion scheme, the more mainstream and popular ones are Optimistic Rollup and ZK-Rollup, the former is the largest ecological solution in Layer2 projects for now, while the latter is considered by Vitalik as the ultimate solution to the expansion problem.
Rollup
So, what is a Rollup? It is a scalable solution that bundles interactions, presses, and sends them to the consensus layer for validation, verifying multiple interaction behaviors at a time.
In essence, instead of sending the interactions to the node in L1, the user sends them to the Rollup server that verifies that these interactions are valid, in other words, these validations are performed outside of Ethereum’s MainNet. After verification, the Rollup server publishes the data to Ethereum’s MainNet, which records the interaction and verification status, so that they will inherit the security of L1.
A simple example:
Richard got a meal card in the canteen downstairs and loaded it with 1,000 USD. Every time he eats, Richard only needs to swipe his meal card without having to pay the money again with his bank card. A month later, Richard did not intend to continue eating in the canteen and had 200 USD in balance when he canceled the card, so he withdrew the balance back to his bank card.
In this process, Richard’s bank card and the canteen account only interacted twice, despite the fact that during that time there was countless buying of meals using the system inside the canteen.
Here is also a key step: when extracting the balance, Richard needs the canteen to provide details to verify that the balance settlement is not wrong, and the detail needs to be submitted to the bank card system for preservation and verification.
Why is detail verification the critical step?
Before Rollup was proposed, there was a capacity expansion scheme called Plasma, which does not send the data occurring on the chain to the main chain for storage and verification, but will only submit a final status result. This makes the results unverifiable, just like the canteen is only giving you the final balance, but not the details.
The Rollup scheme submits the data to the main chain, but it compresses the data as much as possible through smart coding methods, while appropriately deleting and reducing some of the data based on the characteristics of the Rollup itself, as long as the final submission can be verified by anyone.
ZK-Rollup optimizes security and accuracy around validation.
ZK-Rollup
ZK-Rollup packages a large number of transactions into one Rollup block and generates a concise proof for the block off the chain. Smart contracts on Layer1 can simply verify the certificate, without re-executing these interactions.
This can not only save gas fees because the proof verification cost is well below the computational cost of re-execution; but another benefit is to save storage space through data compression (i. e., store only the smallest amount of data on the chain for verification).
A key point of ZK-Rollup lies in “questioning everything”, which contrasts with Optimistic Rollup’s “optimistic assumption that nobody does evil”. ZK-Rollup defaults that all submitted results are ok, but requires Layer2 to carry a zk-SNARK proof after submitting the data to prove the accuracy of its results.
Back to the example:
If Richardtakes the balance directly, does not check the details, but waits until something is wrong, it is similar to Optimistic Rollup; but if Xiao Ming asks the canteen to ensure the accuracy of the balance, it is similar to ZK-Rollup.
You may be wondering, why can the certification documents provided by the canteen prove that the data they give is right? This involves the ZK (proof of zero knowledge).
The simplest zero-knowledge proof is that there is a password door in the middle of a channel, if Richard needs to prove that he knows the password, he does not have to tell others what the password is, but just needs to pass the password door. Of course, the zero-knowledge proof put into practical application is much more complicated than this. For further information, refer to this article by Vitalik:
https://link.medium.com/kTqKFY2XDub
After reading it, you will see why ZK-Rollup was proposed very early and praised by Vitalik, but it made little progress compared to Optimistic Rollups: the difficulty and principle of ZK is still being solved and much more complicated than imagined.
Follow us on social media!
Ontology website / ONTO website / OWallet (GitHub)
Twitter / Reddit / Facebook / LinkedIn / YouTube / NaverBlog / Forklog
