zkSync 2.0: Hello Ethereum
introduce
introduce
Major achievements
Major achievements
On the compiler side, smart contracts written in Solidity and Zinc can now compile to zkEVM bytecode.
On the compiler side, smart contracts written in Solidity and Zinc can now compile to zkEVM bytecode.
In terms of core infrastructure, the full node integration is completed, and the compiled smart contract can be successfully deployed and executed.
zkSync 2.0 vs. Ethereum
zkSync 2.0 vs. Ethereum
The ADDMOD, SMOD, MULMOD, EXP, and CREATE2 opcodes are not supported in this release, but will be in the future.
Solidity smart contract
Most opcodes in Ethereum are supported! 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 currently support the KECCAK256 opcode, but will automatically replace all calls to it with calls to another collision-resistant hash function. KECCAK256 will be introduced later as a precompile.
We decided not to include the SELFDESTRUCT opcode because Ethereum plans to remove it.
cost
cost
The next release will include our implementation of the Web3 API, 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.
Web3 API
The next release will include our implementation of the Web3 API, 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 notion of committed and finalized blocks. Therefore, 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.
sign the deal
sign the deal
Users can sign transactions with their normal Ethereum wallet (such as Metamask or any WalletConnect wallet) by signing the EIP712 message.
Users can sign transactions with their normal Ethereum wallet (such as Metamask or any WalletConnect wallet) by signing the EIP712 message.
Improved storage efficiency
Improved storage efficiency
Precompiled
Precompiled
further restrictions
further restrictions
The first iteration of zkSync 2.0 may impose an additional limit of 32 smart contract calls per transaction until proper accounting mechanisms are implemented.
There will be a hard limit for execution tracking, but it is comparable to the current limit of Ethereum block size and should not affect most protocols.
Learn more about the zkSync 2.0 architecture
Learn more about the 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 within the scope of sacrificing some security, decentralization, and programmability for scalability. The design of zkSync 2.0 combines the following 2 technological breakthroughs to maximize all 4 functions:
zkEVM: The engine that powers our EVM-compatible zkRollup, the only solution backed by smart contracts for L1 security and reliability.
image description
(picture from zkSync)
Because zkEVM and zkPorter are interoperable and composable, zkSync 2.0 is able to significantly outperform all other scaling solutions.
state tree
state tree
The zkSync 2.0 state tree covers the full 160-bit address space of Ethereum. Each account will reside in either the zkRollup part or the zkPorter part of the state. zkRollup and zkPorter accounts are identical 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 data is published is a tradeoff between cost and security. zkPorter transactions are much cheaper than aggregate transactions, but it has the potential to result in your funds being frozen. However, the validity of zkRollup and zkPorter accounts are both guaranteed by zero-knowledge proofs and Ethereum. In other words, funds in zkPorter can only be frozen, not stolen.
Cryptography
Cryptography
Our VM, most commonly known as the zkEVM, is not a 1:1 copy of the EVM, but is designed to be able to run 99% of contracts written in Solidity and maintain the same behavior, such as during recovery and exceptions. Meanwhile, zkEVM is written to efficiently generate 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.
Once again, we are happy to announce that after several months of hard work: the zkEVM instruction set is complete and implemented in circuit and execution environments.
There is an important distinction here: the implementation in the circuit and the execution environment are separate and serve different purposes. The circuit's job is 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 zkEVM in rust, which is efficient and fast. If we relied on circuits to generate proofs and execute, transactions would take hours to finalize. The separation of proof generation and simple execution enables instant settlement of transactions on zkSync.
image description
translater
(picture from zkSync)
We are simultaneously working on two compiler front ends for zkEVM: 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.
The LLVM optimization framework is unmatched: it generates the most efficient zkEVM bytecode from LLVM IR.
The LLVM optimization framework is unmatched: it generates the most efficient zkEVM bytecode from LLVM IR.
With newer versions of Solidity or Zinc, the compiler frontend will handle all changes, while LLVM will save us from having to change the compiler backend.
Lexical, syntactic and semantic tests in Zinc and Yul compilers.
Compiler security is of utmost importance to us and has passed several suites of tests:
Lexical, syntactic and semantic tests in 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.
Each suite already contains thousands of tests, and we will increase this number by at least an order of magnitude.
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 converted to zkEVM bytecode. Therefore, we decided not to release the compiler until it was in a more robust state.
core infrastructure
core infrastructure
The core of zkSync 2.0 consists of several key actors:
full node
Pre-circuit executor environment via virtual machine's zkEVM bytecode
The state is available within seconds of the transaction being sent,
filter out obviously incorrect transactions (e.g. transactions with insufficient funds) that could lead to block bloat,
a prover interface for parallel proof generation,
certifier
Witnesses who receive blocks and generate zero-knowledge proofs,
a prover interface for parallel proof generation,
A custom prover autoscaler that creates and terminates prover machines as needed.
Tools for viewing and interacting with Ethereum L1,
Tools for viewing and interacting with Ethereum L1,
Transaction fees are calculated 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.
