zkSync 2.0: Hello Ethernet

The first version of the zkSync beta network is now live. What are the technical breakthroughs in 2.0?

zkSync 2.0: Hello Ethernet

Facing the biggest technical challenges, we are starting our sprint towards deploying smart contracts in an EVM-compatible environment. The first version of the test network is now live: you can already view activity on zkSync 2.0 using the block browser. In this post, we’ll explain each key component in depth, provide progress updates, and what’s planned for the next release.

Key Achievements
On the cryptography side, the instruction set for zkEVM is complete, and both implementations are complete: in circuit and in the execution environment.

On the compiler side, smart contracts written in Solidity and Zinc can now be compiled into zkEVM bytecode.

On the core infrastructure side, full node integration is complete, enabling successful deployment and execution of compiled smart contracts.

While the zkEVM and Core 2.0 infrastructure is ready to be made public, the compiler needs more work to properly cover all edge cases. In order to provide a more comprehensive developer experience, we decided to open access to zkEVM, the compiler, and the core SDK as soon as the compiler is 100% reliable.

zkSync 2.0 versus Ether
Most things look and feel the same. Here are some important differences.

Solidity Smart Contracts

supports most of the opcodes in Ether! However, there are some exceptions.

ADDMOD, SMOD, MULMOD, EXP, and CREATE2 opcodes are not supported in this release, but will be in the future.

We do not support the KECCAK256 opcode for now, but will automatically replace all its calls with a call to another collision-resistant hash function.KECCAK256 will be introduced later as a precompilation.

We decided not to include the SELFDESTRUCT opcode because EtherChannel plans to remove it.

We may remove support for the full 256-bit XOR/AND/OR opcodes, as these are only present in the Solidity code that has been compiled for use with bitmasks. This can be done by the compiler using other opcodes.


In zkSync 2.0, there is a different concept of gas. The transaction price will fluctuate based on the current L1 gas price (due to published call data) and the ZKP generation cost. Smart contract calls will have a maximum number of zkEVM steps and storage write parameters.

Web3 API

The next release will include our Web3 API implementation, which will be compatible with the Web3 standard as defined by the ethereum documentation. Events will be available out of the box and all services can be easily integrated.

zkSync includes features not found in L1, such as the concept of committed and final blocks. As a result, there will be other ways to give developers more precise control over the data. web3 client code will receive the same data as ethereum, but can request special information using the zksync_ namespace.

Since zkSync has multiple transaction types and uses EIP712 signatures, the format of the eth_sendRawTransaction data will be different from L1. However, the encoding corresponds to the Ether ABI, so it is not difficult to support it.

Signing Transactions

Transactions in zkSync 2.0 can be authorized in two ways (in addition to the priority queue mechanism).

Users can sign transactions by signing EIP712 messages, using their regular Ether wallet (e.g. Metamask or any WalletConnect wallet).

Any account can set up a public key to create our internal Schnorr signature to sign transactions. This allows smart contract-based wallets to interact with zkSync 2.0 without the additional cost of sending L1 messages.

Storage Efficiency Improvements

Only one storage slot override is applied per block. This means that if multiple users interact with a single AMM contract, the AMM contract’s slots will only be overwritten once. This allows the sequencer to later refund the user for the shared cost of a single write.


A “pre-compilation” mechanism is planned, but will be released later. We plan to support keccak256, sha256 hashing, and ECDSA recovery primitives first. Depending on requirements and complexity, other pre-compilations may be considered for inclusion, such as the Blake2f round function (which in its current form is virtually unusable in Ether).

Further limitations

The first iteration of zkSync 2.0 may impose an additional limit of 32 smart contract calls per transaction until a proper bookkeeping mechanism is implemented.

There will be a hard limit on execution tracking, but it is comparable to the current limit on Ether block size and should not affect most protocols.

There may be more limits, but we aim to reduce them to an absolute minimum in the final release.

A deeper look at the zkSync 2.0 architecture

You may have heard of the blockchain trilemma, but there is a fourth factor when it comes to scaling Ether: programmability. All current scaling solutions exist to the extent that they sacrifice some security, decentralization, and programmability for scalability. zkSync 2.0 is designed to maximize all 4 features by combining 2 technical breakthroughs.

zkEVM: The engine that powers our EVM-compatible zkRollup, the only solution with L1 security and reliable smart contract support.

zkPorter: an off-chain data availability system that is 2 orders of magnitude more scalable than aggregation.

The current consensus is that Eth2 data sharding will arrive by the end of 2022 to provide an exponentially larger data availability layer without sacrificing decentralization. zkSync’s zkRollup technology combined with Eth2 data sharding is the ultimate goal, reaching 100,000+ TPS without sacrificing any of the 4 factors.

State Tree

