ZK Sync: A key link in the popularization of Ethereum
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Ethereum enthusiasts (ID: ethfans)
summary
, Author: Alex Gluchowski, Translator & Proofreader: Min Min & A Jian, reproduced by Odaily with authorization.
first level title
summary
To successfully solve the scalability problem of public chains, it is not just about improving transaction throughput. The so-called scalability means that the system must be able to meet the needs of millions of users without the expense of decentralization. The prerequisites for large-scale popularization of cryptocurrency are fast speed, low cost, smooth user experience, and privacy protection.
In the absence of technological breakthroughs, existing scalability solutions have to make significant compromises on one or more conditions. Fortunately, recent advances in zero-knowledge proof technology have brought us even more new solutions.
Today, we, the Matter Labs team, are excited to announce the vision of ZK Sync: a trustless scalability and privacy solution based on ZK Rollup, designed to bring great user and developer experience. We are also proud to announce that ZK Sync’s developer testnet is live.
ZK Sync aims to increase the throughput on Ethereum to thousands of transactions per second like VISA, while ensuring that funds are as secure as they are stored in the underlying account and maintain a high level of censorship resistance. Another important aspect of the protocol is its extremely low latency: transactions on ZK Sync have instant economic finality.
We agree with the concept of lean design, and support advancing the protocol in a step-by-step manner, introducing each function one by one in order, so that each step can bring the most practical value to users. That’s why we started with the basics (security), focusing first on basic scalability (token transfers), then programmability (smart contracts), and finally privacy.
ZK Sync features at a glance:
Strictly equal to the security of L1
Sub-second transaction confirmation speed
Anti-censorship, anti-DoS attack
Privacy Preserving Smart Contract
first level title
The Biggest Challenge of Blockchain Expansion
The value propositions of blockchain concepts such as Internet currency, DeFi, and Web 3.0 cannot be realized to a large extent until they are truly popularized.
Scalability refers not only to transaction throughput, but also whether a blockchain system can meet the demands of millions of users.
Let’s take a look at the three biggest challenges in bringing the blockchain revolution to the masses.
secondary title
To scale blockchains in real life, the transaction throughput of the most decentralized blockchains today is an order of magnitude worse. The Bitcoin network can process 7 transactions per second, the Ethereum network can process 15 transactions per second - and VISA can process an average of 2000 transactions per second.
However, with Bitcoin and Ethereum, inefficiency is a feature, not a bug! Simply reducing the number of validators can easily speed up transaction processing. As the two top blockchain networks, a large number of full nodes on Bitcoin and Ethereum are their most important assets. So this brings resilience to the blockchain, fundamentally differentiating it from existing financial institutions.
Another popular scaling solution is to require each validator to validate only a portion of the relevant blockchain traffic, rather than all traffic. But this will inevitably introduce additional trust assumptions, and the game theory foundation on which the system is based will become extremely fragile.
secondary title
Challenge Two: Achieving Privacy
Most people would not like to transfer large amounts of wealth in full view. Residents of volatile regions—Venezuela, for example—are unlikely to be willing to pay in cryptocurrency if it immediately reveals how much money they have. People who produce or consume adult content (e.g., pornography) would not be able to use cryptocurrencies as a substitute for Paypal if their identities could be revealed at the time of payment.
Additionally, without on-chain confidentiality, privacy regulations like the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act of 2018 (CCPA) can drive common businesses away from public chains to more centralized Globalized payments and financial hubs are turning our increasingly cashless society into a surveillance nightmare.
Privacy is a must for popularizing blockchain.
Privacy must be the default configuration of the protocol. To quote Vitalik Buterin, "If the anonymity set of the privacy model is moderately sized, it is actually very small. If the anonymity set of the privacy model is small, it is practically equivalent to nothing. Only a global anonymity set is truly Robust and reliable."
For covert transactions to be the default choice, the transaction fees for covert transactions must be very low, but technically, covert transactions will inevitably bring high computational costs.
The privacy model must be programmable, as real-world use cases are not limited to money transfers: account recovery, multisig, and spending limits are also required, among others.
Challenge 3: Achieving the desired user experience
The reality is cruel: Product managers know that users prefer lighter, lighter experiences that bring immediate gratification, but ignore long-tail risks. It takes a lot of force to entice users to switch from something familiar to something new. For some, the value proposition of cryptocurrencies (radical self-sovereignty, censorship resistance, and sound money) is attractive enough. But these people are likely to have entered the market. For cryptocurrencies to live up to their original promise, their user base needs to be in the millions, if not billions.
first level title
The ZK Sync Promise: Trust Free, Confidential, Fast
This article explains our architecture, design principles, and desirable properties of our proposed protocol. Of course, the explanation process is indispensable to explain the technology.
secondary title
1. Security: Rooted in ZK Rollup
ZK Sync is built based on the concept of ZK Rollup.
In short, ZK Rollup is a two-layer scaling solution, where all funds are stored in smart contracts on the main chain, while computation and storage are performed off-chain. Every time a new Rollup block is created, a zero-knowledge proof (SNARK) of state transition will be generated and submitted to the contract on the main chain for verification. This SNARK contains proofs of the validity of all transactions in the Rollup block. In addition, the public data update of each block will be published on the main chain as cheap calldata.
This architecture provides the following guarantees:
Rollup validators can never corrupt state or steal funds (unlike sidechains).
Even if validators are uncooperative, users can recover funds on Rollup because Rollup has data availability (unlike Plasma).
Thanks to validity proofs, neither users nor trusted third parties need to monitor Rollup blocks online to prevent fraud (unlike systems using false positives such as payment channels or optimistic rollups). Here is a high-quality article (Editor's Note: For the Chinese translation, see the hyperlink at the end of the article "Validity Proof vs. Falseness Proof"), which discusses in depth the overwhelming advantages of validity proofs over falsehood proofs.
In other words, ZK Rollup strictly inherits the security guarantee of the underlying chain. It is with this security guarantee, coupled with the rich Ethereum community and existing infrastructure, that we decided to focus on Layer 2 solutions instead of trying to build our own underlying chain.
For a better understanding of this concept, see our presentations at ZCon1 and Dappcon, our podcast about Matter Labs on zeroknowledge.fm, and our earlier tech explainer posts. Curious readers can also read this article (Editor's team: see "Optimistic vs ZK rollup, check it out" at the end of the article for hyperlinks) to understand the difference between ZK Rollup and Optimistic Rollup.
With funding from the Ethereum Foundation, Matter Labs has been researching ZK Rollup technology for the past year. Since the release of the first prototype, we have completely rewritten the architecture and ZK circuitry. The latest release incorporates feedback we've received from the community and implements various usability and performance improvements.
complete trustlessness
Have the same security guarantee as the underlying chain (Ethereum)
The certainty of being endorsed by Ethereum after the first confirmation
secondary title
2. Usability: real-time transactions
We expect the latest developments in ZK Proof technology to shorten proof times, bringing ZK Rollup block generation times to under a minute. Once the block proof is submitted to the main chain and verified in the Rollup smart contract, all transactions in this block will be finalized and protected by Layer-1's ability to resist chain reorganization.
However, a block delay of only 15 seconds on Ethereum is a long time for retail and online payments. How can we do better?
The solution is to introduce instant transaction receipts (instant tx receipts) in ZK Sync.
Validators who choose to participate in ZK Sync block production must submit a sizeable security deposit to the ZK Sync smart contract on the mainnet. Consensus reached by validators provides users with sub-second confirmation that their transactions are included in the next ZK Sync block and signed by a majority (2/3) of consensus participants (weighted by stake).
If a new ZK Sync block is created and submitted to the main chain, it cannot be withdrawn. However, if the block does not contain committed transactions, the security deposit of the validator who signed the original receipt and the new block is forfeited. The security deposit pledged by these validators must exceed 1/3 of the total amount. In other words, the penalty will cover 1/3 or more of the security deposit, and only malicious validators will be punished.
Part of the forfeited amount will be used to compensate the transaction recipient, and the rest will be burned.
The slashing mechanism can be triggered either by the user himself or by any honest consensus participant who has signed the original transaction receipt. The latter have an inherent incentive to trigger the slashing mechanism: if they participate in the next round of block production, they may also be punished. Therefore, just one of the consensus participants being honest is enough to detect fraud.
Let's elaborate again: In ZK Sync, we have designed a zero-confirmation transaction mode, which means that a transaction is accompanied by an instant transaction data, and the receipt will point to a ZK Sync block that has not yet been published on the chain.
There are only a few minutes to double-spend a zero-confirmation transaction on ZK Sync before the block proof is published to the main chain. In addition, if a malicious verifier wants to trick users into believing that their transaction has become a zero-confirmation transaction, they must prepare for 1/6 of the security reserve to be confiscated.
From the point of view of buyers and sellers, a zero-confirmation transaction is:
real time
There is a possibility of a reversal, but only for a few minutes
Only reversible if attacking thousands of sellers simultaneously rather than individually
Compared with credit card payment, ZK Sync has greatly improved user experience and security!
Now let's look at it from the perspective of different players:
Online stores that sell physical goods immediately confirm the order to the user, but are immune to attacks because the seller waits for full confirmation before shipping.
Brick and mortar stores are almost impossible to attack when the transaction volume is low. Even if you sell a Macbook with an instant receipt, it would take thousands of coordinated attackers in different locations to launch the attack, and rely on the collusion of a majority of validators to succeed.
Let's go a little deeper. In order to quantify the risk, we can compare the economic guarantee provided by the margin with the settlement guarantee provided by the PoW blockchain (see an article written by Nic Carter here) ). For example, it takes 35 transaction confirmations before Coinbase accepts a deposit of Ethereum funds. If a 51% attack is launched by renting a GPU through Amazon cloud services, it will take 10 minutes to withdraw the transaction, and the cost is about $60,000. Assuming a security deposit of millions of dollars, the cost of withdrawing an instant ZK Sync receipt would be much higher. Therefore, the economic certainty of these instant receipts is as much as Ethereum.
Summary: Live Trading
The economic certainty of sub-second transaction confirmation is comparable to that of Ethereum
Endorsed by Ethereum in minutes
secondary title
3. Reactivity: Anti-censorship and anti-DoS attacks
A necessary property of scaling schemes is that most users cannot participate in the verification of all transactions. Therefore, all Layer 2 scaling solutions require a dedicated role (validators on Plasma and Rollup, Lightning hub, etc.). This type of role has high requirements for security and performance, which brings risks of centralization and censorship.
In order to solve this problem, ZK Sync introduces two different roles in the design: verifier and guardian.
Validator
Validators are responsible for packaging transactions into blocks and generating zero-knowledge proofs for those blocks. They participate in the consensus mechanism and therefore must post a security deposit in order to create instant transaction receipts. Validator nodes must operate in a secure environment with good network bandwidth. Alternatively, they may generate zero-knowledge proofs on an insecure cloud platform if they wish.
Validators are rewarded with transaction fees, paid in tokens being traded (maximum convenience for end users).
In order to quickly reach a ZK Sync consensus, the number of verifiers is limited (according to our analysis, it is more appropriate between 30 and 100). But don’t forget that ZK Rollup validators are completely trustless. On ZK Sync, malicious verifiers can neither destroy the security of the system nor deceive honest verifiers to trigger the slashing mechanism. Therefore, unlike optimistic rollup, the guardian of the system (Guardian) can frequently replace a small number of verifiers. At the same time, liveness is guaranteed as long as 2/3 of nominated validators are honest and operational.
Guardian
A majority of ZK Sync token holders who nominate validators by staking their token share will become guardians. The purpose of the Guardians is to monitor peer-to-peer transaction traffic, detect censorship, and ensure that censoring validators are not nominated. In order to protect their collateral from being slashed, guardians must ensure that ZK Sync is DoS-resistant and censorship-free.
While voting keys are generally kept online, this presents no risk of slashing or theft to guardians on ZK Sync (ownership keys are stored cold). Guardians can then choose to monitor only a small portion of traffic. Therefore, guardian nodes can run on ordinary laptops or cloud servers, that is, there is no need to provide dedicated verifier services.
Guardians are rewarded with validator fees in the form of ZK Sync native tokens. Its earnings and deposits will be locked for a longer period of time, thereby promoting the long-term appreciation of ZK Sync tokens.
Two roles: validators and guardians, both incentivized by transaction fees
Validators run the consensus mechanism and generate proofs
Censorship-proof by Guardians running on commodity hardware
secondary title
4.1 RedShift: Transparent Universal SNARK
To realize smart contracts based on zero-knowledge proof (whether it is transparent or privacy-protected), the biggest obstacle is the lack of an efficient and general zero-knowledge proof system (efficient generic ZK proof systems with recursive composition) realized by recursive composition. . Groth16 was the most efficient ZK SNARK, but it required a dedicated set of trusted initializations for each application, and was inefficient when recursive. On the other hand, FRI-based STARKs require highly specialized construction skills and lack efficient recursive composition for arbitrary general circuits.
This is also one of our main motivations for developing RedShift: to derive a transparent, efficient and concise new type of SNARK from the polynomial commitment scheme based on the FRI protocol. We are currently undergoing peer review and community feedback before deploying RedShift as a core part of ZK Sync.
Redshift is a general-purpose SNARK that allows us to convert arbitrary programs into provable ZK circuits. Heterogeneous circuits (eg, different smart contracts) can be composed in a SNARK in a recursive manner. RedShift relies only on collision-resistant hash functions and can thus be considered post-quantum secure.
Transparent: no trusted setup required
Can be considered post-quantum secure: based on proven cryptography
Universal: suitable for general programs (this is the opposite of STARK)
secondary title
4.2 Zinc: Zero-Knowledge Smart Contract Framework
In the design of ZK Sync's programmable model, we are committed to achieving the following goals:
Highly scalable
Support public smart contracts and private smart contracts
The most important point: a flat learning curve and an easy development process
Many excellent projects have achieved several of these goals, but so far no project has been able to achieve all of the above goals. For example, ZkVM provides a virtual machine for general-purpose smart contracts, but is bulletproof-based and does not support succinct proof aggregation. ZEXE has an excellent privacy protection design, but it requires a deep understanding of the specific details and trade-offs of the zero-knowledge proof circuit, so the threshold for programmers is very high. Other simpler zero-knowledge proof programming frameworks lack the expressiveness and functionality necessary for secure smart contract development.
Therefore, we decided to create Zinc - a secure, simple and efficient programming framework and virtual machine-based runtime environment designed for zero-knowledge proof-based smart contracts.
SyncVM's design priorities are primarily security and developer friendliness. The programming language for defining contracts strictly follows the simplified Rust syntax and borrows smart contract programming elements from Solidity and Libra's Move. Developers do not need to have a deep understanding of the technical details of the zero-knowledge proof field to write efficient and secure programs. In fact, any developer with a background in programming languages such as Rust, Solidity, and C++ can understand Zinc in as little as a day.
The comparison between writing a part of the program in Rust for the Bellman framework (ZEXE uses a similar API) and writing the same program for Zinc is as follows:
Version 0.1 of Zinc will go live in January 2020.
Safe and expressive programming framework
A sandboxed virtual machine that generates zero-knowledge proofs in a delegated manner
first level title
ZK Sync 0.1 version of the developer network is online. This version is limited to ETH and ERC20 token transfers in a single operator environment.
Check out ZK Sync's SDK
Browse the code on Github
experience demo
Launching the developer network of version 0.1 is the first step to realize the vision of ZK Sync. Much research, experimentation and development work is still required in the future. Some parts of the design may change as we learn and incorporate feedback. But we guarantee that ZK Sync will introduce millions of users to the world of cryptocurrency, and this vision will not change. We set the bar high for user experience and will demonstrate that zero-knowledge proof technology can provide a web-like experience without sacrificing blockchain values.
text
