The capacity expansion plan of the public chain should consider the following dimensions:
High transaction throughput (Bitcoin at 7Tps, Ethereum at 15Tps, VISA at 2K + TPS)
Meet the needs of millions of users without sacrificing centrality
It has high speed, low cost, smooth user experience and privacy
Due to the lack of technical breakthroughs, the current expansion plan needs to compromise on one or more of the above dimensions. The emergence of zero-knowledge proof technology makes it possible to satisfy the above requirements simultaneously.
ZkSync solution provided by Matter Labs is:
trustless scaling and privacy solution for Ethereum based on ZK Rollup
The design objectives of zkSync are:
VISA 2K + TPS level transaction throughput for Ethereum
Ensure the security of funds, and the security level is equal to L1 security at the bottom
Achieve a high degree of Censoring -resistance
With ultra-low latency, transactions in zkSync can achieve instant economic finality
ZkSync adopts the progressive design concept to gradually realize the following contents:
Infrastructure Layer (Security)
Basic extended functionality layer (tradability)
Smart Contract layer (programmability, such as account recovery, multiple signatures, cost limits, etc.)
Privacy Layer (Privacy)
Among them, programmability and privacy are the most difficult part of zkSync, which requires an appropriate zero-knowledge proof system and smart Contract programming framework, and corresponding reliable design and implementation.
The main features of zkSync are:
trustless
confidential
fast
ZkSync code implementation see:
https://github.com/matter-labs/zksync
2. Security of zkSync -- ZKRollup
The security of zkSync depends on ZKRollup.
ZkRollup is L2 expansion solution:
All funds are controlled by smart contracts on the main network.
Computation and storage are carried out down the chain.
For each Rollup block, a zero-knowledge proof of state transition is generated, which contains the validity proof of each single transaction. The smart contract on the main network can verify the proof.
Public data updates in each block are sent to the main network as cheap calldata.
The above mechanisms provide the following protection:
Rollup Validator (s) can neither corrupt the state nor steal funds. (Superior to SideChains)
Even if validators(s) are out of service, users can still get their money back from Rollup because the data is available. (Better than Plasma)
With the validity proofs, there is no need for the user or any trusted third party to stay online to supervise the Rollup blocks to prevent fraud. (better than Fraud-proof systems such as Payment channels or optimistic Rollups). The advantages of Validity proof over Fraud proof are detailed in the blog Validity Proofs vs. Fraud Proofs Strike Back.
In other words, ZK Rollup strictly inherits the security guarantee of the underlying L1. This, along with the richness of the Ethereum community and existing infrastructure, was the deciding factor in our decision to focus on L2 solutions rather than trying to build our own L1.
Copyright notice: This article is originally published BY CSDN blogger "Mutourend" under CC 4.0 BY-SA copyright agreement. Please attach the link of the original source and this statement.
- Availability of zkSync -- Real-time transactions
Hope:
The time to generate proof for zkRoll block is controlled within 1 minute.
Once a block proof is submitted to the main network and verified by the Rollup Smart contract, all proofs in the block are protected by King Of France and L1 Reorg-resistance.
And in retail and online payments, even Ethereum's 15-second block latency may be too long. How can we do better?
This introduced Instant Tx Receipts in zkSync.
Validators participating in the generation of zkSync block elections are required to submit an adequate security deposit to the zkSync smart contract on the main network.
The agreement between validators to provide subsecond Confirmation to the user will be included in the next zkSync block and will be signed by a majority (2/3) of the (equity-weighted) consensus participants.
Reverted cannot be withdrawn when a new zkSync block is created and submitted to the main network. If the block does not contain a promised transaction, The safety deposit of "the intersection of the Signers of the Original receipt and the Signers of the new blocks" will be significantly reduced. This intersection requires a margin of no less than one-third of the stake, ensuring that at least one-third of the margin is deductible and that only malicious users are punished.
Part of the reduced fund can be used to compensate the TX Recipient, and the rest will be burned.
The cut action can be triggered by the user himself or by any honest participant in the consensus who signed the original TX Receipt. For the latter, they have an incentive to report fraud, since they will also have their margin cut if they participate in subsequent block generation. Therefore, having at least one honest participant in the consensus is sufficient for fraud detection.
A transaction with instant Receipt in the zkSync block is called:
zero-confirmation tx
The time window for double-spending on zero-Confirmation TX is very short, only a few minutes. After the block proof is sent to the main network, there is no longer double-spending problem.
And unless the zero-confiramtion TX value exceeds 1/6 of its security margin, malicious Validators have an incentive to trick users.
From the perspective of both buyer and seller, zero-Confirmation TX has the following features:
Instant
Potentially reversible, but only within a few minutes
Reversible only if thousands of sellers were attacked simultaneously; a one-to-one attack could not be reversible.
Compared with credit card payment, zkSync has made significant improvements in user experience and security, mainly reflected in:
Online stores with physical goods: May confirm purchases to users immediately, but will not be attacked because they will wait for full confirmation before shipping.
Brick-and-mortar stores: Almost immune to attack when processing small transactions. Even selling a Macbook to Instant Tx Receipt will cost you money unless a coordinated physical attacker in a synchronized location is in cajas with most Validators.
In order to quantify the risk, compare the economic guarantee provided by the margin with the Settlement Assurance provided by POW, see the blog It's the Settlement Assurance, Stupid.
For example, Coinbase requires 35 TX confirmations to finalize a deposit on Ethereum. The cost of revoking the deal is about $60,000 to rent a GPU from AWS for a continuous 51% attack for 10 minutes. Given that there are millions of dollars in security deposits, it would be more expensive to revert an Instant zkSync Receipt. Therefore, Instant Receipts usually prefer schemes like ETH, which have better economic finality attributes.
Note that Instant Tx Receipts also prevent ETH block Reorgs because their validity is independent of Ethereum. In addition, Ethereum's settlement guarantee is combined with zkSync's settlement guarantee.
Availability of zkSync -- The key features of real-time transactions are:
Compared with Ethereum, it has subsecond TX confirmations with economic finality.
Hard Ethereum-backed Finality after a few minutes.
4. ZkSync liVENESS -- Anti-Cencorship and anti-DOS
An inescapable feature of any expansion scheme is:
Most users cannot participate in verifying all transactions
This leads to the introduction of specific roles in L2 storage solutions (such as validators in Plasma or Rollup, hubs in Lightning, etc.). While these new roles bring security and performance improvements, they also carry the risk of centralization and censorship.
To this end, zkSync has two different roles:
Validators
Guardians
The main features of zkSync liVENESS are:
There are Validators and Guardians, both motivated by TX Fees
Validators run the consensus and generate the proofs
Guardians monitor Cencorship with Ordinary Hardware
4.1 Validators in zkSync
Validators are responsible for:
Package transactions to blocks
Generate zero-knowledge proofs for transactions in blocks
Participate in consensus and a portion of security margin must be provided for Instant Tx Receipts
Its nodes must run in a secure environment and have good network bandwidth
Optional ZK proofs generation on insecure clouds as needed
Get incentives for transaction fees, which are paid in any token during the transaction (maximum convenience for the end user)
To maintain the speed of zkSync consensus, only a limited number of Validators (between 30 and 100, depending on profiling) are allowed at any one time.
Note that zkRollup Validators are complettely trustless, and malicious validators neither compromise system security nor trick honest Validators into being penalized.
However, unlike Optimistic rollup, Guardians can rotate a small number of Validators frequently and keep consensus active as long as more than two-thirds of nominated Validators are honest and Operational.
Guardians in 4.2 zkSync
Guardians include the majority of zkSync token holders who can nominate Validators by pledging their tokens.
The main purpose of Guardians is to:
Monitor P2P transaction traffic
Discover censorship behavior
Ensure that validators found in the review are not nominated.
Guardians' primary motivation is to protect the value of its pledge token by ensuring that zkSync is Dos and censor resistant.
By keeping voting keys online, the Guardians are never at risk of being cut or stolen, and their Ownership keys can be stored in cold media.
Guardians can also choose to monitor only a small portion of the traffic, so its nodes can run on regular laptops or cloud servers, i.e., no specialized Validator services are required.
Guardians receive fee incentives from nominated Validators, which are paid in the form of zkSync Native tokens. Its earnings and pledge will be locked in for the long term to incentivise long-term zkSync token value rather than short-term return.
- ZkSync programmability -- RedShift (Transparent Universal SNARK)
The biggest obstacle to implementing ZK-based Smart contracts (whether transparent or privacy-preserving) is:
Lack of efficient Generic ZK Proof Systems with recursive Composition
Groth16, as the most efficient ZKNARK at present:
Application-specific Trusted setup is required
If recursion is implemented, its efficiency will be greatly reduced
And FRI - -based STARKs:
Highly specialized skills are required to build it
Lack of efficient recursive composition of arbitrary Generic circuits.
To this end, proposed RedShift:
Transparent, no need for Trusted setup
Efficient and fully succinct SNARK based on the FRI-based Iteration Scheme
For universal SNARK, can convert any program to provable ZK circuits. (Better than STARKs)
Heterogenous circuits (e.g., different smart contracts) can be composed in one SNARK recursively.
Battle-teste Cryptography based, independent of collison-Restant hash functions, has post-Quantum secure with facts rather than facts.
RedShift will form the core of zkSync.
- ZkSync programmable -- Zinc (Framework for Zero-knowledge Smart Contracts)
The zkSync programmability model was designed with the following goals in mind:
High scalability
Both public smart contracts and private smart contracts are supported
Most important: smooth learning curve and ease of deployment
The current framework of zero-knowledge smart contract is as follows:
ZkVM: Provides virtual machines for Generic Confidential Smart Contracts, but it is bulletproof based and does not support succinct proof aggregation.
ZEXE has excellent privacy design, but requires an in-depth understanding of zero ciruit specifics and trade-offs.
So Zinc was designed:
Safe, Simple and efficient Programming Framework
Vm-based Runtime environment Sandboxed VM for the delegated Generation of zero-knowledge proofs
Specially designed for ZKP-based Smart Contracts
Zinc's key design is to:
security
Developer friendly
For this purpose, Rust-like syntax is used in Zinc to define smart contracts, drawing on smar-Contract Programming elements from Solidity and Libra's Move.
Zinc does not require any knowledge of the ZKP domain to write efficient and secure programs.
For developers with a background in Rust, Solidity, C++ or similar development, Zinc can be mastered in 1 day.
The following is a comparison of the Implementation of the Bellman Framework written by Rust versus Zinc:
Copyright notice: This article is originally published BY CSDN blogger "Mutourend" under CC 4.0 BY-SA copyright agreement. Please attach the link of the original source and this statement.
The original link: https://blog.csdn.net/mutourend/article/details/116245021