zkSync 2.0: Hello Ethereum!

The Alpha version of zkEVM testnet is live.

Shall I compare thee to a summer’s day?

Thou art more scalable and secure.

Rough winds do shake the darling minds of May,

And summer’s lease hath all too short a date.

— Satoshi Shakespeare, 2021

Introduction

With the greatest technical challenges behind us, we’re starting our sprint towards smart contract deployments in an EVM-compatible environment. The first version of the testnet is live: you can already check out the activity on zkSync 2.0 with a block explorer. In this post, we’ll dive deeper into explaining each of the key components, providing progress updates, and what’s planned for the next release.

>> ZKSYNC 2.0 TESTNET EXPLORER <<

Key Accomplishments

On the cryptography side, the instruction set of the zk EVM has been finalized and both implementations are done: in circuit and in the execution environment.

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

On the core infrastructure side, the full node integration is complete and capable of successfully deploying and executing compiled smart contracts.

While the zk EVM and core 2.0 infrastructure are ready to be made public, the compiler requires more work to cover all of the edge-cases correctly. To provide a more holistic developer experience, we have decided to open access to the zkEVM, compiler, and core SDK together as soon as the compiler is 100% reliable.

Comparing zkSync 2.0 to Ethereum

Most things look and feel the same. Here are a few important differences:

Solidity Smart Contracts

Most opcodes in Ethereum are supported! However, there are a few exceptions:

1. ADDMOD, SMOD, MULMOD, EXP, and CREATE2 opcodes are not supported in this release but will be in the future.
2. We will not support the KECCAK256 opcode for now and will instead automatically replace all its invocations with a call to another collision-resistant hash function. KECCAK256 will later be introduced as a precompile.
3. We have decided not to include the SELFDESTRUCT opcode as Ethereum is planning to remove it.
4. We may remove support for full 256 bit XOR/AND/OR opcodes as these exist only on compiled solidity code for bitmasking. This may be done by the compiler using other opcodes.

Gas

In zkSync 2.0, there is a different concept of gas. Transaction prices will fluctuate depending on current L1 gas prices (due to publishing calldata) and cost of ZKP generation. Smart contract calls will have a maximum number of zk EVM 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 work out of the box and all services can be easily integrated.

zkSync includes features that L1 doesn’t, such as the notion of committed and finalized blocks. So, there will be additional methods to give developers more precise control of data. Web3 client code will receive the same data as you would on Ethereum, but specialized information can be requested with the `zksync_` namespace.

Because zkSync has multiple types of transactions and uses EIP712 signatures, the format of `eth_sendRawTransaction` data will be different from L1. However, the encoding corresponds to the Ethereum ABI, so supporting it won’t be difficult.

Signing Transactions

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

1. Users can sign transactions with their normal Ethereum wallets (such as Metamask or any WalletConnect one) by signing an EIP712 message.
2. Any account can set up a public key to create our internal Schnorr signatures to sign transactions. This allows smart-contract based wallets to perform interactions with zkSync 2.0 without the extra costs of sending L1 messages.

Storage Efficiency Boost

Storage slot overwrites are only applied once per block. This means if multiple users interact with a single AMM contract, the storage slots of the AMM contract will be overwritten only once. This allows a sequencer to refund the users for a shared cost of a single write later.

Precompiles

The mechanism of “precompiles” is planned, but will be released later on. We plan to support keccak256, sha256 hashes, and ECDSA recovery primitives first. Other precompiles such as a Blake2f round function (virtually unusable in Ethereum in its current form) may be considered for inclusion based on demand and complexity.

Further Limitations

The first iteration of zkSync 2.0 may impose an extra limitation of 32 smart contract calls per transaction until a proper accounting mechanism is implemented.

The execution trace will have a hard limit, but it will be comparable to the current limits of the Ethereum block size and should not affect most protocols.

There may be more limitations, but our goal is to reduce them to an absolute minimum in the final version.

A deeper dive into zkSync 2.0 architecture

You may have heard of the blockchain trilemma, but when it comes to scaling Ethereum, there’s a 4th factor: programmability. All current scaling solutions reside on a spectrum of sacrificing some security, decentralization, and programmability for scalability. The design of zkSync 2.0 maximizes on all 4 features with the combination of the following 2 technological breakthroughs:

1. zk EVM: The engine powering our EVM-compatible zkRollup, the only solution with L1 security and solidity smart contract support.
2. zkPorter: An off-chain data availability system with 2 orders of magnitude more scalability than rollups.

Since zkEVM and zkPorter are interoperable and composable, zkSync 2.0 is able to significantly outperform all other scaling solutions.

The current consensus is 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 endgame, hitting 100,000+ TPS without sacrifices on any of the 4 factors.

The State Tree

The zkSync 2.0 state tree covers Ethereum’s full 160-bit address space. Each account will reside in either the zkRollup part or zkPorter part of the state. zkRollup and zkPorter accounts are completely identical except for one component: where the data availability is guaranteed. zkRollup transaction data gets published to Ethereum through calldata, and zkPorter transaction data is published to the zkSync Guardian network, where zkSync token holders participate in Proof of Stake.

