Ethereum’s development route should not blindly pursue scalability. In the final analysis, only performance improvements that meet the needs of users are truly meaningful.
Original title: “Viewpoint | Should Ethereum’s Roadmap Change? 》
Written by: A Jian
Since the publication of “A Rollup-centric ethereum roadmap” ( Chinese translation ), the entire community has raised questions about the roadmap of Ethereum (especially Ethereum 2.0).
On November 18, 2020, in the fifth AMA event (a Chinese excerpt ) of the Eth2.0 research team of the Ethereum Foundation, Vitalik clearly stated that the roadmap has changed: (1) I will not emphasize it temporarily The importance of Phase2, Phase 1 is committed to achieving data sharding (shard data) for use in Rollup mode; (2) The beacon chain will have execution functions, that is, after the merger of Eth1-Eth2, the beacon chain block will directly contain transactions (3) The three major tasks after Phase 0 implementation: light client support, data fragmentation, and merging will be advanced in parallel, and any module will be launched as long as it is ready.
The purpose of this article is not to defend the original three-phase roadmap. On the contrary, this article wants to argue that the three-phase roadmap is elusive and the new roadmap is tasteless. There is no Eth2.0-related roadmap worthy of Ethereum abandoning its current operating mode and turning to a PoS-based system.
Here, I will first explain the argumentation ideas and technical difficulties of the initial three-stage roadmap; then I will analyze the scalability of the new roadmap. Finally, it is demonstrated that the scalability advantages of the new roadmap are already small enough to make Ethereum risk the transition to PoS.
Three-phase roadmap for Eth2.0
In the past two years, the widely circulated Eth2.0 roadmap has planned three sequential implementation components:
Phase 0: Beacon chain with PoS as consensus mechanism
Phase 1: Multiple shard chains
Phase 2: Add execution functions to all shards
It can be clearly seen from this roadmap that the original Ethereum 2.0 goal is to create a “sharded execution” system, meaning: each shard has its own state, and these states are The state transition rules of each shard are changed; the changed state is finalized by the beacon chain; thus, Ethereum 2.0 becomes a system where multiple shards can process transactions in parallel. This also means that Ethereum 2.0 is a decoupling system of “consensus” and “transaction processing (verification)”. The verifiers assigned to each shard are responsible for verifying the correctness of transactions and states; but the finalization of these states Relying on the epoch finalization mechanism of the beacon chain, the two processes are not completely synchronized.
This “PoS beacon chain + multi-sharding” architecture seems to make good use of the characteristics of the PoS algorithm itself: in order to solve the No-thing-at-stake problem (PoS block generation does not require computational effort, so it is eligible Block-producing accounts will try to produce blocks on different forks at the same time, causing the system to fall apart). The Casper algorithm used in Ethereum 2.0 requires users to deposit a portion of the deposit to obtain block-producing qualifications, and if the validator abuses the block-producing qualifications (Such as supporting two forks at the same time), you will be fined and forfeited the deposit; therefore, algorithms like Casper actually create two states on the blockchain that can communicate with each other but change independently: one is ordinary The state of the user, the other is the block weight state of the validator; the consensus process is based on the block weight state, and reaching a consensus will also change the block weight state; therefore, the consensus process is inherently independent of the verification of user transactions and can be solved Coupling; for any transaction batch and result state, the consensus process can be abstracted into a “final finalization mechanism”. Logically, parallel execution of multiple shards becomes possible.
As for its scalability, the name of the Ethereum sharding technology “Quadratic sharding” reveals the clue: assuming that the transaction on the shard, its execution complexity can be reduced to the same difficulty as the block header verification , The fragmented execution architecture can make the processing capacity of the entire system increase quadratically as the processing capacity of the participating nodes increases linearly. Generally speaking, if the nodes participating in the network (on average) can verify 4 block headers within a period of time, this means that when participating in a shard, the nodes can verify 4 transactions in the same time. At this time, the total processing volume of the system is 4 shards × 4 transactions/shards = 16 transactions; if the processing capacity of the node becomes 8 (2 times), the processing volume will become 64 transactions (4 times).
It sounds wonderful, but this “square expansion” argument contains the following assumptions:
(1) There is a technology that enables the verification of fragmented transactions to be simplified to the same difficulty as verifying the block header;
(2) There is no cross-shard transaction, that is, the transactions within each shard are completely independent of each other. Cross-shard transactions need to occupy the processing capacity of multiple shards, as well as the processing capacity of the beacon chain, which greatly compromises the scalability.
Regarding (1), this hypothesis is likely to be satisfied. Statelessness is such a technology. The idea is that when a transaction is propagated (or when a block is propagated), it is accompanied by a proof of the access state of the exchange. (Witness), so that the verifier of the transaction can verify the validity of the transaction without having to hold the state data at the time of transaction execution. This is extremely critical. If there is no statelessness, the validators participating in the shard verification must save the state of the shards, because the validators will be continuously allocated to different shard chains, which means they must save all the The state of the piece, in practice, means that they have to continuously download all sharded blocks and process transactions, so that the entire system collapses into a large block system (for example: invest in resources that can handle 16 transactions and process 16 Transactions). Unfortunately, so far, Ethereum 1.0 has not developed a sufficiently lightweight stateless method.
Regarding (2), there is nothing to say. If cross-shard transactions cannot be implemented, the system of sharding execution is meaningless, because each shard is its own business. There must be a way for ETH to exist on each shard so that this system can still take ETH as the main body. As of today, there has not been a cross-shard transaction scheme that can not increase the processing capacity of the beacon chain. The reason is also very simple. For any shard A, because of parallel processing, what transactions are happening on any shard B, it is unknowable whether the state of the shard needs to be rewritten, so there must be a communication layer that can be trusted It proves that a transaction that tried to rewrite the state of A segment occurred on the B segment. Once the beacon chain needs to be able to process transactions, the effect of quadratic expansion will be broken. (By the way, the chain that satisfies the needs of this trusted communication layer becomes the de facto Layer-1, and the other fragments become the de facto Layer-2, like “Layer- 1 + Layer-2”.)
In addition to questionable scalability, fragmented execution also brings many interesting economic problems. For example, if the processing time of a cross-shard transaction exceeds the processing time of an intra-shard transaction (which is inevitable), this means that the value of ETH on different shards will not be the same. Just like one dollar in the United States and one dollar outside the United States are actually not the same thing. No matter how many shards there are, there will be at least two ETH prices, one is the price of ETH on the shard with the most prosperous financial application (that is, the Eth1 shard); the other is ETH on other shards The latter must pay a certain fee and a certain amount of time before it can be replaced with the former, so there must be some discount for the former. In the same way, even if there is uniswap on each shard, the slippage of the market on different shards must be different. Eventually everyone will be gathered on one shard, because when everyone is together, the liquidity is the most abundant and the capital efficiency is the highest . To some extent, it can be considered that the need for cross-shard transactions is very small-but this also means that the idle transaction processing capacity on other shards is meaningless.
The technical difficulties of the fragmented execution system will not be repeated here. Those who are interested can think about how to pay the handling fee for the fragmented execution system. But what I want to say here is that the design concept of the fragmented execution system violates everyone’s actual needs and violates the law of development of things. The global state (composability) is not a problem, but it is what everyone needs; it is precisely because Ethereum enables all financial applications to be combined instantly, creating a space where value can circulate without friction, Ethereum has It has the potential to change the world; creating friction for value circulation at the agreement level is self-defeating martial arts. When you have a good foundation layer, you should find a way to maintain this foundation layer, and let users choose the remaining things and let the ecology evolve by itself-don’t think that design can design an ecology, over-design just imposes costs on everyone.
The shelving of the fragmented execution (Phase 2) side confirms the difficulty-in the foreseeable future, this path will not produce satisfactory results. Nevertheless, I do not think that the Eth2.0 researchers have completely abandoned the three-phase roadmap. Vitalik also emphasized that the changed roadmap is also fully compatible with Phase 2, except that Phase 2 no longer has priority.
But in fact, giving up fragmented execution is the path that Ethereum should choose.
Executable beacon link diagram
In the new roadmap of Ethereum 2.0, the most eye-catching point is that the beacon chain block will contain the transactions of the merged Eth1 shard, that is, the beacon chain has an execution function. Other slices only have the function of saving data.
In fact, the positioning of “data sharding” in the new roadmap is “data availability layer for Rollup”.
Without execution sharding, there is no way to talk about quadratic expansion. So, how is the scalability of this “PoS Layer-1 + Rollup + Rollup data does not occupy the main chain block space” architecture?
To answer this question, let’s take a look at the interaction mode between the Rollup scheme and the main chain.
First of all, you can understand a Rollup system as a stateless contract. The internal state of the contract (which user has how much money) is invisible to the outside; however, all transactions that occur in the contract will be regularly disclosed. It will be released to the main chain so that any third party can reconstruct the internal state of the contract after obtaining the data.
The feature of Rollup (such as ZK Rollup) that uses a validity certificate is: every time the contract discloses transaction data, it is accompanied by a “computational integrity certificate” that these transactions have been executed correctly, so the new state root should be XXX; If the proof can pass the verification of the contract, the contract updates the state root; if the proof fails the verification, the contract refuses to update.
The rollup (such as Optimistic Rollup) that uses false proofs is the opposite: every time anyone publishes transaction data for the contract, he must deposit a deposit and assert that the new state root of the contract is YYY; after a period of time, Anyone else can deposit a deposit and issue a false proof to challenge the assertion; the false proof proves that the batch of transactions is flawed, or the new state after the transaction is processed is not YYY; if the challenge is successful, the person who issued the false assertion The deposit will be lost; if no one challenges for a period of time, the contract update status root is YYY.
Both of these schemes must publish data on the chain, which will occupy space on the chain; moreover, the size of the space on the chain determines the processing capacity of the Rollup system per unit time (ie, TPS). Think deeper. If these transaction data can be published in a place with a smaller data volume constraint, or in other words, without occupying the space of the Layer-1 block, the processing volume can have a double effect. If there are many such places, it can also produce a multiplier effect.
This is the concept of “data sharding” and “Rollup-centric roadmap”: Let the Rollup solution put all transaction data in shard blocks, and the processing capacity can be increased by many times as many shards as there are; the current The amount of data in the Ethereum block is about 20-30 KB. This amount of data is obviously safe. Then, if we have 64 shards, we can provide 64*30 = 1920 KB = 1.9 MB of data every 15 seconds. . Moreover, I provide such a large data throughput on the user side, but it will not be a burden on the full node, because you can download the data if you want to download it, and you can not download it if you don’t want to download it (that is, the meaning of “sharding”). Everyone, you download a bit, I download a bit, the burden on the node is still very light-anyway, verifying the status of these Rollup contracts does not require me to have all the historical transaction data of the Rollup. The state of Ethereum is still safe.
It sounds reasonable, but the sentence is too optimistic, too many assumptions:
(1) This “download if you want to download, download if you don’t want to download” method does not work at all on ZK Rollup: When ZK Rollup wants to update the state root, the verifier of the ZK Rollup contract update operation (that is, Layer- The full node of 1) must also obtain the transaction data corresponding to the proof when accepting the proof, otherwise it will not be able to pass the verification. (There is no need to provide transaction data. There is also a scheme to advance the contract state root only by verifying the proof, called Validium, which is not Rollup). In other words, if only ZK Rollup is considered, the “data fragmentation” method is no different from large blocks in terms of bandwidth. No matter who the data is initially sent to and where it is stored, all nodes must download them.
(2) For Optimistic Rollup, if you are willing to take a more optimistic assumption, of course, you can, you can usually not download transaction data at all, and only keep the latest state root that obtains the finality, and download the relevant only when there is a dispute. From the point of view of the full node, the transaction data does not lose the ability to verify the state of the contract; but from the point of view of the user, things are completely different: you start to be uncertain whether you can reconstruct your state at any time To complete the withdrawal. In other words, users will not be sure whether they are using Optimistic Rollup or plasma. Originally, Optimistic Rollup’s solution was to ensure that all full nodes have a backup of historical transactions, so users can easily rebuild their state and submit a state certificate (or assertion) to complete the withdrawal; but if this guarantee is lost, you will Not sure if I can rebuild the state. The security of Optimistic Rollup will also be affected: its security assumption is that at least one person who has obtained transaction data is abiding by the protocol; in the data fragmentation mode, you don’t know how many people will go Request this part of transaction data.
All in all, when the “data sharding” mode is paired with ZK Rollup, it cannot provide greater scalability in the sense of bandwidth, and has the same effect as expanding the block space; when paired with Optimistic Rollup, compared to large blocks, Its scalability advantage is inversely proportional to the frequency of challenges; more serious is that it makes Optimistic Rollup at risk of degenerating into plasma (by definition, there is no Optimistic Rollup anymore, and another name should be used to refer to this Something between Optimistic Rollup and plasma).
in conclusion
The Rollup program is actually a phoenix that has learned bloody lessons from the development of Layer-2. Its biggest feature is that it provides sufficient protection for the safety of users’ funds. Because anyone who gets the transaction data can rebuild the state, and the blockchain guarantees the sustainable data availability of these transaction data, the Rollup solution can provide the premier user protection in the layer-2 solution. Only with such a program, users dare to really use it. Abandoning this benefit, designing the system according to the optimistic assumption of maximizing performance can only design things that users dare not use.
As long as you realize that Rollup is essentially a contract design pattern, the myth of “PoS + data sharding + Rollup can provide greater throughput” can be penetrated at a glance-Rollup can provide no matter which consensus it is in. The same scalability, data sharding can provide more, just because other security assumptions are introduced, so that Rollup sacrifices security in exchange for throughput. The problem is that such a contract is weaker than Rollup. A more scalable contract is not that it has never appeared before, and it is not designed on the POW chain, but it is designed and no one uses it.
Since 2017, the Ethereum community has struggled to explore secure scalability solutions for practical needs. Many people may have believed that “PoS + sharding” can provide powerful scalability, but that is a “sharded execution system” and has its own problems. The “executable beacon link” in front of us is nothing more than sacrificing the properties of the contract in exchange for throughput. Today, there is no evidence to prove that for scalability, Ethereum should embrace PoS.
In the final analysis, only performance improvements that meet the needs of users are truly meaningful performance improvements. If you do not proceed from the actual needs of users, on the contrary, proceed from the assumption of technical beauty or maximum performance, you can only design castles in the sky. If you can, let users make their own decisions. Too much worry at the protocol layer often increases friction.
Should Ethereum’s roadmap change? Of course, you should give up these unrealistic illusions and go back and ask users what they need.
Source link: mp.weixin.qq.com
