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
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 <<
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.
Most things look and feel the same. Here are a few important differences:
Most opcodes in Ethereum are supported! However, there are a few exceptions:
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.
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.
Transactions in zkSync 2.0 can be authorized in 2 ways (in addition to the priority queue mechanism):
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.
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.
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.
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:
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 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.
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.
https://miro.medium.com/max/1400/0*S3TKmlfGRTx5MNkE
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:
The security of the compiler is paramount to us, and has already gone through multiple suites of tests:
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.
zkSync 2.0 core consists of several key actors:
The Full Node
The Prover
The Interactor
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!
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!
我可以把你比作夏日吗？
你的可扩展性和安全性更高。
狂风确实震撼了五月亲爱的心灵，
夏天的租约日期太短了。
——中本聪莎士比亚，2021
面对最大的技术挑战，我们开始在与 EVM 兼容的环境中部署智能合约。测试网的第一个版本已经上线：您已经可以使用区块浏览器查看 zkSync 2.0 上的活动。在这篇文章中，我们将深入解释每个关键组件、提供进度更新以及下一个版本的计划。
在密码学方面，zk EVM 的指令集已经完成，两种实现都完成了：在电路中和在执行环境中。
在编译器方面，用 Solidity 和 Zinc 编写的智能合约现在可以编译成 zkEVM 字节码。
在核心基础设施方面，全节点集成已完成，能够成功部署和执行已编译的智能合约。
虽然 zk EVM 和核心 2.0 基础设施已准备好公开，但编译器需要做更多工作才能正确覆盖所有边缘情况。为了提供更全面的开发者体验，我们决定在编译器 100% 可靠后立即开放对 zkEVM、编译器和核心 SDK 的访问。
大多数东西看起来和感觉都是一样的。以下是一些重要的区别：
支持以太坊中的大多数操作码！但是，也有一些例外：
此版本不支持 ADDMOD、SMOD、MULMOD、EXP 和 CREATE2 操作码，但将来会支持。
我们暂时不支持 KECCAK256 操作码，而是通过调用另一个抗冲突哈希函数来自动替换其所有调用。KECCAK256 稍后将作为预编译器引入。
我们决定不包含 SELFDESTRUCT 操作码，因为以太坊计划将其删除
。
我们可能会取消对完整 256 位 XOR/AND/OR 操作码的支持，因为这些操作码仅存在于已编译的用于位掩码的 Solidity 代码中。这可以由编译器使用其他操作码来完成。
在 zkSync 2.0 中，有一个不同的 gas 概念。交易价格将根据当前的 L1 gas 价格（由于发布调用数据）和 ZKP 生成成本而波动。智能合约调用将具有最大数量的 zk EVM 步骤和存储写入参数。
下一个版本将包括我们的 Web3 API 实现，它将与以太坊文档定义的 Web3 标准兼容。事件将开箱即用，所有服务都可以轻松集成。
zkSync 包括 L1 没有的功能，例如提交和最终块的概念。因此，将会有额外的方法让开发人员更精确地控制数据。Web3 客户端代码将接收与您在以太坊上相同的数据，但可以使用“zksync_”命名空间请求专门的信息。
因为 zkSync 有多种交易类型，并且使用 EIP712 签名，所以 eth_sendRawTransaction 数据的格式会与 L1 不同。但是，编码对应于以太坊 ABI，所以支持它并不困难。
zkSync 2.0 中的交易可以通过 2 种方式授权（除了优先队列机制）：
每个块仅应用一次存储槽覆盖。这意味着如果多个用户与单个 AMM 合约交互，则 AMM 合约的存储槽只会被覆盖一次。这允许定序器在以后向用户退还单次写入的共享成本。
“预编译”机制已计划好，但稍后会发布。我们计划首先支持 keccak256、sha256 哈希和 ECDSA 恢复原语。根据需求和复杂性，可以考虑包含其他预编译，例如 Blake2f 轮函数（在当前形式的以太坊中几乎无法使用）。
zkSync 2.0 的第一次迭代可能会对每笔交易施加 32 次智能合约调用的额外限制，直到实施适当的记账机制。
执行跟踪将有一个硬限制，但它与以太坊块大小的当前限制相当，不应影响大多数协议。
可能会有更多限制，但我们的目标是在最终版本中将它们减少到绝对最低限度。
您可能听说过区块链三难困境，但在扩展以太坊时，还有第四个因素：可编程性。所有当前的扩展解决方案都存在于牺牲一些安全性、分散性和可编程性以实现可扩展性的范围内。zkSync 2.0 的设计结合了以下 2 项技术突破，最大限度地发挥了所有 4 项功能：