zkEVM solution: zkSync, StarkNet, Polygon zkEVM, Scroll

In his blog post, Vitalik outlined four types of zkEVM based on compatibility with Ethereum.

What should be noted is:

The closer zkEVM is to the functionality of Ethereum, the slower and more expensive it will be to generate Zk proofs.

On the other hand, if a blockchain or Rollup is more compliant with Ethereum's specifications and standards, then it will be easier for developers to build applications on it and integrate them into the Ethereum ecosystem.

In short, a blockchain that is highly compatible with Ethereum could have a competitive advantage.

First category: The exact equivalent of Ethereum's zk rollups, precisely duplicates Ethereum in all parts, including hashes, state trees, transaction trees, precompilations, or any other consensus logic. So far, no zkEVM has achieved equivalence with Ethereum.

The second categoryZk rollups, which is fully equivalent to EVM, strives to be equivalent to EVM, but not to Ethereum. They are fully compatible with existing applications, but with some minor modifications to Ethereum to make development easier and to generate proofs faster. Scroll and zkEVM Polygon theoretically fall into this category; In practice, they currently belong to the third group.

The third category: is almost the same as EVM, sacrificing more elements and equivalence in order to make proof generation faster. Polygon zkEVM and Scroll currently fall into this category. This category is often a springboard into the second category.

The fourth category: High-level language equivalent, meaning that they all accept smart contracts written in Solidity and convert them into another custom, ZK-friendly language. zkSync and StarkNet fall into this category, although zkSync may add EVM bytecode compatibility over time and eventually move to higher types.

Although Vitalik's proposed classification is currently the most popular and impartial, there are other classifications as well.

Immutable proposes four categories

Immutable, a StarkWare based NFT-specific L2, provides the following useful category in its blog post:

These categories are more clearly based on existing zkEVM reaching Ethereum compatibility or equivalence at specific levels of the stack (high-level language, bytecode, or runtime environment) than Vitalik's categories.

Solidity compatibility. Compatibility with Ethereum is implemented at the high-level language level Solidity, which means developers can continue to write smart contracts in the language they are accustomed to using on Ethereum. However, these rollups immediately converted Solidity into their intermediate representations, then compiled in their bytecode and executed in their custom environments. Specifically, these L2 use a translator to convert Solidity code into readable code for custom VMS (StarkWare's Cairo, zkSync's LLVM-IR). These translators do not support certain Solidity features, so developers may need to adjust their smart contracts. For example, zkSync and StarkNet.

EVM compatibility. These Rollup are EVM-compatible on a language level, but they have their own bytecode, which means Solidity can compile directly into EVM opcode/bytecode and then convert to custom bytecode before custom VM run time. In fact, these rollups are compatible with most Ethereum programs, but some applications may need to be rewritten. In addition, some bytecode features, such as precompilation, are not supported. For example, Polygon zkEVM.

Equivalent to EVM. These rollups create a zk validation circuit that can read EVM opcodes and bytecode directly, although the VM itself is different from the EVM. These rollups are fully compatible with existing applications, but can make minor modifications to Ethereum to make development easier and proof generation faster. For example, Scroll.

Equivalent to Ethereum. This means replicating Ethereum on all its components, similar to what Polygon did. So far, no zk Rollup falls into this category.

By combining this framework with that proposed by Immutable, and adding some additional information, you can outline the following chart, highlighting some design differences and similarities to consider when comparing different zkEVM implementations, before any performance data is available:

zkSync 2.0 

zkSync 2.0 (renamed zkSync Era just before the Mainnet release) is an extended solution for the Ethereum network, fully compatible with the Solidity programming language. With zkSync, users can choose between two data availability types: zkSync Rollup and zkSync Porter. The former publishes data directly onto Ethereum, making it as secure as Ethereum L1, while the latter stores data off-chain, resulting in faster and cheaper transactions, but with a lower level of security.

zkSync is EVM-compatible in that it can convert smart contract code written in Solidity into Yul and convert Yul into LLVM-IR, then recompile it into a custom circuit compatible bytecode set of EVMs specifically designed for use with zkSync. While this requires intermediate steps, it also allows for the addition of other non-EVM features, such as Account Abstraction. In addition, zkSync's company, Matter Labs, plans to gradually make it more compatible with the Ethereum toolkit, and is preparing to launch its first three-tier prototype, zkSync Opportunity, in the area of scalability and interoperability, as part of its ambitions for a beta web release.

