1 Introduction
1.1 Scalability issues
You may already know the history of the blockchain (but I’m still talking nonsense). In 2017, Bitcoin began to make headlines in mainstream media , arousing unprecedented attention, and people all over the world have seen the challenges faced by this technology. With the increasing popularity of Bitcoin, Bitcoin transactions have also occurred in large numbers, and network congestion has reached an unprecedented level. The skyrocketing transaction fees have made Bitcoin transfers unrealistic. Recently, Ethereum has also revealed the same problem. Compared to the low peak period, the gas fee on Ethereum has increased by 30 to 50 times.
All these phenomena reflect the problem that the entire community has long known: the initial design of the Bitcoin blockchain is not suitable for mass popularization. Since Bitcoin’s maximum transaction processing volume per second is only a few, it is far inferior to mainstream payment networks such as Visa or PayPal. We usually call this limitation a blockchain scalability problem .
The purpose of Ethereum is to confirm transactions faster than Bitcoin, but it is far from enough to solve this problem. The transaction throughput of Ethereum-higher than Bitcoin, but only a few dozen transactions per second-is not enough for the network to achieve mass adoption. Ethereum will also experience congestion, and even simple smart contract operations will cost several dollars.
Side note: the actual throughput of the blockchain
In view of Bitcoin’s design, its transaction throughput is theoretically only 7 transactions per second . In fact, due to issues such as empty blocks and complex input and output transactions, the throughput averages only 3 transactions per second. When the Bitcoin network updated the Segregated Witness protocol through a soft fork in 2017, the throughput increased to 4.6 transactions, which is still not even 7 transactions per second.
Similarly, Ethereum’s design transaction throughput is 15 transactions per second . However, this limit is dynamically changing (depending on the block Gas Limit set by the miner). Assuming that the current network sets the gas upper limit of a block to 12 million, the actual throughput will reach more than 36 transactions per second. However, this inference is only suitable for the case where there are only Ether transfer transactions in the block, because the cost of token transfer is 2.5 times higher, not to mention more complex interactions with smart contracts-the cost is usually high many.
In the blockchain industry, many scalability projects have failed miserably . Some projects just stay at the stage of white paper, or slash their feet and distort the connotation of blockchain to defraud attention. We have reason to believe that there is no final solution to the scalability problem, and new solutions will always increase complexity and difficulty.
Even if we accept this fact, the progress in the field of scalable solutions over the past few years is still frustrating. However, the end of darkness is light, and we are about to usher in a turning point .
Earlier this year, when a client asked us to investigate the market for scalability solutions, we seemed to hear the clarion call of a revolution. Recently, several promising teams have announced project milestones. The Ethereum community is eager to try again.
We know that too much information may be misleading and make it difficult to grasp the whole picture, so we decided to help everyone sort it out. Through this article, we want to share the results of our scalability research with blockchain developers and the entire blockchain community. We believe that this article will help you understand the potential of zero-knowledge proofs and two-tier scalability solutions, as well as a deeper understanding of these technologies.
1.2 Report content
Compared with the past, the market for scalable solutions has developed, and countless companies dedicated to the development of such solutions have their own hands. Faced with such a large number of solutions, it is easy for us to feel lost and it is difficult to discern which solutions are the most promising.
Therefore, we decided to carefully analyze and compare these solutions, find out those with the most potential, and help entrepreneurs and developers make the right choices. We mainly focus on the two-tier schemes based on zero-knowledge proofs , because we found that these schemes have high security and relatively short capital withdrawal time, so they have the greatest potential from a long-term perspective.
There are at least two types of promising solutions not covered in this article: optimistic rollup and state channels. These two types of schemes are not constructed based on zero-knowledge proofs, so they are beyond the scope of this article.
Side note: What is a two-tier solution?
The goal of the second-tier scalability solution is to add additional protocols to the existing blockchain , increase the maximum throughput of Ethereum (that is, the speed of processing transactions) and reduce the transaction fees that end users need to pay. Different from the one-layer scheme such as ETH 2.0, the two-layer scheme uses the basic protocol as a decentralized security layer, and then builds another layer on it (without changing the Ethereum consensus algorithm or any other core concepts).
The second-tier solution transfers the calculations originally performed by Ethereum to off-chain , using Ethereum as a security guarantee. As calculations are moved off-chain, the amount of data that needs to be stored on the chain is greatly reduced, which speeds up transactions while reducing transaction costs.
2. Zero knowledge proof
2.1 Introduction
The solution detailed in this article uses zero-knowledge proof cryptography to ensure transaction security and enable off-chain computing. Therefore, before delving into scalability solutions, we need to have a basic understanding of zero-knowledge proof technology.
Zero-knowledge proof (ZK for short) is a branch of cryptography and one of the hot spots pursued by the blockchain community in recent years. Through zero-knowledge proof, one party (the prover) can prove to the other party (the verifier) that he has some knowledge, but there is no need to disclose the knowledge itself and other information that can be used to crack the knowledge. The only information that the prover needs to convey and prove to the verifier is that he does possess this knowledge.
It doesn’t matter if you don’t understand. Let’s take a simple zero-knowledge proof example:
2.2 Examples in real life
Regarding how zero-knowledge proof works, Konstantinos Chalkias gave a brilliant example. Suppose there are two good friends Victor and Peggy, they both like to juggle in the park on weekends. Victor is a patient with red-green blindness. To him, these balls are all the same color.
The two decided to go to Central Park (Central Park) to juggle balls as usual. Peggy brought a red ball and a green ball. Victor, a red-green blindness patient, cannot see the difference between the two balls.
In order to prove to Victor the difference between the two balls, Peggy asked Victor to hold a ball in one hand and hide behind him, and then repeatedly exchanged the balls in his hands. After each exchange, Victor will show Peggy any ball and ask her if it is different from the last one.
Whenever Victor exchanges the ball, Peggy can tell whether the ball he showed is different from the last time, because she can distinguish red and green. In this way, Victor can be sure that Peggy knows the difference between the two balls, and he can’t know the colors of the two balls. This is the zero-knowledge proof.
Although Peggy has a 50% probability of guessing once or twice, the more they repeat, the probability of guessing will infinitely approach zero. Therefore, Victor can be absolutely sure that the colors of the two balls are different.
2.3 Zero-knowledge proof and blockchain
Zero-knowledge proof can be used to generate a password on a calculation has been performed in accordance with predetermined rules of science to prove . This type of proof can be generated by a compiled computer program and can be verified automatically.
The reason why zero-knowledge proof helps to solve the scalability problem is that zero-knowledge proof itself is much smaller than the data it represents , and zero-knowledge proof can be used to anonymize transactions.
(Anbi Press: Not all zero-knowledge proof technologies generate proofs that are much smaller than statements. Zero-knowledge proof technologies must meet only three requirements: completeness, soundness, and zero-knowledge. knowledgeness), it is not required to have this small size.)
Side note: The scalability solution based on zero-knowledge proof does not fundamentally change the scalability of the blockchain, but only changes the usage of the blockchain : all small calculations are transferred from the chain to the off-chain execution, and the blockchain only A large number of calculation results need to be verified.
The zero-knowledge proof generated by the two-layer expansion scheme first needs to comply with a set of predefined rules . If it is a transaction system, this set of rules may be similar to the consensus rules of the blockchain, for example, each transaction must be signed with the correct signature, or users must not overdraw. The two-tier system transforms the rules into a series of mathematical expressions (circuits and polynomials), and then uses these mathematical expressions to create two computer programs necessary for the zero-knowledge proof generation process: the prover and the verifier .
As long as we have a prover and a verifier, we can use the system to generate and verify transactions. Suppose Alice has 3 ETH in her wallet and she wants to transfer an account to Bob. She signs the transaction, and the transaction data is submitted to the certifier. The prover uses the data to generate a zero-knowledge proof, which is then sent to the verifier. Now let us consider the following two scenarios.
2.3.1 Generate a valid zero-knowledge proof
The verifier can verify whether Alice performed the transaction according to the predefined rules without knowing the transaction information. One of the rules is that Alice cannot overdraft, so if she wants to transfer 2 ETH, the verifier will approve the transaction.
2.3.2 Generate a false zero-knowledge proof
Now, suppose Alice wants to send 5 ETH. It stands to reason that the transaction will be rejected at the prover stage. Even if the prover did evil, the transaction would not be permitted and could not pass the verification of the verifier because it was not executed in accordance with the regulations.
(Ambient: Readers should be aware that chapters 2.3.1 and 2.3.2 are the “completeness” and “reliability” in the attributes of zero-knowledge proofs: correct proofs must pass verification; wrong proofs must not pass Verification. The “zero-knowledge” of zero-knowledge proof is not used here. Therefore, if privacy requirements are not required, but only to improve scalability, then anything that satisfies completeness, reliability, and simplicity (the proof is small) The proof system with fast verification speed can actually be used for the same purpose. Therefore, Vitalik once proposed to ” replace the ZK prefix of ZK rollup with snarks “, or more detailed naming such as “Validium” , because these solutions are actually None of the above uses zero-knowledge attributes. StakWare, including StakWare, has been emphasizing that it is using the proof system to achieve computational integrity proof. But in the case of “ZK rollup” deeply rooted in the hearts of the people, AZTEC uses zero The rollup scheme of knowledge proof (providing privacy) had to be named ” ZK-ZK-rollup “. It is embarrassing)
2.4 SNARK vs. STARK
So far, there have been many cryptographic proofs based on zero-knowledge proofs. The most well-known ones are SNARK and STARK. There is a very important connection between them.
SNARK stands for :
- Conciseness ( s uccinct): The proof is much smaller than the data it represents and can be verified quickly.
- Non-interactive ( n on-interactive): The prover will only send a set of information to the verifier, so there is no need to interact back and forth between the two.
- Knowledge argument ( A rgument of k nowledge): From the calculated level, we believe that the proof is complete – malicious prover can not cheat the system, unless TA really understand the specific content of the knowledge, in order to prove TA support proposed.
(Ambient: In cryptography, there is a distinction between proof (proof scheme) and authentication (argument scheme). The soundness of the scheme must be able to resist the prover with infinite computing resources before it can be called proof; and argument It only needs to be able to resist the malicious prover whose computing power is polynomial, and does not need to resist the malicious prover with infinite computing power.)
The SNARK used in the scalability solution requires a trusted setup between the prover and the verifier . Trusted initialization is a set of initial public parameters similar to game rules, which are generated by a group of volunteer participants performing joint calculations at a specified time, that is, the so-called trusted setup ceremony. As long as at least one participant is honest, the parameters can be generated safely. Therefore, the greater the number of participants, the higher the credibility of the mechanism.
STARK (such as FRI-AIR STARK developed by StarkWare) does not require trusted initialization-therefore, the “T” here stands for “transparent”. This eliminates the hidden danger of a single point of failure for the entire system. Although the amount of data proved by STARK is relatively large, the calculation cost can be shared equally for large batches of transactions. Therefore, STARK can improve scalability.
Side note: As far as solutions based on early SNARK technology (ie, Groth16) are concerned, whenever a new version of Groth16 is launched, a trusted initialization ceremony must be performed. Therefore, when the latest version of Loopring was launched last year, the mechanism described below also needs to be implemented. There is also a variant of SNARK called Universal SNARK (Universal SNARK) or SNORK (for example, PLONK and SONIC). This technique uses universal trusted setup (universal trusted setup) . For example, the creators of zkSync do not need to implement a trusted initialization mechanism when the new version is launched: they reused the execution results of multi-party calculations performed by more than 200 celebrities including Vitalik last year. Through universal trusted initialization, the zero-knowledge proof scheme used in the protocol can be extended or updated without performing a new ritual.
(Ambient: SNORK = Succinct Non-interactive Oecumenical (Universal) aRguments of Knowledge, which is actually a SNARK with a universal and scalable trusted initialization setting.)
3. Architecture
What the solutions described in this article have in common is that they all use zero-knowledge cryptography. The difference between them stems from data availability issues.
3.1 Data availability issues
Transaction data and information related to user balances can be stored on the underlying blockchain or not on the blockchain. This requires a basic trade-off between scalability and security.
The security of storing data on the chain is similar to storing assets directly on Ethereum, without requiring users to perform additional operations. Users can get data at any time. This is very important, especially if the scalability solution provider’s server is compromised or malicious. The availability of data on the chain allows users to create a proof to prove that they hold a certain number of tokens, and these tokens can be directly taken out of the smart contract without interacting with the second-tier system. The zero-knowledge proof-based solution that stores data on the chain is called zkRollup .
The scalability solution of storing data off-chain introduces data availability issues and therefore weakens the security of the second-tier solution. Once a scalability solution provider terminates the cooperation, ordinary users cannot withdraw their funds unless they can obtain data representing their balance. This type of solution is called Validium . In order to alleviate the problem of data availability, this type of scheme may introduce a multi-party committee , which is responsible for storing copies of data and sharing the copies with users if the provider commits evil or terminates the service.
However, storing data off-chain has a big advantage: higher scalability . Solutions that use off-chain storage are not subject to the limitations of blockchain. Therefore, this type of solution is more conducive to improving transaction throughput than using on-chain storage solutions.
Recently, StarkWare proposed a hybrid solution that allows users to freely choose whether to store data on or off-chain. Users can choose once every time they initiate a transaction, so their choices change dynamically. This scalability solution is called Volition .
Original link: https://ethworks.io/ethereum-scaling-report.html Author: EthWorks translation & proofreading: Min Min & safety laboratories
This article is translated and republished by EthFans authorized by the author.