Partnered With:

Detail the ethereum expansion scheme ZKSync2.0

Read this article in 558 Minutes

The test network of Ethereum expansion scheme ZKSync 2.0 has been online, and this paper analyzes it in detail

ZKSync 2.0: Hello Ethereum!

Originally written by Matter Labs

Block Uincorn

introduce

Facing our biggest technical challenge, we are sprinting toward deploying smart contracts in EVM-compliant environments. The first version of the test net is online: you can already view activity on ZKSync 2.0 using the block browser. In this article, we'll explain each of the key components in depth, provide progress updates, and plan for the next release.

The main achievements

· In terms of cryptography, the instruction set of ZKEVM 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 into ZKEVM bytecode.

· In terms of core infrastructure, full node integration is completed and the compiled smart contract can be successfully deployed and executed.

Although & have spent ZKEVM and the core 2.0 infrastructure are ready to be exposed, but the compiler needs more work to properly cover all edge cases. In order to provide a more comprehensive developer experience, we decided to open up access to ZKEVM, the compiler, and the core SDK as soon as the compiler was 100% reliable.

ZKSync 2.0 vs. Ethereum

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

Solidity smart contracts

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

1. Addmod, SMOD, MULMOD, EXP and CREATE2 opcodes are not supported in this version, but will be in the future.

2. We temporarily do not support the Keccak256 opcode, but will automatically replace all its calls with calls to another collision-resistant hash function. Keccak256 will be introduced later as precompiled.

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

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

cost

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 release of call data) and the cost of ZKP generation. Smart contract calls will have a maximum number of ZKEVM steps and store write parameters.

Web3 API

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

ZkSync contains features that L1 does not, such as the concept of committed and final blocks. As a result, there will be other ways for developers to control the data more precisely. The Web3 client code will receive the same data as Ethereum, but can request special information using the 'zksync_' namespace.

Because zkSync There are multiple transaction types and the EIP712 signature is used, so the 'eth_sendrawTransaction' data will have a different format than L1. However, encoding corresponds to the Ethereum ABI, so supporting it is not difficult.

Signed a deal

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

1. Users can sign transactions using their normal Ethereum wallet (such as MetaMask or any WalletConnect wallet) by signing the EIP712 message.

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

Storage efficiency improvement

Slot overlay should be applied only once per block. This means that if multiple users interact with a single AMM contract, the storage slot of the AMM contract will only be overwritten once. This allows the collator to later refund the user the shared cost of a single write.

precompiled

The "precompile" mechanism is planned, but will be released later. We plan to first support keccak256, sha256 hashes, and ECDSA recovery primitives. Depending on your requirements and complexity, consider including other precompilations, such as the Blake2f round function (which in its current form is almost impossible to use in Ethereum).

Further restriction

The first iteration of ZKSync 2.0 May impose an additional limit of 32 smart contract calls per transaction until a proper billing mechanism is implemented.

Perform trace will have a hard limit, but it is comparable to the current limit on 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 version.

Learn more about the ZKSync 2.0 architecture

You may have heard of the blockchain trilemma, but when it comes to expanding Ethereum, there's a fourth factor: programmability. All current extension solutions are in the realm of sacrificing some security, decentralization, and programmability for the sake of extensibility. The ZKSync 2.0 design combines the following two technological breakthroughs to maximize all four features:

1. ZKEVM: The engine that powers our EVM-compatible ZKROLLUP, the only solution with L1 security and reliability smart contract support.

2. ZKPorter: An off-chain data availability system that is two orders of magnitude more scalable than summaries.

(Image courtesy of ZKSync)

Because of ZKEVM and &NBSP; ZKPorter is interoperable and composable, so ZKSync 2.0 is able to significantly outperform all other extension solutions.

The current consensus is that ETH2 data sharding will arrive by the end of 2022 to provide exponentially greater layers of data availability 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 four factors.

State of the tree

The ZKSync 2.0 state tree covers Ethereum's full 160-bit address space. Each account will reside in either the ZKROLLUP or ZKPORTER sections of the state. The Zkrollup and Zkporter accounts are identical, except for one component: guaranteed data availability. ZKrollup transaction data is published to Ethereum via calldata, ZKPorter transaction data is published to the ZKSync Guardian network, and ZKSync token holders participate in the Proof of Proof.

Where the data is published is a trade-off between cost and security. The ZKPorter transaction is much cheaper than the aggregate transaction, but it may result in your funds being frozen. However, the validity of both Zkrollup and Zkporter accounts is guaranteed through zero-knowledge proof and Ethereum. In other words, money in ZKPorter can only be frozen and cannot be stolen.

The interoperability and composability of the ZKrollup and ZKPorter accounts gives each user the opportunity to become a first-class citizen in ZKSync. Uniswap deployed on the Zkrollup side can be accessed through a Zkporter account in exchange for a minimum fee. ZKSync 2.0 is a system designed to engage users across the financial sector.

cryptography

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

This is done without any major changes to our proof system; We continue to use Plonk with custom gates and lookup tables (commonly called Ultraplonk) as well as Ethereum's BN-254 curve. This is advantageous because the certification system has been field tested in ZKSync 1.0 and other projects using the same certification system since June 2020.

Once again, we are happy to announce that after several months of effort, the instruction set for ZKEVM has been completed and implemented in circuits and execution environments.

There is an important difference here: the implementation in the circuit and the execution environment is separate and used for different purposes. The circuit's job is to generate proof of 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, which is efficient and fast. If we rely on circuits to generate proof and execute, it will take hours for the transaction to finalize. The separation of proof generation and simple execution enables transactions on ZKSync to be settled on the fly.

Next, we focus on combining ZKEVM with the compiler and combining recursion together: recursion between blocks, which allows us to publish a proof for N blocks, and recursion within blocks, which aggregates subproofs of different logical parts of blocks. That's the easy part! Recursive aggregation proofs between blocks have been used on the mainnet of ZKSync 1.0 since June 2020. For more information about in-block recursion and how our ZKEVM works, watch this video description.

The compiler

(Image courtesy of ZKSync)

We are also working on two compiler front-ends for ZKEVM: YUL and ZINC. YUL is an intermediate Solidity representation that can be compiled into bytecode for different backends. Zinc is our Rust-based language for smart contracts and general zero-knowledge proof circuits.

Because the compiler is built using the LLVM framework, it can be thought of as having front-end YUL → LLVM IR → ZKEVM bytecode and back-end LLVM IR → ZKEVM. The adoption of LLVM brings several major advantages:

1. The LLVM optimization framework is unmatched: It generates the most efficient ZKEVM bytecode from the LLVM IR.

2. With a newer version of Solidity or ZINC, the compiler front end will handle all changes and LLVM will allow us to eliminate the need to change the compiler back end.

3. In the future, if developers want to write smart contracts in native Rust or JavaScript, they will simply build a compiler front end for that language and the smart contract will be available right out of the box in ZKSync.

The security of the compiler is critical to us and has passed multiple sets of tests:

1. Morphology, syntax, and semantic tests in ZINC and YUL compilers.

2. Our own Zinc and Solidity integration tests throughout the 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 that fits into our integrated test tools.

Each suite already contains thousands of tests, and we're going to increase that number by at least an order of magnitude.

Our two compilers have successfully deployed and executed simple smart contracts in both languages. But there is more optimization 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 functional, and then build the Rust compiler front end to allow you to write smart contracts using native Rust.