Where the data is published is a tradeoff between cost and security. zkPorter transactions are exponentially cheaper than rollup transactions, but it comes with a possibility that your funds could be frozen. However, the validity of both zkRollup and zkPorter accounts is guaranteed through zero knowledge proofs and by Ethereum. In other words, funds in zkPorter can only be frozen, never stolen.

The interoperability and composability of zkRollup and zkPorter accounts give every user the opportunity to be a first-class citizen in zkSync. Uniswap deployed on the zkRollup side can be accessed to swap for the lowest fees by zkPorter accounts. zkSync 2.0 is one system, designed for users across the entire financial spectrum to participate in.

Cryptography

Our VM, most commonly referred to as the zkEVM, is not an EVM 1:1 replica, but instead aims to be able to run 99% of contracts written in Solidity and maintain its same behavior, such as during reverts and exceptions. Simultaneously, the zk EVM is written to be efficient in a circuit to produce zero knowledge proofs.

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

Once again, we are excited to announce, after months of hard work: the instruction set of the zkEVM has been finalized and implemented in circuit and in the execution environment.

There is an important distinction here: the implementation in circuit and execution environment are separate and serve different purposes. It is the job of the circuit to generate proofs of the execution trace and provide witnesses, but this is very slow. On the other hand, the execution environment, which is a straightforward implementation of the zk EVM in rust, is efficient and fast. If we were to rely on the circuit for both proof generation and execution, transaction finality would take hours. The separation of proof generation and simple execution is what enables the instant settlement of transactions on zkSync.

Next, we are focusing on bringing together the zkEVM and the compiler, and joining together the recursion: recursion between blocks, which allows us to post one proof for N blocks, and recursion within blocks, which aggregates subproofs for different logical parts of the block. This is the easy part! Recursive aggregation proofs between blocks are already being used on mainnet in zkSync 1.0 since June 2020. For more on recursion within blocks and how our zk EVM works, watch this video explanation.

Compiler

We are simultaneously working on two compiler front-ends targeting zkEVM: Yul and Zinc. Yul is an intermediate Solidity representation that can be compiled to bytecode for different backends. Zinc is our Rust-based language for smart contracts and general purpose zero-knowledge proof circuits.

Because the compilers are built using the LLVM framework, it can be thought of as having a frontend, Yul → LLVM IR, and backend, LLVM IR → zkEVM bytecode. The adoption of LLVM brings several major advantages:

1. The LLVM optimization framework is unmatched: it generates the most efficient zkEVM bytecode from LLVM IR.
2. With newer versions of Solidity or Zinc, the compiler frontend will handle all the changes and the LLVM will abstract us out of changing the compiler backend.
3. In the future, if developers want to program smart contracts in native Rust or Javascript, only the compiler frontend for that language needs to be built for smart contracts to work out of the box in zkSync.

The security of the compiler is paramount to us, and has already gone through multiple suites of tests:

1. Lexical, syntax, and semantic tests in Zinc and Yul compilers.
2. Our own integration tests for both Zinc and Solidity, which run through the entire smart contract lifecycle: from parsing the source code to contract deployment and executing transactions on zkSync.
3. The extensive suite of tests integrated from the Solidity repository and adapted for our integration testing tools.

Each suite already consists of several thousand tests, and we are going to increase this number by at least one order of magnitude.

Our 2 compilers have already successfully deployed and executed simple smart contracts in both languages. But there are still more optimizations to be completed and some complex LLVM IR statements that need to be translated to zkEVM bytecode. So, we have decided not to release our compiler until it is in a more robust state.

After the compiler is finished, we will focus on making Zinc more expressive and feature-rich, and then building the Rust compiler frontend to allow programming smart contracts using native Rust.

Core Infrastructure

zkSync 2.0 core consists of several key actors:

The Full Node

1. pre-circuit executor environment for zkEVM bytecode via virtual machine
2. the state is usable in seconds after the transaction is sent,
3. filters out obviously incorrect transactions (e.g. not enough funds for the transaction) that could bloat the block,
4. executes transactions in the mempool and generates blocks.

The Prover

1. receives witnesses for blocks and generates zero-knowledge proofs,
2. prover interface for parallel proof generation,
3. custom prover autoscaler that creates and kills prover machines on demand.

The Interactor

1. tools for watching and interacting with Ethereum L1,
2. calculates fees for transactions based on token prices, ZKP generation costs, and L1 gas prices.

The Paranoid Monitor

Prometheus, elastic, sentry, uptime, several independent incident notification systems, and custom health-check services.

***

This core infrastructure is fully functional, with the zkEVM executor already integrated!

Let’s Talk

Once the compiler is finished, we will be sharing access to all components together! Developers will be able to deploy Solidity/Zinc smart contracts and interact via the Web3 API.

Follow us on Twitter for updates! And join the conversation in our discord, telegram, and gitter.

If you’re interested in helping build the first EVM-compatible zkRollup with us, we’re hiring for all roles!