Flash Depth Data Forum

Forum

Search Extension

In-depth understanding of zkSync 2.0 architecture and core infrastructure

水多多|zkSync

2022-07-25 14:57

Read this article in 99 Minutes

This article takes you to interpret each key component of zkSync 2.0, progress updates and plans for the next version

Original title: "zkSync 2.0: Hello Ethereum! "

Original author: Shui Duoduo | zkSync

May I compare you to a summer day?

You Higher scalability and security.

The strong wind really shook the heart of my dear May,

The summer lease dates are too short.

— — Satoshi Shakespeare, 2021

Introduction

Facing the biggest technical challenge, we started deploying smart contracts in an EVM-compatible environment. The first version of the testnet is live: you can already use a block explorer to view activity on zkSync 2.0. In this post, we explain each key component in depth, provide progress updates, and plans for the next release.

Main achievement

In terms of cryptography, the zk EVM's instruction set has been completed, and both implementations have been completed: in the circuit and in the execution environment .

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

In terms of core infrastructure, the full node integration has been completed and the compiled smart contracts can be successfully deployed and executed.

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

Comparison between zkSync 2.0 and Ethereum

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

Solidity Smart Contract

Supports most opcodes in Ethereum! However, there are some exceptions:

The 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 automatically replace all calls to it with calls to another collision-resistant hash function. KECCAK256 will be introduced as a precompiler later.

We decided not to include the SELFDESTRUCT opcode as Ethereum plans to remove it.

We may remove support for the full 256-bit XOR/ Support for AND/OR opcodes, as these only exist in compiled reliable code for bitmasks. This can be done by the compiler using other opcodes.

gas

In zkSync 2.0, there is a different concept of gas. The transaction price will be based on the current L1 gas price ( Fluctuates due to post call data) and ZKP generation cost. Smart contract calls will have max number of zk EVM steps and store write parameters.

Web3 API

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

zkSync includes features that L1 does not, such as the concept of commits and finalized blocks. As a result, there will be additional ways for developers to control data more precisely. Web3 client code will receive the same data as you would on Ethereum, but can request specialized information using the "zksync_" namespace.

Because zkSync has multiple transaction types 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 is not difficult.

Sign transaction

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

User Transactions can be signed using their normal Ethereum wallet (such as Metamask or any WalletConnect wallet) by signing an EIP712 message.

Any account can set up a public key to create our internal Schnorr signatures 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 improvement

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

Precompiled

The "precompile" mechanism is planned, but will be released later. We plan to support keccak256, sha256 hashes and ECDSA recovery primitives first. Other precompiles can be considered for inclusion depending on needs and complexity, such as the Blake2f round function (almost unusable in Ethereum in its current form).

Further restrictions

The first iteration of zkSync 2.0 may impose an additional limit of 32 smart contract calls per transaction until appropriate accounting mechanism.

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

There may be more restrictions, but our goal is to reduce them to the absolute minimum in the final release.

In-depth understanding of zkSync 2.0 architecture

You may have heard of the blockchain trilemma, but when it comes to scaling Ethereum, there is a fourth factor: Programmability. All current scaling solutions exist to the extent of sacrificing some security, decentralization, and programmability in order to achieve scalability. zkSync 2.0 is designed to maximize all 4 features by combining the following 2 technological breakthroughs:

zk EVM: The engine that powers our EVM compatible zkRollup, the only A solution that supports L1 security and reliable smart contracts.

zkPorter: an off-chain data availability system with scalability 2 orders of magnitude higher than rollups.

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

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

zkSync 2.0 state tree covers the entire 160-bit address space of Ethereum. Each account will reside in either the zkRollup part or the zkPorter part of the state. A zkRollup is exactly like a zkPorter account, except for one component: guaranteed data availability. zkRollup transaction data is published to Ethereum through calldata, zkPorter transaction data is published to the zkSync Guardian network, and zkSync Token holders participate in the proof of equity.

Where to publish data is a trade-off between cost and security. zkPorter transactions are much cheaper than aggregate transactions, but it has the potential to freeze your funds. However, the validity of zkRollup and zkPorter accounts are both guaranteed by zero-knowledge proofs and Ethereum. In other words, the funds in zkPorter can only be frozen, not stolen.

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

Cryptography

Our VM, commonly called zkEVM, is not a 1:1 copy of the EVM, but is designed to be able to run 99% of contract and maintain its same behavior, e.g. during recovery and exceptions. At the same time, the zk EVM is written to efficiently produce zero-knowledge proofs in circuits.

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

After months of hard work, we are again excited to announce that the instruction set for zkEVM is complete and implemented in circuits and execution environments.

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

Next, we focus on bringing the zkEVM and compiler together and combining recursion: recursion between blocks, which allows us to issue a proof for N blocks, and recursion within a block, which aggregates differences between blocks A sub-proof for the logic part. This is the easy part! Recursive aggregated proofs between blocks have been used on zkSync 1.0 mainnet since June 2020. For more information on intra-block recursion and how our zk EVM works, watch this video explainer.

Compiler

We are developing two compiler frontends for zkEVM at the same time: Yul and Zinc. Yul is an intermediate Solidity representation that compiles to bytecode for different backends. Zinc is our Rust-based language for smart contracts and general-purpose zero-knowledge proof circuits.

Because the compiler is built using the LLVM framework, it can be considered to have a front-end Yul LLVM IR and a back-end LLVM IR zkEVM bytecode. Adopting LLVM brings several major advantages:

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

2. With a newer version of Solidity or Zinc, the compiler frontend will handle all changes, and LLVM will keep us out of changes to the compiler backend.

3. In the future, if developers want to write smart contracts in native Rust or Javascript, they only need to build the compiler front end of the language, and the smart contracts can be used out of the box in zkSync.

Compiler security is of utmost importance to us and has passed several suites of tests:

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

2. Our integration testing of Zinc and Solidity runs through the entire smart contract lifecycle: from parsing source code to contract deployment and executing transactions on zkSync.

3. An extensive test suite integrated from the Solidity repository and adapted to our integration testing tool.

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 more optimizations to be done, some complex LLVM IR statements need to be translated into 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 a Rust compiler front end to allow writing smart contracts in native Rust.

Core infrastructure

zkSync 2.0 core consists of several key roles:

full node

Pre-circuit executor environment for zkEVM bytecode via a virtual machine

State is available within seconds of transaction sending

filtering discard obviously incorrect transactions that could bloat the block (e.g. insufficient funds for the transaction)

Execute the transaction in the mempool and generate the block

< h4>Prover

Receives the witness of the block and generates a zero-knowledge proof

Prover interface for parallel proof generation

Custom prover autoscaler that creates and terminates prover machines on demand

Interactor

A tool for viewing and interacting with Ethereum L1,

Calculate transaction fees based on Token price, ZKP generation cost and L1 gas price

Paranoid Monitor

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

This core infrastructure is fully functional and already has the zkEVM executor integrated!

Let's talk

When the compiler finishes, we will share access to all components together! Developers will be able to deploy Solidity/Zinc smart contracts and interact via the Web3 API.