The zkSync 2.0 state tree covers the full 160-bit address space of Ether. Each account will reside in either the zkRollup part of the state or the zkPorter part. zkRollup and zkPorter accounts are identical except for one component: guaranteed data availability. zkRollup transaction data is published to Ethernet via calldata, zkPorter transaction data is published to the zkSync Guardian network, where zkSync token holders participate in proof-of-interest.

Where data is published is a trade-off between cost and security. zkPorter transactions are much cheaper than aggregated transactions, but it can potentially result in your funds being frozen. However, the validity of both zkRollup and zkPorter accounts is guaranteed by zero-knowledge proofs and Ether. In other words, funds in zkPorter can only be frozen, not stolen.

The interoperability and composability of zkRollup and zkPorter accounts gives every user the opportunity to become a first-class citizen in zkSync. Uniswap deployed on the zkRollup side can be accessed through the zkPorter account in exchange for a minimum fee. zkSync 2.0 is a system designed for participation by users from across the financial spectrum.


Our VM, most often referred to as zkEVM, is not a 1:1 copy of EVM, but is designed to be able to run 99% of contracts written in Solidity and maintain their same behavior, for example during recovery and exceptions. At the same time, zkEVM is written to efficiently generate zero-knowledge proofs in the circuit.

This was done without any significant changes to our proof system; we continue to use PLONK with custom gates and lookup tables (often referred to as UltraPLONK) as well as Ether’s BN-254 curve. This is advantageous because the proof system has been field tested in zkSync 1.0 since June 2020, as well as other projects using the same proof system.

Once again, we are pleased to announce that after several months of work: the instruction set of zkEVM is now complete and implemented in both the circuit and execution environments.

There is an important difference here: the implementations in the circuit and in the execution environment are separate and used for different purposes. The job of the circuit is to generate proofs for the execution trace and provide witnesses, but this is very slow. The execution environment, on the other hand, is a direct implementation of zkEVM in rust that is efficient and fast. If we relied on the circuit to generate proofs and executions, the transaction would take hours to finalize. The separation of proof generation and simple execution allows for instant settlement of transactions on zkSync.

Next, we focus on combining zkEVM and the compiler together with recursion: inter-block recursion, which allows us to issue a proof for N blocks, and intra-block recursion, which aggregates sub-proofs for different logical parts of the blocks. This is the easy part! Recursive aggregation of proofs between blocks has been in use on the main web of zkSync 1.0 since June 2020. For more information on intra-block recursion and how our zkEVM works, please watch this video description.


Since the compiler is built using the LLVM framework, it can be thought of as having a front-end Yul → LLVM IR and a back-end LLVM IR → zkEVM bytecode. the adoption of LLVM brings several key advantages.

The LLVM optimization framework is unparalleled: it generates the most efficient zkEVM bytecode from LLVM IR.

With newer versions of Solidity or Zinc, the compiler front-end will handle all the changes, while LLVM will eliminate the need to change the compiler back-end.

In the future, if a developer wants to write a smart contract in native Rust or Javascript, they can simply build a compiler front-end for that language and the smart contract will be ready to use out of the box in zkSync.

The security of the compiler is of paramount importance to us and has passed several sets of tests.

Lexical, syntactic, and semantic tests in the Zinc and Yul compilers.

Our own Zinc and Solidity integration tests throughout the entire smart contract lifecycle: from parsing source code to contract deployment and executing transactions on zkSync.

An extensive test suite integrated from the Solidity repository for our integration testing tools.

Each suite already contains thousands of tests, and we will increase this number by at least an order of magnitude.

Our 2 compilers have successfully deployed and executed simple smart contracts in both languages. But there are still more optimizations to be done, and some complex LLVM IR statements need to be converted to zkEVM bytecode. Therefore, we decided not to release the compiler until it was in a more robust state.

Once the compiler is complete, we will focus on making Zinc more expressive and feature-rich, and then build the Rust compiler front-end to allow writing smart contracts using native Rust.

Core Infrastructure

The zkSync 2.0 core consists of several key players.

Full Node

A pre-circuit actuator environment via the zkEVM bytecode of the virtual machine

which is available for a few seconds after a transaction is sent.

filtering out obviously incorrect transactions that could lead to block inflation (e.g., underfunded transactions).

executes the transaction in the memory pool and generates the block.


receives the witness for the block and generates a zero-knowledge proof.

a prover interface for parallel proof generation, the

Custom prover autoscaler that can create and terminate prover machines as needed.


A tool for viewing and interacting with Ether L1.

Calculates transaction fees based on token price, ZKP generation cost and L1 gas price.

Paranoia Monitor

Prometheus, elastic, sentry, uptime, several separate event notification systems and custom health check services.

This core infrastructure is fully functional and has been integrated with the zkEVM actuator.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/zksync-2-0-hello-ethernet/
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 (2)
Donate Buy me a coffee Buy me a coffee
Previous 2021-06-01 23:26
Next 2021-06-01 23:30

Related articles