Introduction | ZK Sync: a key part of the popularity of Ethereum

summary

To successfully solve the scalability problem of the public chain, it is not just to improve transaction throughput. The so-called scalability is that the system must be able to meet the needs of millions of users without the cost of decentralization . The prerequisites for large-scale popularization of cryptocurrency are fast speed, low cost, smooth user experience, and privacy protection.

Without technological breakthroughs, existing scalability solutions had to make major compromises on one or more conditions. Fortunately, the latest advances in zero-knowledge proof technology have brought us more new solutions.

Today, our Matter Labs team is excited to announce ZK Sync 's vision: ZK Rollup's trust-free scalability and privacy solution designed to deliver a great user and developer experience. We are also proud to announce that the ZK Sync Developer Testing Network 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 stored in the underlying account and maintaining a high level of censorship resistance. Another important aspect of the protocol is the extremely low latency: transactions on ZK Sync are instantly economically deterministic .

• Read through the blockchain series: Key role in the blockchain world Token
• "Death sentence" on Telegram? Interpretation of the latest interview of the SEC "crypto old godmother"
• Perspective | How will Facebook Libra affect the banking industry?

We agree with the lean design philosophy and support the progressive advancement of the protocol, introducing each function one by one in order to enable each step to bring the most practical value to the user. That's why we start with the most basic part (security), first focusing on basic scalability (token transfer), then programmability (smart contract), and finally privacy.

ZK Sync features at a glance:

• Strictly equal to L1 security
• VISA level throughput
• Sub-second transaction confirmation speed
• Anti-censorship, anti-DoS attack
• Privacy-protected smart contract

The biggest challenge of blockchain expansion

In fact, the primary use of cryptocurrency is still speculation.

The value propositions of blockchain concepts such as Internet currency, DeFi, and Web 3.0 will not be realized to a large extent until they are not truly popular.

Scalability refers not only to transaction throughput, but also whether the blockchain system can meet the needs of millions of users.

Let's take a look at the three major challenges facing the blockchain revolution to the general public.

Challenge one: stay decentralized

In order to promote the blockchain in real life, the transaction volume of the currently most decentralized blockchain is still an order of magnitude worse. The Bitcoin network can process 7 transactions per second, and the Ethereum network can process 15 transactions per second-and VISA can process as many as 2000 transactions per second.

However, for Bitcoin and Ethereum, inefficiency is a feature, not a defect! By reducing the number of validators, you 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. Therefore, this brings strong resilience to the blockchain and fundamentally distinguishes it from existing financial institutions.

Another popular expansion plan is to require each validator to verify only a part of the relevant blockchain traffic, not all of the traffic. But this will inevitably introduce another trust hypothesis, and the game theory foundation on which the system is based will also become extremely fragile.

Challenge 2: Achieving privacy

Most people will not like to transfer a lot of wealth in the public eye. Residents in turbulent areas, such as Venezuela, are unlikely to be willing to pay with cryptocurrency if they immediately reveal how much money they have. If it is possible to reveal their true identity at the time of payment, it is impossible for people who produce or consume adult content (such as Xiaohuangshu) to use cryptocurrency instead of Paypal .

In addition, without on-chain confidentiality, privacy regulations such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act 2018 (CCPA) will prompt ordinary companies to shift from public chains to more centrality Payment and financial centers have turned our increasingly cashless society into a surveillance nightmare.

Privacy is a necessary condition for popularizing the blockchain.

However, it is difficult to achieve privacy on the public chain for the following reasons:

1. Privacy must be the default configuration of the protocol. To quote Vitalik Buterin, "If the anonymous set of the privacy model is actually small, it is actually very small. If the anonymous set of the privacy model is small, it is actually about no. Only globalized anonymous sets are true. Robust and reliable. "
2. To make covert transactions the default choice for everyone, the transaction costs of covert transactions must be very low, but, technically, covert transactions will inevitably bring high computational costs.
3. The privacy model must be programmable because real-world use cases are not limited to transfers: account recovery, multi-signature, spending limits, and so on.

Challenge 3: Achieving the expected user experience

