Introducing zkSync: the missing link to the mass adoption of Ethereum
Matter Labs’ trustless scaling & privacy engine built on ZK-rollup
Executive summary
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.
The hardest problems in blockchain scaling
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.
Challenge #1: Staying decentralized
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.
Challenge #2: Enabling privacy
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:
- Privacy must be on by default as an integral protocol feature. To quote Vitalik Buterin: “If your privacy model has a medium anonymity set, it really has a small anonymity set. If your privacy model has a small anonymity set, it has an anonymity set of 1. Only global anonymity sets are truly robustly secure.”
- To enable privacy by default, private transaction costs must be very low, despite significant added computational overhead.
- Privacy models must support programmability, because real-world use cases need more than just transfers: they require account recovery, multi-sigs, spending limits, etc.
Challenge #3: Meeting UX expectations
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.
The promise of zkSync: trustless, confidential, and blazing fast.
In this technical write-up, we will explore the high-level architecture, design choices, and properties of the proposed protocol.
1. Security: Rooted in ZK Rollup
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:
- The Rollup validator(s) can never corrupt the state or steal funds (unlike Sidechains).
- Users can always retrieve the funds from the Rollup even if validator(s) stop cooperating because the data is available (unlike Plasma).
- Thanks to validity proofs, neither users nor a single trusted third party needs to be online to monitor Rollup blocks in order to prevent fraud (unlike fraud-proof systems, such as payment channels or optimistic rollups). This excellent article dives deep into the overwhelming benefits of validity proofs over fraud proofs.
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.
2. Usability: real-time transactions
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:
- Instant
- Potentially reversible, but only within a few minutes
- Only reversible in a simultaneous attack against thousands of merchants, not one-by-one.
This is a huge UX and security improvement over credit card payments! Let’s look at it from the perspective of different actors:
- Online stores with physical goods may instantly confirm a purchase to a user, but are immune against attack because they will wait for the full confirmation before shipping.
- Physical stores are practically unsusceptible to attack when dealing with smaller amounts. Even if you’re selling a Macbook against an instant tx receipt, it would take thousands of coordinated physical attackers in different locations AND a collusion of the majority of validators to cause you to lose money.
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.
3. Liveness: censorship- and DoS-resistance
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
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
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.
4. Programmability and privacy: the building blocks
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.
4.1. RedShift: transparent universal SNARK
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.
4.2. Zinc: framework for zero-knowledge smart contracts
In the design of ZK Sync’s programmability model, we have committed to an ambitious combination of several orthogonal goals:
- High scalability
- Support for both public and private smart contracts
- Most importantly: a flat learning curve and easy development
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.
ZK Sync v0.1 testtnet is live!
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.