At the time of writing, the zkSync Era had just launched, so it would be premature to comment on its performance. zkSync 1.0  for simple transactions only; (now called zkSync Lite) is one of the largest zk rollups, according to TVL, with more than $83 million locked up and more than 19 million cumulative transactions, while StarkNet's TVL is just over $19 million with 4 million cumulative transactions.

StarkNet

StarkNet Is a type 4 / Solidity compatible zk-rollup that employs a different type of zero-knowledge proof called STARKs (Scalable Transparent ARgument of Knowledge) to ensure the integrity of off-chain transactions. STARKs are considered more efficient and scalable than SNARK, but may require a more complex technical setup.

While StarkNet also supports smart contracts, its capabilities are relatively modest due to the use of STARKs and the fact that the StarkNet contract and StarkNet OS are written in the Cairo language. To make development easier, StarkWare has recently been upgraded to Cairo 1.0  , this version emulates Rust. Like the zkSync Era, StarkNet can be classified as "Solidity compatible" because it will not execute programs within the EVM, but instead create a brand new, purposely-designed VM and use custom bytecode. StarkWare uses the Warp translator to convert Solidity code into Cairo VM bytecode.

However, unlike zkSync Era and other zkEVM implementations, the StarkNet team is not aiming to be compatible with EVM or other Ethereum components, Rather, the aim is to make StarkNet's VM as efficient as possible by rolling through its custom client API, JavaScript library, and wallet system, which will force Ethereum-compatible tools to manually add StarkNet support. Although Cairo 1.0 also introduced Sierra -- Secure Intermediate Representations -- as a new intermediate presentation layer between Cairo 1.0 and Cairo bytecode, the Warp translator did not support certain Solidity features, And it's still a long way from matching EVM compatibility with the zkSync Era.

Polygon zkEVM

Polygon zkEVM  zk-rollup is a zk-rollup that uses the custom language zkASM to interpret zkEVM code and verify smart contract execution in non-EVM runtime environments. The program began in 2021 with the $250 million acquisition of Hermez Network to develop an EVM equivalent system that combines the security and efficiency of STARK and SNARK. While STARK is used to generate validity proofs for transaction states, SNARK is used to evaluate the correctness of STARK proofs. The combination of these solutions enables security, speed, and low transaction costs.

In July 2022, Polygon announced that Polygon Hermez would be renamed Polygon zkEVM, just launched at the time of writing. The latest beta version of Polygon zkEVM introduces recursive capabilities that allow one ZK proof of validity to be used to verify batches of other ZK proofs, each of which can verify multiple transactions. This feature benefits from Plonky  2  , a recursive SNARK that is 100 times faster than existing alternatives and natively compatible with Ethereum itself.

In addition to Polygon zkEVM, Polygon also developed Polygon Avail, a blockchain that optimizes data availability only. The network will be permissionless, allowing anyone to join as a validator, and unlike existing Dacs (Data Availability Committees), it will have hundreds of nodes working together to provide network security. Avail will work with Polygon Hermez (Rollup) to upload status data from Hermez instead of publishing on Ethereum, providing solutions between Validium and Rollup.

Although some experts point out that the specifications provided by Polygon are better described as EVM compatibility, the team is working to create the first solution that is fully equivalent to EVM.

Scroll

Scroll  Is an EVM-equivalent zk-rollup developed by the Scroll team in collaboration with the Ethereum Foundation's PSE (Privacy and Scaling Explorations) group, and is currently in Pre-Alpha test networking, Intended to be fully compatible with the Ethereum Virtual Machine (EVM) at the bytecode level. This means that developers can create smart contracts in any EVM-compatible language and deploy them to Scroll. Although Scroll does not currently support EVM opcode, it is planned to do so by building 1:  1 opcode map to implement and accept EVM opcode directly without the compiler.

