Update June 18 2020: zkSync v1 is live on Mainnet!!!
A successful solution to the scaling problem in public blockchains is not only a matter of high transaction throughput. It must also be defined as the ability of the system to meet the demands of millions of users without sacrificing decentralization. The prerequisites of mass crypto adoption include high speed, low cost, smooth UX, and privacy.
In the absence of a technological breakthrough, existing scaling solutions have had to make heavy compromises on one or more of these requirements. Luckily, recent advances in zero-knowledge proofs open up radical new possibilities to address this problem.
Today, we at Matter Labs are excited to reveal our vision for zkSync: a trustless scaling and privacy solution for Ethereum based on ZK Rollup, with an emphasis on superb user and developer experiences. We’re also proud to announce the launch of the testnet for zkSync.
ZK Sync is designed to bring a VISA-scale throughput of thousands of transactions per second (TPS) to Ethereum while keeping the funds as secure as in the underlying L1 accounts and maintaining a high degree of censorship-resistance. Another important aspect of the protocol is its ultra-low latency: transactions in ZK Sync will provide instant economic finality.
We subscribe to a lean design philosophy and favor a gradual protocol evolution that introduces features one-by-one in a sequence that brings the most tangible value to users at each step. This is why we are starting with the fundamentals (security), focusing initially on basic scalability (token transfers), then on programmability (smart contracts), and, finally, on privacy.
Today, in practice, crypto is still used mostly for speculation. Without real mass adoption, the value proposition of magic internet money, DeFi, Web 3.0 and all other promising blockchain ideas will remain largely unfulfilled.
Scalability is not merely transaction throughput, but the overall readiness of blockchain systems to meet the demands of millions of users.
Let’s consider three of the hardest problems in expanding the blockchain revolution to the masses.
Real-world adoption requires transaction throughput that is an order of magnitude higher than what today’s most decentralized blockchains can handle. Bitcoin is capable of 7 TPS, Ethereum manages 15 — while VISA alone is processing a daunting 2000 TPS on average.
But the slowness of Bitcoin and Ethereum is a feature, not a bug! It is trivially possible to increase the speed by reducing the number of validators. The huge number of full nodes that both leading blockchain networks can boast of is their most critical asset. This provides resilience, and is what actually makes these blockchains fundamentally different from existing financial institutions.
An alternative popular scalability approach is to require each validator to check only part of the relevant blockchain traffic, rather than all of it. But this inevitably introduces additional trust assumptions and puts such systems on very shaky game-theoretical grounds.
Most people won’t feel comfortable moving large parts of their fortune into a publicly exposed glass box. Inhabitants of dangerous places — Venezuela, for instance — are unlikely to pay a local merchant in crypto if the recipient can immediately learn how much money they have. People creating or consuming obscene content, such as pornography, will be unlikely to use crypto as an alternative to Paypal if these payments can potentially be linked to their real-world identities.
Moreover, in the absence of on-chain confidentiality, privacy regulations like GDPR and CCPA will drive ordinary businesses away from public blockchains towards more centralized payment and financial hubs, turning our increasingly cashless society into a surveillance nightmare.
Privacy is an absolute prerequisite for mass adoption.
Achieving privacy in public blockchains is especially difficult due to several factors:
The reality is harsh: product managers know well that users routinely prefer easier, more lightweight experiences with instant gratification over alternatives, often ignoring the long-tail risks. It takes an extraordinary force to coax users into switching from what is familiar to something new. For some people, the value proposition of crypto (radical self-ownership, censorship-resistance, sound money) is enough. But those folks are probably already on board. We need millions, if not billions, to reach the requisite scale for crypto to deliver on its promise.
To attract millions of mainstream users, we need to offer them a user experience that doesn’t just match these expectations, but exceeds them. We must do this providing entirely new possibilities while keeping all the convenient properties of traditional Web products that people have become accustomed to. Everything must be fast, simple, intuitive and error-tolerant.
In this technical write-up, we will explore the high-level architecture, design choices, and properties of the proposed protocol.
ZK Sync is built on the concept of ZK Rollup.
In a nutshell, ZK Rollup is an L2 scaling solution in which all funds are held by a smart contract on the mainchain, while computation and storage are performed off-chain. For every Rollup block, a state transition zero-knowledge proof (SNARK) is generated and verified by the mainchain contract. This SNARK includes the proof of the validity of every single transaction in the Rollup block. Additionally, the public data update for every block is published over the mainchain network as cheap calldata.
This architecture provides the following guarantees:
In other words, ZK Rollup strictly inherits the security guarantees of the underlying L1. This, together with the richness of the Ethereum community and existing infrastructure, was a decisive factor in our decision to focus on an L2 solution instead of trying to build our own L1.
To better understand the concept, please refer to our video explainers from talks at ZCon1 and Dappcon, a podcast featuring Matter Labs at zeroknowledge.fm, or our earlier technical explainer post. Curious readers can also explore the differences between ZK Rollup and Optimistic Rollup in this post.
Following a grant from the Ethereum Foundation, Matter Labs has spent the past year working on ZK Rollup technology. We have completely rewritten the architecture and ZK circuit since the launch of the first prototype. The newest version incorporates feedback we received from the community and implements various usability and performance improvements.
We expect current developments in ZK prover technology to reach proving times that will enable ZK Rollup blocks to be produced in under a minute. Once a block proof is submitted to the mainchain and verified by the Rollup smart contract, all transactions in this block are finalized and are now subject to L1 reorg-resistance guarantees.
But in retail and online payments, even Ethereum’s 15-second block latency can be too long. How can we do better?
Here’s how: in ZK Sync we’re introducing instant tx receipts.
Validators elected to participate in ZK Sync block production will have to post a significant security bond to the ZK Sync smartcontract on the mainnet. A consensus run by the validators provides a subsecond confirmation to the user that their transaction will be included in the next ZK Sync block, signed by a supermajority of ⅔ of the consensus participants (weighted by stake).
If a new ZK Sync block is produced and submitted to the mainchain, it cannot be reverted. However, if it doesn’t contain the promised transaction, the security bond of the intersection of the signers of the original receipt and the signers of the new blocks will be slashed. This intersection is guaranteed to have more than ⅓ of the stake. This guarantees that at least ⅓ of the security bond is slashable, and that only malicious users will be punished.
A portion of the slashed funds will be used to compensate the tx recipient. The rest will be burned.
The slashing can be triggered either by users themselves or by any of the honest participants in the consensus who have signed the original tx receipt. The latter will have a natural incentive to call the fraud: if they participate in the subsequent block production, they can be slashed too. Thus at least one honest participant in the consensus is sufficient for fraud detection.
Let’s examine the properties of this protocol. We will call a zero-confirmation tx a transaction with an instant receipt for a ZK Sync block which has not yet been published to Ethereum.
A double spend of zero-confirmation transactions on ZK Sync is only potentially exploitable in a very short time window of a few minutes until the block proof is published on the mainchain. Further, malicious validators would have to trick users into accepting zero-confirmation transactions worth over ⅙ of the security bond.
From the point of view of both buyers and merchants, zero-confirmation transactions are:
This is a huge UX and security improvement over credit card payments! Let’s look at it from the perspective of different actors:
But let’s dig deeper. To quantify the risks, the economic guarantee provided by the bond can be compared to the settlement assurance provided by proof-of-work blockchains (see this great write up by Nic Carter). For example, Coinbase requires 35 tx confirmations before considering a deposit final on Ethereum. The cost of reverting this transaction by running a 51% attack for 10 minutes on GPUs rented from AWS is roughly $60,000. Assuming millions of USD in the security bond, it would be much more expensive to revert an instant ZK Sync receipt. Thus, instant receipts are generally likely to have ETH-like or even better economic finality properties.
It’s important to note that instant tx receipts also protect against ETH block reorgs, because their validity is independent of Ethereum. Additionally, Ethereum’s settlement assurance compounds with the settlement assurance of ZK Sync.
An inevitable property of any scaling solution is that most users cannot participate in verifying all of the transaction volumes. This leads to the need for specialized roles in all L2 scalability solutions (validators in Plasma or Rollups, Lightning hubs, and so on). The increased security and performance requirements imposed by these roles pose a risk of centralization and censorship.
The ZK Sync design tackles this issue by introducing two different roles in the long run: Validators and Guardians.
Validators are responsible for packing transactions into blocks and generating zero-knowledge proofs for them. They participate in the consensus and must, therefore, contribute a share of the security bond for instant tx receipts. Their nodes must run in a secure environment with good internet bandwidth. Alternatively, they may choose to generate ZK proofs in the unsecured on-demand cloud.
Validators are rewarded with transaction fees, which can be paid in any token being transacted (for the maximum convenience of end-users).
In order to keep the ZK Sync consensus fast, only a limited number of validators are allowed at any moment (between 30 and 100, subject to profiling). Recall, however, that ZK Rollup validators are completely trustless. In ZK Sync, malicious validators can neither jeopardize the security of the system nor trick honest validators into slashing conditions. Therefore, unlike in optimistic rollups, a small set of validators can be frequently rotated by the Guardians. At the same time, the liveness of the consensus is guaranteed as long as more than ⅔ of the nominated validators are honest and operational.
Guardians comprise the majority of ZK Sync token holders who stake their token share to nominate validators. The purpose of Guardians is to monitor peer-to-peer transaction traffic, detect censorship behavior, and ensure validators caught censoring are not nominated. The motivation of Guardians is to protect the value of their stake by making sure that ZK Sync remains DoS- and censorship-resistant.
Despite keeping the voting keys online, Guardians in ZK Sync are never exposed to risk of slashing or theft (the ownership keys can be kept in cold storage). They may also choose to monitor only a fraction of the traffic. Thus, their nodes can be run on ordinary laptops or cloud servers, i.e. there is no need for specialized validator services.
Guardians are rewarded with fees from the Validators denominated in the ZK Sync native token. Their earnings and stakes are locked for a prolonged period of time.
Achieving efficient programmability and privacy is the most difficult part of the ZK Sync vision. It requires solid design and implementation for both an appropriate zero-knowledge proof system and a smart contract programming framework.
The biggest blocker for implementing ZK-based smart contracts (whether transparent or privacy-preserving) has been the lack of efficient generic ZK proof systems with recursive composition. Groth16, the most efficient ZK SNARK at the time, required an application-specific trusted setup, and would lose a lot of efficiencies when recursion applied. FRI-based STARKs, on the other hand, require highly specialized skills to construct and lack efficient recursive composition of arbitrary generic circuits.
This was one of the main motivations for our work on RedShift: a new transparent, efficient and fully succinct SNARK derived from our FRI-based polynomial commitment scheme. We’re currently in the process of incorporating peer-review and community feedback, and will then deploy RedShift as a core part of ZK Sync.
Redshift is a universal SNARK, which allows us to use it to conveniently convert arbitrary programs into provable ZK circuits. Heterogenous circuits (e.g. different smart contracts) can be recursively composed in one SNARK. RedShift is plausibly post-quantum secure since it relies exclusively on collision-resistant hash functions.
In the design of ZK Sync’s programmability model, we have committed to an ambitious combination of several orthogonal goals:
A number of outstanding projects share some of these goals, but none commits to all of them at once. For example, ZkVM offers a virtual machine for generic confidential smart contracts, but is based on bulletproofs and doesn’t support succinct proof aggregation. ZEXE has an excellent privacy-preserving design, but requires an in-depth understanding of the zero-knowledge circuit specifics and trade-offs, raising the barrier of entry very high for the broader circle of programmers. Other, simpler ZK programming frameworks lack the expressiveness or features necessary for safe smart contract development.
This led to our decision to create Zinc: a safe, simple and efficient programming framework and VM-based runtime-environment, designed specifically for ZKP-based smart contracts.
The key design priorities of SyncVM are safety and developer-friendliness. The programming language for defining contracts, closely follows a simplified Rust syntax, with smart-contract programming elements borrowed from Solidity and Libra’s Move. It does not require developers to deeply understand the specifics of the ZKP domain to write efficient and secure programs. In fact, Zinc can be learned in one day by developers with a background in Rust, Solidity, C++ or similar programming languages.
Consider a part of program written in Rust for the Bellman framework (ZEXE has a similar API) and the same piece in Zinc:
Zinc v0.1 will be released in January 2020.
The testnet for ZK Sync v0.1 is live. The scope of this version is limited to ETH and ERC20 token transfers in a single-operator setting.
The launch of the v0.1 devnet is the first step on the long journey of bringing the ZK Sync vision to life. It will take a lot of research, experimentation and development effort. Some design aspects may change as we learn and incorporate feedback. But we promise that the aspiration will remain unchanged: ZK Sync is going to be a bridge for bringing millions of users into crypto. We are setting a high bar for user experience and will demonstrate that zk-technology is capable of providing a Web-like experience without sacrificing the values of the blockchain revolution.
You can follow our progress on Matter Labs’ Twitter, public Telegram channel, or by subscribing to our (very occasional) newsletter.
If you want to contribute to ZK Sync development, please talk to us. We are always looking for talented engineers and cryptographers to join our team.
公共区块链扩容问题的成功解决方案不仅仅是高交易吞吐量。它还必须定义为系统在不牺牲去中心化的情况下满足数百万用户需求的能力。大规模采用加密货币的先决条件包括高速、低成本、流畅的用户体验和隐私。
在没有技术突破的情况下，现有的扩展解决方案不得不对这些要求中的一项或多项做出重大妥协。幸运的是，零知识证明的最新进展为解决这个问题开辟了全新的可能性。
今天，我们Matter Labs很高兴展示我们对zkSync的愿景：基于 ZK Rollup 的以太坊去信任扩展和隐私解决方案，强调卓越的用户和开发人员体验。我们也很自豪地宣布推出 zkSync 测试网。
ZK Sync 旨在为以太坊带来每秒数千笔交易 (TPS) 的 VISA 规模吞吐量，同时保持资金与底层 L1 账户一样安全，并保持高度的抗审查性。该协议的另一个重要方面是其超低延迟：ZK Sync 中的交易将提供即时的经济终结性。
我们赞同精益设计理念，并支持渐进式协议演进，即按顺序逐个引入功能，从而在每一步为用户带来最切实的价值。这就是为什么我们从基础（安全）开始，首先关注基本的可扩展性（代币转移），然后关注可编程性（智能合约），最后关注隐私。
今天，在实践中，加密仍然主要用于投机。如果没有真正的大规模采用，神奇的互联网货币、DeFi、Web 3.0 和所有其他有前途的区块链理念的价值主张将在很大程度上无法实现。
可扩展性不仅仅是交易吞吐量，而是区块链系统满足数百万用户需求的整体准备情况。
让我们考虑将区块链革命扩展到大众的三个最困难的问题。
实际采用需要比当今最分散的区块链可以处理的交易吞吐量高一个数量级。比特币能够达到 7 TPS，以太坊管理 15 - 而仅 VISA 就平均处理了令人生畏的 2000 TPS。
但是比特币和以太坊的缓慢是一个特点，而不是一个错误！通过减少验证者的数量来提高速度是很容易的。两个领先的区块链网络都可以吹嘘的大量完整节点是他们最关键的资产。这提供了弹性，并且实际上使这些区块链与现有金融机构有根本不同。
另一种流行的可扩展性方法是要求每个验证者只检查部分相关的区块链流量，而不是全部。但这不可避免地会引入额外的信任假设，并将此类系统置于非常不稳定的博弈论基础上。
大多数人都不愿意将大部分财富转移到一个公开的玻璃盒子里。如果收款人可以立即知道他们有多少钱，那么危险地方的居民（例如委内瑞拉）就不太可能用加密货币向当地商人付款。如果这些支付可能与他们的真实身份相关联，那么创建或消费淫秽内容（例如色情内容）的人不太可能使用加密货币作为Paypal 的替代品。
此外，在缺乏链上保密性的情况下，GDPR 和 CCPA 等隐私法规将推动普通企业从公共区块链转向更集中的支付和金融中心，将我们日益无现金的社会变成监控的噩梦。
隐私是大规模采用的绝对先决条件。
由于以下几个因素，在公共区块链中实现隐私尤其困难：
现实是残酷的：产品经理清楚地知道，用户通常更喜欢更简单、更轻量级的即时满足体验，而不是替代方案，往往忽略了长尾风险。诱使用户从熟悉的事物切换到新事物需要非凡的力量。对于某些人来说，加密货币的价值主张（激进的自我所有权、抗审查、稳健的货币）就足够了。但那些人可能已经在船上了。我们需要数百万甚至数十亿，才能达到加密货币兑现承诺所需的规模。