The reality is cruel: Product managers are well aware that users always prefer a lighter, lighter experience that immediately brings satisfaction, but ignores the long tail risk . To entice users to switch from familiar things to new things, it takes a lot of power . For some, the value proposition of cryptocurrency (complete ownership, censorship resistance, and sound currency) is already attractive enough. But this part of the people are likely to have entered. If cryptocurrencies are to fulfill their original promises, they will need millions if they do n’t need billions of users.

To attract millions of mainstream users, we need to provide them with a user experience that meets or exceeds these expectations. We must provide new features while retaining all the convenience attributes of traditional Internet products that people are used to, that is, fast, simple, intuitive, and fault-tolerant.

ZK Sync's promise: trustless, confidential, and fast

This article will explain to you our architecture, design principles, and the good characteristics of our proposed protocol. Of course, the explanation process must explain the technology.

1. Security: rooted in ZK Rollup

ZK Sync is built on the concept of ZK Rollup.

In a nutshell, ZK Rollup is a two-tier expansion solution. All funds are stored in smart contracts on the main chain, and calculations and storage are performed off-chain. Every time a new Rollup block is created, a zero-knowledge proof (SNARK) of state transition is generated and submitted to the contract on the main chain for verification. This SNARK contains proof of the validity of all transactions in the Rollup block. In addition, the public data updates of each block will be posted to the main chain as cheap calldata.

This architecture provides the following guarantees:

1. Rollup validators can never destroy state or steal funds (unlike sidechains).
2. Even if the validator does not cooperate, the user can recover the funds on Rollup, because Rollup has data availability (unlike Plasma).
3. Thanks to the proof of validity, neither users nor trusted third parties need to prevent fraud by monitoring Rollup blocks online (unlike systems that use erroneous proofs, such as payment channels or optimistic rollups). Here's a good article (Editor's Note: For the Chinese translation, see the hyperlink "Validity Proof vs. Error Proof" at the end of the article), which delves into the overwhelming advantages of a valid proof over a false proof.

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 have decided to focus on the second-tier solution rather than trying to build our own underlying chain.

To better understand this concept, see our talk on ZCon1 and Dappcon , a podcast on Matter Labs at zeroknowledge.fm , and our earlier technical explanation post . Curious readers can also read this article (editor group: hyperlinks see "Optimistic vs ZK rollup" at the end of the article) 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. We have completely rewritten the architecture and ZK circuits since the first prototype was released. The latest version incorporates feedback we get from the community and implements various usability and performance improvements.

Summary: ZK Rollup

• Completely trustless
• Has the same security guarantee as the underlying chain (Ethereum)
• Certainty endorsed by Ethereum after first confirmation

2. Availability: Real-time trading

We expect that the latest developments in ZK certification technology will shorten the certification time and control the block production time of the ZK Rollup block to within one minute. Once the block certificate 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, in terms of retail and online payment, the block delay of just 15 seconds on Ethereum is also a little long. How can we do better?

This method is: Introduce instant tx receipts in ZK Sync.

Validators who choose to participate in ZK Sync block production must submit a considerable security deposit to the ZK Sync smart contract on the main network. The consensus reached by the verifier will provide users with sub-second confirmation to ensure that their transactions are included in the next ZK Sync block and signed by most (2/3) consensus participants (weighted by equity).

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 a committed transaction, the security deposit of the verifier who signed the original receipt and the new block will be forfeited. The deposit pledged by this part of the verifier must exceed more than 1/3 of the total amount. In other words, the punishment will cover 1/3 or more of the security deposit, and only the malicious verifier will be punished.

Part of the forfeited amount will be used to compensate the recipient of the transaction, and the rest will be destroyed.

The confiscation mechanism can be triggered either by the user himself or by any honest consensus participant who has signed the original transaction receipt. The latter are inherently motivated to trigger the confiscation mechanism: if they participate in the next round of block production, they may also be punished. Therefore, as long as one of the consensus participants is honest, it is sufficient to detect fraud.