Scroll's architecture consists of a centralized serialization node and a decentralized proof network. The centralized serialization node is responsible for sorting transactions, creating blocks, and submitting the transaction data as calldata to the Rollup contract on Ethereum for data availability. Scroll plans to gradually decentralize the serialized nodes. On the other hand, a distributed proof generator called Roller produces proofs and publishes them to the L1 network, leveraging distributed computing power. Rollers are randomly selected, and it is possible to generate multiple proofs of different blocks in parallel on different Rollers to increase speed.

* Note: Although only on-chain data availability is currently supported, Scroll's original design also included Validium mode.

Indeed, Scroll and Polygon both take a bytecode level approach to building their zkEVM. This approach eliminates the translation step entirely, which means that these ZkevMs will not convert Solidity code into another language before compiling and interpreting. However, while Scroll's only difference from Ethereum is the runtime environment, Polygon creates and optimizes a custom VM, then converts EVM bytecode to that VM's bytecode. Unlike Scroll, the Polygon runtime (" zkExecutor ") runs the custom "zkASM" opcode (the microopcode in the figure) instead of the EVM opcode to optimize EVM interpretation (that is, to reduce the number of constraints rather than directly prove EVM). Polygon zkEVM may not work with 100  % of Solidity code, tools, and applications are compatible, although most are fine.

While these are the most prominent projects focused on rolling out general purpose zkEVM implementations, other application-specific projects are also using zk technology in practice.

Looping is an application-specific zk-rollup used to support a decentralized exchange (DEX) protocol. Loopring is also a platform that lets anyone build dex using zk proofs. Immutable X is another zk-rollup of specific applications built on StarkWare for NFT trading and gaming. Aztec is a privacy-oriented Ethereum-based zk-rollup that encrypts data to maintain data transparency and availability to the protocol while protecting user privacy. In addition, Aztec invented the PLONK Proof system, which is also used by zkSync and other projects.

Several protocols, such as Immutable X, Sorare, rhino.fi, ApeX, dYdX, etc., are built on StarkEx. In projects that use StarkEx ZK-Rollup, data is sent to Ethereum as calldata and published on the chain. In Validium mode, data is stored down the chain and only hash values are stored on the chain. While the Rollup model ensures greater security (users can recreate ledger state simply by interacting with the Ethereum blockchain), the Validium model ensures lower costs and higher privacy.

Overall, although zkSync Lite is the largest zk rollup, StarkWare has the largest ecosystem, including projects built on StarkEx, and it also has the largest TVL and market share.

summarize

In summary, zk-rollup is a promising solution for extending blockchain networks, offering a variety of implementations to meet different needs and requirements. While some classifications exist, it is worth noting that they are approximate interpretations and lack consensus on definitions and technical differences.

As Sandy Peng, co-founder of Scroll, admits: "There is no definition that can be clearly agreed upon. 'The whole research team at Scroll' tends towards a certain narrative or a certain perception, but it's not a clear thing. Our research team doesn't even agree on what everything means."

Nonetheless, some common trends have emerged in zk rollup implementations:

First, they all seem to take a hybrid approach to data availability, providing a rollup version of a traditional on-chain data store and a validium version of an off-chain data store. "In my opinion, you'll find that every rollup will have a rollup version and a validium version," Avail CEO Anurag Arjun told Blockworks.

Secondly, they mostly avoid using pure open source code until they are actually running, which is also related to stiff competition from optimistic rollups like Arbitrum and Optimism. The Zk-rollups promise to be more efficient, but technically more difficult to achieve.

In addition, as the table above makes clear, optimistic rollups, especially Arbitrum, is benefiting from first-mover advantage and is leading the market in terms of applications, transaction volume, and market share. If proven successful, optimistic rollups could combine the proof-of-validity model with their already established user base (e.g., Optimism of Upgraded Bedrock might introduce proof-of-validity).

In addition, although all implementations begin with a centralized sequester to improve efficiency, they all aim to progressively decentralize to address concerns about centralization. Interestingly, a decentralized sorter may require an economic incentive for a native token, so all mentioned projects should take this step.

Finally, the amazing results of these zkEVM implementations over the past year have led to a renewed focus on zk technology in general, with the company focusing on all aspects of development, including the development of new zk hardware to increase the speed of proof generation.

While there are still some challenges that need to be addressed, it is remarkable how far zkEVM's design has come in just over a year. 2023 could be the defining year for this technology.

Original link