The bridge for millions of users to enter the world of cryptocurrencies: an article to understand the Ethereum expansion solution ZK Sync

Written in front: This article was published by Matter Labs. The company has received funding from the Ethereum Foundation and has made some progress in terms of capacity expansion programs. It proposes a layer 2 solution in the article, which can meet the needs of millions of users without sacrificing decentralization, while ensuring privacy, and bringing a smooth user experience.

The following is the full content of the article:

A successful solution to the problem of public blockchain expansion is not only related to transaction throughput, it must also be achieved, the system can meet the needs of millions of users without sacrificing decentralization. The prerequisites for the full popularity of cryptocurrencies include high speed, low cost, smooth user experience and privacy.

• The demand for cryptocurrencies may skyrocket! What else does Deutsche Bank report "Imagine 2030" imply?
• The "Bitcoin Giant Whale" gray company continues to move in 2019, indicating that there may be great changes in 2020?
• Perspectives | Stateless Clients: New Trends in Ethereum 1.x

In the absence of technological breakthroughs, existing capacity expansion solutions have had to make major compromises on one or more of the above requirements. Fortunately, recent advances in zero-knowledge proofs have opened up entirely new possibilities for solving this problem.

Today, Matter Labs is pleased to show you our vision for ZK Sync: ZK Rollup-based Ethereum de-trusted capacity expansion and privacy solutions, emphasizing the superior experience for users and developers. We are also proud to announce the launch of devnet (Developer Network) for ZK Sync.

ZK Sync aims to bring Ethereum a Visa-level throughput of thousands of transactions per second, while ensuring that funds are as secure as a layer 1 account 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 financial finality.

We agree with the idea of ​​simplifying the design, and tend to evolve the protocol step by step, introducing features one by one, and bringing the most tangible value to users at each step. That's why we start with the basics (security), and first focus on basic scalability (token transfer), then programmability (smart contracts), and finally privacy.

(ZK Sync function list)

The most difficult problem of blockchain expansion

Today, in reality, cryptocurrencies are still used primarily for speculation. The value proposition of the magical Internet currency, DeFi, Web 3.0, and all other promising blockchain innovations will be almost impossible to achieve without mass realisation.

Scalability is not only about transaction throughput, but also the overall readiness of the blockchain system to meet the needs of millions of users.

Let's take a look at the three most difficult issues of popularizing the blockchain revolution to the masses.

Challenge 1: stay decentralized

The transaction throughput required for real-world popularity is an order of magnitude higher than today's most decentralized blockchains. Bitcoin's TPS (number of transactions processed per second) is 7, Ethereum is 15, and Visa is 2000.

But the slow speed of Bitcoin and Ethereum is a feature, not a flaw! It is possible to increase speed by reducing the number of validators. The large number of full nodes in these two leading blockchain networks is their most important asset. This provides the resilience of the network, which is actually the essential difference between them and existing financial institutions.

Another universal scalability method is to require each validator to check only part of the relevant blockchain traffic, not all. But this inevitably introduces additional trust assumptions and places such systems on the basis of highly unreliable game theory.

Challenge 2: Implementing privacy

Most people are reluctant to put most of their property in a clear glass box. Residents in dangerous areas (such as Venezuela) are unlikely to pay in cryptocurrencies, otherwise the recipient will know immediately how much they have. If these payments are likely to be associated with the user's real identity, then it is unlikely that people will use cryptocurrencies as an alternative to Paypal.

In addition, in the absence of on-chain confidentiality, privacy regulations such as GDPR (General Data Protection Regulation) and CCPA (California Consumer Privacy Act) will drive ordinary enterprises away from public blockchains and move to more centralized payment and Financial centers have turned 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 the following factors:

1. As a full protocol feature, privacy must be turned on by default. To quote Vitalik Buterin: "If your privacy model has a medium anonymous set, it actually has a small anonymous set. If your privacy model has a small anonymous set, the number of anonymous sets is actually only 1. Only globally Anonymous collections are truly secure. "

2. In order to achieve default privacy, the cost of privacy transactions must be very low, albeit with significant computational expenses.

3. The privacy model must support programmability, because real-world applications require more than just transfers: account recovery, multi-signature, spending restrictions, and more.

Challenge 3: Meet user experience expectations

The reality is cruel: Product managers know that users often prefer a simpler, more lightweight experience, instant gratification, and often ignore the long tail risk. It takes a lot of determination to switch from something familiar to something new. For some, the value proposition of cryptocurrencies (complete self-ownership, anti-censorship, sound currency) is sufficient. But these people may already be on board. We need at least millions, if not billions, to reach the scale needed for cryptocurrencies to fulfill their promises.

To attract millions of mainstream users, we need to provide them with a user experience that not only meets these expectations, but also exceeds them. We must offer all new possibilities while maintaining all the convenience attributes of traditional Web products that people have become accustomed to. Everything must be fast, simple, intuitive, and fault-tolerant.

ZK Sync's promise: detrust, confidentiality, and speed

