No doubt that Ethereum has become the superstar public chain that runs thousands of smart contracts on it. However, the traffic is so busy that “traffic jams” could often been spotted, even a “highway” like Ethereum must confront a long queue of transactions to be packed and sent, even though the toll (gas fee) could be enormous. The network congestion was not beyond expectation. An earlier incidence dating back to 2018 , a game named Crypto Kitten, had the privilege to bring about the weakness of Ethereum in handling mass transactions, let alone the number of users and Dapps have soared to several times of those in 2018. Ethereum has bear the burden of being the avant-garde, dragging it slower and slower as time goes by ; an update to alleviate the congestion cannot wait. not dropped significantly; when denominated in US dollars, the handling fee has risen to a certain extent due to the increase in the price of ETH.
What if there is a Layer 2 solution that could offer fast and secure transaction with low gas fee, highly compatible with vast majority of smart contracts and Dapps yet private enough without the controversial week-long waiting time, would you make it in your wish list? In fact, this nearly perfect Layer 2 solution could probably be live in the market in the near future.
What could Layer 2 and Rollup Do?
The most well-known ETH 2.0 is like a massive renovation of “the highway”; the process will eventually be slow since the renovation is naturally difficult to implement and benefits of various parties are involved. If it were to exempt a direct renovation on “the highway” by implementing ETH 2.0, a Layer 2 solution is more or less an indirect solution that it creates overpasses above “the highway” in order to achieve scaling. The mainstream Layer 2 scaling technique is Rollup: it handles more transactions without taking up space by compiling data. In other words, larger data packs could commute like a bus on " the highway" instead of cars with limited capacity, thus more passengers, data, in this case, could be transported.
Rollup could be classified by whether it interacts with proofs submitted to Layer 1. There are 2 Rollup technical tracks. One is the Interactive Rollup. For short, we identify one-round interaction and multi-round interaction as Optimistic Rollup (OP Rollup), Arbitrum, Boba Network and Optimism are some outstanding projects in this category: the number of projects in the ecosystem and TVL skyrocket in this year, and the TVL of this three projects occupied almost 70% of the whole Layer 2 market. The other is Non-interactive, also know as ZK Rollup; exemplary projects in this track are dYdX, Loopring and zkSync. They have a comparatively smaller market share.
If Optimistic Rollup were the innocent and romantic Juliet girl, longing for a love fairy tale with Romeo in a perfect world, ZK Rollup would be more like a considerate office lady, tact and neat. For immature ideas from an innocent girl would consume a large amount of time to be proven, and the result would not be necessarily right. Just as how it performs in Optimistic Rollup: the fraud proof could still be flawed even after a week-long verification period. However, the neat office lady, ZK Rollup, prefers a much faster and result-driven “state proof”. As the nature of verification differs, ZK Rollup outperforms OP Rollup with better performance, lower transaction fee and unconstrained exit time.
Defects of ZK Rollup
Compatibility is the main defect of ZK Rollup compared to OP Rollup. As illustrated in the below, ZK Rollup is only compatible with payment and transaction types of applications, while OP Rollup supports a variety more, lacking appropriate development of ZK Rollup, which leads to the mere 3.6% market share of Layer 2 in the whole Ethereum in terms of TVL.
ZK Rollup submits Zero Knowledge Proof to Ethereum mainnet as an effective proof; the inherent complexity of generating Zero Knowledge Proof triggers low compatibility with most applications. In the intricate process, logic of codes must be first converted to a mathematical circuit, not only including basic calculations such as plus or minus, and also accompanied with convoluted logic such as “and”, “or”, “Not”, Hash, bit operation,and other operations on smart contracts. Moreover, this diagram could only support plus and multiplication calculations, and Ethereum opcode is not Zero Knowledge Proof friendly as it was not designed to do so. Furthermore, the most frequently deployed Hashing method, such as AEW-128 or SHA-256, consist of enormous bit operations(“and” and “or” commands); it would be extremely complicated and substantial when converted to gate constraints in the cir.
We need ZK EVM
The current ZK Rollup has constructed a parallel path above the Ethereum boulevard. However, it is more like a bike trail that could only carries out simple transactions, whereas loaded trucks like smart contracts are too heavy to pass. In this case, should ZK Rollup conquer a larger market share by running smart contracts and produce proofs on Layer 2 in order that verification on mainnet could pass faster, a special virtual machine, ZK EVM, must be in place.
There are two key requirements under this circumstance. First, ZK EVM could be compatible with current EVM that codes on Layer 1 could be executed immediately on Layer 2. Second, ZK EVM must be capable of producing proofs for various operations while consuming less computation and storage resources.
Luckily, thanks to the vast development of Zero Knowledge Proof, a new algorism, “Plonk Zero Knowledge Proof”, has come to earth that accelerates the landing of ZK EVM. “Plonk Zero Knowledge Proof” does not produce the proof by calculating the whole circuit from head to toe; instead, it only verifies constraints in the circuit. That is to say, two points make a line, and to draw a line only need two points. Just as shown in the following chart, as long as the gate constraint and the copy constraint are verified, the whole circuit could be verified. In addition, the new algorism sets a trust mark to the whole unit instead of partially trusted, the verification process thus speeds up.
Tech Tracks of zEVM
There are two mainstream tech tracks:First, EVM friendly projects which embed Zero Knowledge Proof in current EVM. It aims to provide further support to native EVM opcode that codes are still executed in EVM and completely compatible with solidity commands. Applied ZKP and Hermez draw the most attention in this track.
Second, Zero Knowledge Proof friendly projects that build EVM with the foundation on Zero Knowledge Proof friendly opcode. This track focuses on the redesign of virtual machine that codes executed here could generate Zero Knowledge Proof much easier. That is to say, the original Zero Knowledge Proof unfriendly codes would be modified, adapting EVM developer tools in order to maintain compatibility with solidity.
The appealing point of EVM friendly track is compatibility. It is completely compatible with current ecosystem and developer tools, well inherited the credited security model from Ethereum. From the overview of Ethereum ecosystem, this kind of update would be so gradual that current projects could be transferred smoothly before anyone could notice once succeeded. However, as mentioned above, Zero Knowledge Proof will also be generated for those commands deviating from the generation of proofs, which may consume enormous resource along the way. Ethereum. From the overview of Ethereum ecosystem, this kind of update would be so gradual that current projects could be transferred smoothly before anyone could notice once succeeded. However, as mentioned above, Zero Knowledge Proof will also be generated for those commands deviating from the generation of proofs, which may consume enormous resource along the way.
Zero Knowledge Proof friendly track wins over in terms of flexibility. It does not strictly generate proofs for every single command, and code to a set of commands that is more Zero Knowledge Proof friendly instead. Throughout the transformation of codes, Zero Knowledge Proofs are generated while the functions of smart contract are sustained. As a result, it could potentially prevail that avant-garde projects are more likely to be attracted to participate by the tempting benefits of considerately smaller workload and less difficulties to be encountered. However, extra workload may be conducted to transform EVM codes to intermediary codes, especially in the case of replacing the most frequently deployed Keccak Hash functions with other functions. It remains mysterious that if the process of this transformation could be flawless that comes with extra security and compatibility problems.
Table 2：Advantages, shortcoming and outstanding projects of the two zkEVM technology tracks
Typical projects
zkSync 2.0
ZkSync 2.0 is a representative project in the second track mentioned above. Which is Zero Knowledge Proof friendly. The updated version of zkSync 1.0, zkSync 2.0, would be a much better solution that is EVM compatible. Matter Lab explored various technical implementation plans, including TinyRam, Optimized Special Ops, Recursive TinyRam is a simple and traditional random browser for R1SC circuit (a commonly used circuit in Zero Knowledge Proof). It processes logic from smart contract and generate circuit for common opcodes. However, the consumption could be tremendous: The amount of gates in TinyRam could be thousand times more than that in normal fixed circuit. In other words, in a normal fixed circuit, an “add” calculation could be done via merely one gate, whereas 1000 gates must be involved in TinyRam; the more gates, the higher the gas fee. Even though TinyRam is somewhat inefficient, it has minor influence on the whole consumption structure because a rather small percentage is reserved in dealing with logic. This is a tradeoff between efficiency and compatibility, which the latter weighs more for ZKEVM.
Except, there are some longer commands in EVM, such as CALL, DATACOPY, EXP, CREATE, and so on. These commands are naturally unfriendly to circuit proof. For these special commands, zkEVM of zkSync inserted Optimized Special Ops accordingly in order to facilitate the expression of these longer commands in EVM via specially designed codes as intermediary.
To enhance verification efficiency, EVM added Recursive Aggregation. Through Recursive Aggregation, those proofs, which originally must undergo the verification process separately, only need to be transformed a binary tree as root proof and verified; it is sufficient enough to verify that all proofs from leaf nodes are correct. Thus, verification efficiency is elevated.
As mentioned above, Zero Knowledge Proof friendly tech track employs the method of recreating a set of opcode to support Zero Knowledge Proof, which is much less impracticable that ZkSync 2.0 might be the first mature product in the market. Matter Labs has already launched closed beta for zkSync 2.0 that runs Uniswap V2; a trial experience to the Testnet is recommended if more relevant information is desired. The team has not announced the official schedule for the mainnet launch; it is likely that more tests must be conducted in order to confirm the security settings for this typical zkEVM.
Hermez
Hermez devoted to obtain full compatibility to Dapps of Ethereum by exploiting nativeommand set of EVM. It enables an optimized implementation from existing tools and ecosystem on Ethereum with higher security.
However, some native EVM commands are reluctant to Zero Knowledge Proof. The team alter the tough codes to some intermediary codes, micro opcode, to express the same logic that could be accepted. This kind of intermediary codes are customized and optimized; Zero Knowledge Proof is more likely to be generated in this case. Therefore, a balance is more likely to be achieved between maximizing Zero Knowledge Proof generation and optimizing compatibility of EVM, in the middle between the two tracks.
As native opcode of EVM requires executing environment, intermediary opcode is subject to a typical environment-uVM. UVM is composed by ROM and Main SM, and Main SM consists of various SM that could handle multiple functions.
Let’s dive into how Hermez produces proofs according to the program logic. A program has to be executed step by step no matter how complicated the logic is. For instance, extracting a number, completing a calculation, responding to a condition, jumping to another string, etc, the program reiterates various execution of commands until an ending condition is encountered. Although the trace, which represents the pathway of execution and number of executions, could be random, the result would be still within a certain scope of possible outcomes. That is to say, even though the program could not determine the specific route to go through, it would proceed on one of the Hermez stores these certain intermediary opcode in ROM, and configures responding codes according to different storage locations and commands characteristics, namely rom(x). During the process of program execution, a real opcode would be generated according to each operation, namely instTrace(x). Plookup algorism could be utilized in the process of verifying instTrace(x) is a subset of rom(x).
One could not identify a song if he or she could not hear the melody that belongs to the typical song. The same thing applies when identifying a program: A program is determined to be falsely executed if codes being executed are not genetically part of the program.
An assumption was made earlier by someone anonymous: It would be irrational to consider a program is correctly executed if it follows certain paths but in misplaced order. From my perspective, it is controversial to conclude the status of program execution merely by how it is executed. ZkEVM need, and only need to verify the exact codes of smart contract to be executed on Layer 2. Other possible glitch or the order of codes execution should not be part of zkEVM verification; developers who write and deploy the smart contract should be concerned.
In terms of proving the consistency of storage, Hermez utilize the prove of correlation for key-values. Compared to Applied ZKP, Hermez introduced Hash and Merkle Tree; a considerable amount of hash computations exist. However, the consumption for generating Zero Knowledge Proof by Hashing could be enormous, Hermez has not declared any official treatments in this case. From my own perspective, and consistent with the logic mentioned earlier this article, as long as the fixed logic is executed and verified, the degree of completion is entirely beyond concern.
The next proofs from SM could be integrated as a whole to be sent and verified by the verifiers.
Last but not least, Hermez employs a large amount of polynomial promises: the proof being generated is zk-STARK instead of zk-SNARK. Zk-STARK constitute a large proportion of storage, deviating from the principle that Rollup is born to minimize the amount of data submitted to Layer 1. As a result, Hermez proposed that a proof could be synthesized for a typical proof: A STARK proof could be generated first, PLONK or Groth 16 coule then come to play the role in synthesizing a shorter proof. It is commensurate with two separated compilation that directly reduce the consumption of the verifier and save unnecessary occupation of Layer 1 storage, achieving the function of scaling.
Hermez team prepares to launch Testnet in Q4 2021, and Mainnet in Q2 2022. Stay
AppliedZKP
Except zkSync 2.0 and Hermez, the construction of the “overpass” cannot be whole without AppliedZKP. An interesting topic is first spotted on AppliedZKP: Bus Mapping.
The inherent logic of Bus Mapping is to deal with storage and computation independently. When corresponding data is correctly read by a group of codes, executed in a preset order and intervened the account status, it would be considered as an effective execution. They categorized proof to “Status Proof” and “EVM Proof”. “Status Proof” is the final outcome that operations of status/storage/stacks are correctly executed, while EVM confirms the correct codes are executed within certain time range. With these two proofs in appearance, Ethereum Mainnet would be capable of authenticating whether programs are being executed on Layer 2.
To be more specific, “Status Proof” must match the status of operations related to storage completed in the EVM. An EVM storage is composed by 3 parts: Storage, Memory and Stack. “Status Proof” has to provide proof to each part respectively. Bus Mapping plays a role as a gateway transporting data between computation module and storage module. “Status Proof” would be the one to communicate with the computation module that data transported in Bus Mapping is consistent with that in the storage module.
The reflection of Bus Mapping includes two operations according to status. One is to read the old status, the other is to rewrite a new status. Storage status (applicable for Storage, Memory and Stack) is organized by sorts of key-values , a confirmation of receiving the correct data is equal to a confirmation that data transported by Bus Mapping match the data in storage status. Furthermore, plookup algorism would be employed to verify that the keys and values transported by Bus Mapping are inside the source being read; keys and values match each other. Thus, plookup finishes the verification process, in other words, academically, a relationship of subset between two data sets is confirmed.
Plookup first transforms the proof of bit operation to the verification that if input and output match the default setting in the lookup table, and then to the summary of whether the group of vectors is inclusive of another. By doing so, the number of Gate Constraints could be reduced, therefore efficiency levels up.
Proof of EVM need to confirm every single operation in the program, including calculation (plus, minus, multiplication and division), logic operation (“and” , “or” and “not”), program redirect (call), etc.. Each step requires to undergo an entire process of realizing opcode, defining constraints and EVM execution result, confirming elements of execution step in order to complete the EVM circuit.
Summary and Expectations
For Ethereum, the well-known “highway”, ZK Rollup has increased total transaction volume over 500 times, boosting TPS to 2000, which is on the par with current VISA payment system. After vast development of ZKEVM, ZK Rollup would be capable of handling more cases and providing comprehensive support for various applications, thus stands out to be a pioneer in the Rollup market.
Pressure of traffic on Ethereum could be enormously alleviated thanks to faster transportation of data. On one hand, in this case, Ethereum stands a better chance in the fierce competition of newly emerged public chains, such as Solana, Avalanche, Fantom, etc.. As a result, these public chains lost comparative advantage in terms of performance so that they have to differentiate from each other and employ more innovative strategies in order to attract users and grow their ecosystem. On the other hand, more newly launched projects could deploy on Ethereum with a lower cost and still benefit from the mature and powerful Ethereum ecosystem. In all, ZKEVM is the key. We believe that the development of technology would eventually make everything mentioned above true. Perhaps, the discussion of ZKEVM should not be in the scale of “whether ZKEVM would come” any more, but “when ZKEVM would come” instead.
Besides, ZKEVM is not the finish line of Rollup. The future of Rollup could way beyond our imagination rather than a temporary transition. According to Vitalik, for Ethereum, Rollups are more than likely to be the sole scalable solution without trust in the short run, or even long term. The volume of Rollup could be optimized by the reduction of gas fee for the calldata part in the block, cutting more than 5 times cost down, which is less than 1% of that in Layer 1; when Sharding is successful, scalability of Rollup could be amplified exponentially that further curtails the transaction fee to negligibly low.
Rollup could prevail among all public chains other than Ethereum. A newly developed district would be sparsely populated because very few could perceive and embrace the advanced philosophy of design; traffic jam might not be an issue at this time. So are the public chains. However, traffic would be eventually accumulated to a certain level that may cause traffic jam, an “overpass” is necessary sooner or later to sooth the situation. Rollup remains indispensable considering possible consequences that may appear in the future, and ZKEVM would play a vital role in the challenges yet to come.