Let's elaborate again: In ZK Sync, we designed a zero-confirmation transaction mode, that is, a transaction is accompanied by an instant transaction data, and the receipt will point to a ZK Sync block that has not been published on the chain.

Before the block certificate is released to the main chain, there are only a few minutes to launch a double-spend attack on zero confirmation transactions on ZK Sync. In addition, if a malicious verifier wants to persuade users to believe that their transaction has become a zero-confirmation transaction, they must make a 1/6 security reserve plan to be confiscated.

From the buyer's and seller's perspective, a zero-confirmation transaction is:

1. real-time
2. The possibility of reversal, but only in a few minutes
3. Reversible only if attacks are launched against thousands of sellers at the same time, not one by one

Compared with credit card payment, ZK Sync has greatly improved user experience and security!

Now let's look at it from the perspective of the different participants:

• Online stores that sell physical goods will immediately confirm the order with the user, but they will not be attacked because the seller will wait until the full confirmation before shipping.
• Physical stores are almost impossible to attack when the transaction volume is small. Even if you sell a Macbook in the form of an instant receipt, there are thousands of coordinated attackers launching attacks in different locations, and most contributors must conspiracy to succeed.

Speaking 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 by Nic Carter here) ). For example, after 35 transaction confirmations, Coinbase will receive an Ethereum funds deposit. If the 51% attack was launched by renting a GPU through Amazon cloud services, it takes 10 minutes to continue the attack to withdraw the transaction, which costs 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 better than Ethereum.

It should be noted that real-time transaction data will not be affected by the reorganization of ETH blocks, as the validity of these receipts is not related to Ethereum. In addition, Ethereum's settlement guarantee is combined with ZK Sync's settlement guarantee.

Summary: Real-time trading

• Economic certainty of sub-second transaction confirmation comparable to Ethereum
• Determinism endorsed by Ethereum in minutes

3. Active: Anti-censorship and anti-DoS attack

One of the attributes that the extended solution must have is that most users cannot participate in the verification of all transactions. Therefore, all Layer 2 extensions require a dedicated role (validator on Plasma and Rollup, Lightning hub, etc.). These roles have high requirements for security and performance, which brings the risk of centralization and auditing.

To solve this problem, ZK Sync was designed with two different roles: validator and guardian.

Validator

Validators are responsible for packaging transactions into blocks and generating zero-knowledge proofs for these blocks. They need to participate in the consensus mechanism, so they must pay a security deposit to create an instant transaction receipt. The verifier node must operate in a secure environment with good network bandwidth. Or, they may generate zero-knowledge proofs on insecure cloud platforms as they wish.

The validator will get the transaction fee as a reward, which is paid by the token being traded (providing the greatest convenience for the end user).

In order to reach the ZK Sync consensus quickly, the number of validators is limited (based on our analysis, it is more appropriate between 30 and 100 people). But don't forget, ZK Rollup validators are completely trustless. On ZK Sync, a malicious verifier can neither breach the security of the system nor trick the honest verifier to trigger a confiscation mechanism. Therefore, unlike optimistic rollup, the Guardian of the system can frequently change a small number of validators. At the same time, as long as two-thirds of the nominated verifiers are honest and operational, they can ensure that liveness is met.

Guardian

Most ZK Sync holders who nominate validators by pledged token shares will become guardians. The purpose of the guardian is to monitor peer-to-peer transaction traffic, detect censorship, and ensure that no validators are censored. In order to protect their pledges from being confiscated, the guardian must ensure that ZK Sync can resist DoS attacks and will not conduct censorship.

Although the voting keys are usually kept online, this does not pose a risk of forfeiture or theft to the guardians on ZK Sync (the ownership keys are stored cold). The guardian can choose to monitor only a small portion of the traffic. Therefore, the guardian node can run on an ordinary laptop or cloud server, that is, there is no need to provide a special validator service.

The Guardian will receive a fee from the validator as a reward, which is issued in the form of ZK Sync native tokens. Its earnings and deposits will be locked for a longer period of time to promote the long-term appreciation of ZK Sync tokens.

Summary: Activity