In this technical article, we will explore the advanced architecture, design choices, and attributes of ZK Sync.

1. Security: Rooted in ZK Rollup

ZK Sync is built on the concept of ZK Rollup.

In short, ZK Rollup is a layer 2 expansion solution, in which all funds are held by smart contracts on the main chain, while calculation and storage are performed off-chain. Each Rollup block will generate a state transition zero knowledge certificate (SNARK) and verify it through the main chain contract. This SNARK contains proof of the validity of each transaction in the Rollup block. In addition, the public data updates for each block are published on the main chain network as low-cost calldata.

This architecture provides the following guarantees:

• Rollup validators will never destroy state or steal funds (unlike sidechains).
• Users can always retrieve funds from Rollup, even if validators stop collaborating because data is available (unlike Plasma).
• With the proof of effectiveness, in order to prevent fraud (unlike fraud prevention systems such as payment channels or optimistic rollups), users or a single trusted third party do not need to monitor Rollup blocks online.

In other words, ZK Rollup strictly inherits the security guarantee of the underlying layer 1. This, coupled with Ethereum's rich community and existing infrastructure, was a decisive factor in our decision to focus on layer 2 solutions rather than trying to build our own layer 1.

With funding from the Ethereum Foundation, Matter Labs has been working on ZK Rollup technology for the past year. We have completely rewritten this architecture and the first prototype of the ZK circuit since its introduction. The latest version integrates feedback we have received from the community and implements various usability and performance improvements.

(Summary: Features of ZK Rollup)

2. Availability: Real-time trading

We look forward to the current development of ZK verification technology in order to reach the proof time and allow ZK Rollup blocks to be produced in one minute. Once a block certificate is submitted to the main chain and verified by the Rollup smart contract, all transactions in that block will be completed, and will now receive a layer 1 anti-restructuring guarantee.

But in the retail and online payment space, even Ethereum's 15-second block delay can be too long. How can we do better?

This can be done: In ZK Sync, we introduced instant transaction receipts.

Validators selected to participate in the ZK Sync block output must sign an important security agreement with the ZK Sync smart contract on the mainnet. Verifiers run to provide users with a sub-second confirmation that their transactions will be included in the next ZK Sync block, signed by an absolute majority of two-thirds of the consensus participants (as measured by stake).

If a new ZK Sync block is generated and submitted to the main chain, it cannot be recovered. However, if it does not contain a committed transaction, the security guarantee intersection of the signer of the original receipt and the signer of the new block will be cut. This intersection is guaranteed to hold more than one-third of the stake. This guarantees that at least a third of the security guarantees can be cut and only malicious users will be punished.

Part of the reduced funds will be used to compensate the recipient of the transaction. The rest will be burned.

Reductions can be triggered by users themselves or by honest participants who signed the original transaction receipt. The latter will have a natural incentive to uncover fraud: if they participate in subsequent block productions, they may also experience significant cuts. Therefore, at least one honest participant in the consensus is sufficient to detect fraud.

Let's check the characteristics of this protocol. We refer to the zero-confirmation transaction as a transaction with an instant receipt of the ZK Sync block, which has not yet been published to Ethereum.

Double spend zero confirmation transactions on ZK Sync can only be utilized in a short time (a few minutes) until the block certification is released on the main chain. In addition, malicious validators will trick users into accepting zero-confirmation transactions worth more than one-sixth of the security guarantee.

From the perspective of buyers and merchants, zero-confirmation transactions are:

• real-time
• Reversible, but only in minutes
• Reversible only when attacking thousands of merchants at the same time, not one after the other.

This is a huge user experience and security improvement compared to credit card payments! Let's look at it from a different perspective:

Online stores that own physical products may immediately confirm purchases with users, but they will not be attacked because they will wait for full confirmation before shipping. Brick-and-mortar stores are hardly attacked when processing small transactions. Even if you sell your Macbook based on instant transaction receipts, you need thousands of coordinated physical attackers in different locations and most validators to make you lose.

Let's dig a little deeper. In order to quantify the risk, the economic guarantee provided by the guarantee can be compared with the settlement guarantee provided by the PoW blockchain. For example, Coinbase requires confirmation of 35 transactions before considering the finality of Ethereum transactions. The cost of renting a GPU from AWS (Amazon Web Services) for a 10-minute 51% attack to withdraw this transaction is approximately $ 60,000. Assuming millions of dollars in security guarantees, the cost of withdrawing an instant ZK Sync receipt is even greater. As a result, instant receipts often have properties similar to Ethereum, and even have better economic finality.

Importantly, instant transaction receipts also prevent Ethereum block restructuring, as their validity is independent of Ethereum's existence. In addition, Ethereum's settlement guarantee and ZK Sync's settlement guarantee can be combined with each other.

(Summary: Real-time trading)

3. Activity: anti-censorship and anti-DoS

An inevitable feature of all expansion plans is that most users cannot participate in all transaction verifications. This leads to the need to set up special roles in all layer 2 expansion schemes (validators in Plasma or Rollups, Hubs of Lightning Network, etc.). Security and performance improvements in these roles pose the risk of centralization and review.

The design of ZK Sync solves this problem and introduces two different roles in the long run: Validators and Guardians.

Validator

Validators are responsible for packaging transactions into blocks and generating zero-knowledge proofs for them. They participate in consensus and therefore must contribute a portion of the security guarantee to the instant transaction receipt. Their nodes must operate in a secure environment with good Internet bandwidth. Alternatively, they can choose to generate ZK proofs in an unsecured cloud.

The validator will get a transaction fee, which can be paid with any token that is being traded (maximum convenience for the end user).

To maintain the consensus speed of ZK Sync, only a limited number of validators are allowed at any time (between 30 and 100, depending on the situation). However, recall that ZK Rollup validators are completely de-trusted. In ZK Sync, a malicious verifier can neither endanger the security of the system nor trick the honest verifier to break the conditions. Therefore, unlike optimistic rollups, validators can be rotated frequently by guardians. At the same time, as long as more than two-thirds of the nominated validators are honest and operational, the liveliness of the consensus can be guaranteed.

protector

The guardians are mostly ZK Sync token holders. They select validators by pledged tokens. The goal of the Guardian is to monitor peer-to-peer transaction traffic, detect censorship, and ensure that validators found to be censored are not nominated. The motive of the guardians is to protect their stake value by ensuring that ZK Sync remains anti-censorship and anti-DoS.

Although ZK Sync keeps the voting keys online, the guardian will never face the risk of assets being cut or stolen (ownership keys can be kept in cold storage). They may also monitor only a portion of the traffic. Therefore, their nodes can run on ordinary laptops or cloud servers, which means that no special validator service is required.

Guardians receive fee rewards from validators in the form of ZK Sync tokens. Their earnings and stakes will be locked for a long time to motivate them to prioritize the long-term value of the ZK Sync token over short-term returns.

(Summary: Active)

4. Programmability and privacy: building blocks

Achieving efficient programmability and privacy is the most difficult part of ZK Sync's vision. It requires reliable design and deployment of appropriate zero-knowledge proof systems and smart contract programming frameworks.

RedShift: transparent universal SNARK

The biggest obstacle to implementing ZK-based smart contracts (whether transparent or privacy-protected) is the lack of an effective universal ZK proof system with recursive combinations. Groth16 was the most efficient ZK SNARK at the time. It required dedicated trusted settings, which may affect efficiency when applying recursion. On the other hand, FRI-based STARKs require highly specialized skills to build arbitrary universal circuits and lack effective recursive combinations.

This is one of the main motivations for our research on RedShift: a new transparent, efficient and concise SNARK derived from our FRI-based polynomial commitment scheme. We are currently conducting peer review and community feedback at the same time, and will then deploy RedShift as a core part of ZK Sync.

RedShift is a general-purpose SNARK that allows us to use it to easily convert arbitrary programs into provable ZK circuits. Heterogeneous circuits (such as different smart contracts) can be recursively formed in a SNARK. RedShift seems to be quantum-resistant because it only relies on collision-resistant hash functions.

(Summary: Redshift)

Zinc: Zero Knowledge Smart Contract Framework

In the design of the programmability model of ZK Sync, we are committed to the combination of several orthogonal targets:

• High scalability
• Support for public and private smart contracts
• Most importantly: it's easy to use

The above characteristics are the goals of many excellent projects, but no one project promises all of them at the same time. For example, ZkVM provides a virtual machine for general secret smart contracts, but it is based on bulletproofs and does not support concise proof aggregation. ZEXE has an excellent privacy protection design, but it requires in-depth understanding of the details and trade-offs of zero-knowledge circuits, which has caused the barrier to entry to be too high. Other simpler ZK programming frameworks lack the features needed for secure smart contract development.

This is why we decided to create Zinc: a secure, simple, and efficient programming framework and a virtual machine-based runtime environment, specifically designed for ZKP-based smart contracts.

The design focus of SyncVM is security and developer friendly. The programming language used to define the contract strictly follows the simplified Rust syntax, and the smart contract programming elements borrow from Solidity and Libra's MOVE. It does not require developers to understand the details of ZKP to write efficient and secure programs. In fact, developers with a background in Rust, Solidity, C ++, or similar programming languages ​​can learn Zinc in one day.

Zinc v0.1 will be released in January 2020.

(Summary: Zinc)

ZK Sync v0.1 developer network is online

ZK Sync v0.1 Developer Network is online. The scope of this release is limited to Ethereum and ERC20 token transfers in a single operator setting. ( ZK Sync SDK )

The release of Developer Network v0.1 is the first step to implementing ZK Sync functionality. This requires a lot of research, experimentation and development work. Some design aspects may change as we learn and feedback. But we promise that this vision will not change: ZK Sync will be a bridge for millions of users to enter the cryptocurrency world. We set a high standard for user experience and will prove that ZK technology can provide a web-like experience without sacrificing the value of the blockchain revolution.

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