• Two roles: validator and guardian, both motivated by transaction fees
• Verifier runs consensus mechanism and generates proof
• Prevent censorship by guardians running on ordinary hardware

4.1 RedShift: Transparent Universal SNARK

The biggest obstacle to the realization of smart contracts based on zero-knowledge proofs (whether transparent or privacy-protected) is the lack of an efficient and universal ZK proof systems with recursive composition. . Groth16 was once the most efficient ZK SNARK, but it required a dedicated set of trusted initialization settings for each application, and it was inefficient when using recursion. On the other hand, FRI-based STARK requires highly specialized build skills and lacks efficient recursive combinations for any general-purpose circuit.

This is also one of our main motivations for developing RedShift : a transparent, efficient and concise new SNARK is derived from the FRI protocol-based polynomial commitment scheme. We are currently undergoing peer review and community feedback, and will later deploy RedShift as a core part on ZK Sync.

Redshift is a general-purpose SNARK that allows us to transform arbitrary programs into provable ZK circuits. Heterogeneous circuits (for example, different smart contracts) can be constructed recursively in an SNARK. RedShift relies only on collision-resistant hash functions, so it can be considered post-quantum safe.

Summary: Redshift

• Transparent: No need for trusted settings
• Can Be Considered Post-Quantum Security: Based on Proven Cryptography
• Universal: Suitable for general programs (as opposed to STARK)

4.2 Zinc: Zero Knowledge Smart Contract Framework

In the design of the programmable model of ZK Sync, we are committed to the following goals:

• Highly scalable
• Supports open smart contracts and private smart contracts
• The most important point: a gentle learning curve and a simple development process

Many excellent projects have achieved several of these goals, but none of them has achieved all of them. For example, ZkVM provides a virtual machine for general smart contracts, but it is based on bulletproof and does not support concise proof aggregation. ZEXE has an excellent privacy protection design, but requires in-depth understanding of the specific details and trade-offs of the zero-knowledge proof circuit, so the threshold is high for programmers. Other simpler zero-knowledge proof programming frameworks lack the features necessary for expressive and secure smart contract development.

Therefore, we decided to create Zinc, a secure, simple, and efficient programming framework and a virtual machine-based runtime environment, designed for smart contracts based on zero-knowledge proofs.

SyncVM's design priorities are primarily security and developer friendliness. The programming language that defines the contract strictly follows the simplified Rust syntax and borrows the programming elements of smart contracts from Solidity and Libra's Move. Developers do not need to have a deep understanding of the technical details in the field of zero-knowledge proofs to write efficient and secure programs. In fact, developers with programming languages ​​such as Rust, Solidity, and C ++ need only one day to understand Zinc.

The comparison between writing a part of the program for the Bellman framework with Rust (ZEXE uses a similar application interface) and writing the same program for Zinc is as follows:

Zinc version 0.1 will be available in January 2020.

Summary: Zinc

• Security and expressive programming framework
• Sandboxed virtual machine that generates zero-knowledge proofs in a delegated manner
• Focus on ease of development: Solidity programmers need only one day to learn

ZK Sync 0.1 version developer network is online!

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.

View ZK Sync's Software Development Kit

Browse the code on Github

Experience demo

Launching the 0.1 Developer Network is the first step towards realizing ZK Sync's vision. A lot of research, experimentation and development work will be needed in the future. As we understand and absorb feedback, some design parts may change. But we guarantee that ZK Sync will bring millions of users into the cryptocurrency world, and this vision will not change. We have set high standards for user experience and will prove that zero-knowledge proof technology can provide a web-like experience without sacrificing blockchain values.

You can follow Matter Labs' Twitter , public Telegram channel or subscribe to our occasional news feed .

If you want to contribute to the development of ZK Sync, please contact us. We are looking for good engineers and cryptographers to join our team.

Original link: https://medium.com/matter-labs/introducing-zk-sync-the-missing-link-to-mass-adoption-of-ethereum-14c9cea83f58 Author: Alex Gluchowski translation & proofreading: Min Min & A sword

We will continue to update Blocking; if you have any questions or suggestions, please contact us!