Opinion: Should Ethereum's roadmap change?
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans), Author: A Jian, reproduced by Odaily with authorization.
Ethereum enthusiasts (ID: ethfans)Chinese translationEthereum enthusiasts (ID: ethfans)
, Author: A Jian, reproduced by Odaily with authorization.From "A rollup-centric ethereum roadmap" (Chinese translation
) since the publication of the article, the entire community has raised questions about the roadmap of Ethereum (especially Ethereum 2.0).
Chinese translation of excerpts
), Vitalik made it clear that the roadmap has changed: (1) The importance of Phase 2 is no longer emphasized for the time being, and Phase 1 is dedicated to implementing data sharding (shard data) for rollup use; (2) Beacon The chain will have the execution function, that is, after the merger of Eth1-Eth2, the beacon chain block will directly contain transactions; (3) The three major tasks after the implementation of Phase 0: light client support, data fragmentation, and merger will be promoted in parallel. Either module is rolled out as soon as it is ready.
Three-stage roadmap for Eth2.0
Phase 0: Beacon chain with PoS as consensus mechanism
Phase 1: Multiple shard chains
Phase 2: Add execution functionality to all shards
Over the past two years, the widely circulated Eth2.0 roadmap has planned three sequential components:
Phase 0: Beacon chain with PoS as consensus mechanism
Phase 1: Multiple shard chains
Phase 2: Add execution functionality to all shards
From this roadmap, it can be clearly seen that the original goal of Ethereum 2.0 is to create a "sharded execution" system, which means: each shard has its own state, and these states are divided into 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 in which multiple shards can process transactions in parallel. This also means that Ethereum 2.0 is a decoupled 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 depends on Relying on the epoch finalization mechanism of the beacon chain, the two processes are not completely synchronized.
This "PoS beacon chain + multi-shard" architecture also seems to make good use of the characteristics of the PoS algorithm itself: in order to solve the No-thing-at-stake problem (PoS blocks do not need to pay calculations, so they are eligible The account that produced the block 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 part of the deposit first to be eligible for block production, and if the verifier abuses the block production qualification (such as supporting two forks at the same time), the deposit will be fined; thus, algorithms like Casper actually create two states on the blockchain that can communicate with each other but change independently of each other: one is ordinary The other is the state of the user, and the other is the block weight state of the verifier; 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, which can solve coupling; for arbitrary transaction batches and result states, the consensus process can be abstracted into a "finality finalization mechanism", and logically, multi-shard parallel execution becomes possible.
As for its scalability, the name of the Ethereum sharding technology "Quadratic sharding (Quadratic sharding)" reveals the clue: assuming that the execution complexity of the transaction on the shard can be reduced to the same difficulty as the verification of the block header , then the fragmented execution architecture can make the processing capacity of the whole system increase quadratically with the linear increase of the processing capacity of participating nodes. In layman's terms, if nodes participating in the network (on average) can verify 4 block headers within a period of time, it means that when participating in a shard, nodes can verify 4 transactions in the same time. The total processing capacity of the system is 4 shards × 4 transactions/shard = 16 transactions; if the processing capacity of the node becomes 8 (2 times), the processing capacity will become 64 transactions (4 times).
Sounds good, but the "square-level expansion" argument includes the following assumptions:
(1) There is a technology that simplifies the verification of shard transactions to the same difficulty as verifying block headers;
(2) There are no cross-shard transactions, that is, transactions in each shard will not depend on each other at all. Cross-shard transactions need to occupy the processing capacity of multiple shards, and also occupy the processing capacity of the beacon chain, which will greatly reduce scalability.
Regarding (1), this assumption is likely to be satisfied. Statelessness is such a technology. Its idea is that when disseminating transactions (or disseminating blocks), there is 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 verifiers participating in the shard verification must save the state of the shards, because the verifiers will be continuously assigned to different shard chains, which means that they must save all shards. In practice, it means that they have to continuously download blocks of all shards and process transactions, so that the entire system collapses into a large block system (for example: invest resources that can process 16 transactions, process 16 transactions). Unfortunately, so far, Ethereum 1.0 has not developed a sufficiently lightweight stateless method.
In addition to questionable scalability, sharded execution poses a number of economically interesting 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. It's as if a dollar inside the United States is not actually the same thing as a dollar outside the United States. 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 luxuriant financial application (that is, the Eth1 shard); the other is the price of ETH on other shards The latter must pay a certain handling fee and pay a certain amount of time before it can be exchanged for the former, so there must be some discount for the former. In the same way, even if there is uniswap on each shard, the transaction slippage of the market on different shards must be different. In the end, everyone will converge 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 there is little need for cross-shard transactions - but this also means that the idle transaction processing capacity on other shards is meaningless at all.
The technical difficulties of the fragmented execution system will not be repeated here. Those who are interested can think about how the fragmented execution system pays the handling fee. But what I want to say here is that the design concept of the fragmented execution system goes against everyone's actual needs and also goes against the law of development of things. Global state (combinability) is not a problem, but exactly what everyone needs; it is precisely because Ethereum enables all financial applications to be combined instantly, creating a space where value can circulate with zero friction, and Ethereum has It has the potential to change the world; creating friction for value circulation at the protocol layer is self-defeating. When you have a good base layer, you should find a way to maintain this base layer, let users choose the rest, 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 fragmented execution (Phase 2) proves the difficulty of it—in the foreseeable future, this path will not produce satisfactory results. Even so, I don't think the researchers of Eth2.0 have completely abandoned the three-phase roadmap. Vitalik also emphasized that the changed roadmap is also fully compatible with Phase 2, but Phase 2 no longer has priority.
But in fact, abandoning fragmentation execution is the path that Ethereum should choose.
secondary title
Executable Beacon Chain Roadmap
In the new roadmap of Ethereum 2.0, the most striking point is that the beacon chain block will contain the transactions of the merged Eth1 shard, that is, the beacon chain has the execution function. Other shards only have the function of saving data.
In fact, the positioning of "data sharding" in the new roadmap is "data availability (data availability) layer for rollup".
Without executable sharding, quadratic scaling is out of the question. So, what 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 this contract (which user has how much money) is not visible to the outside world; however, the data of all transactions that occur in the contract will be disclosed regularly Come out and publish it on the main chain, so that any third party can reconstruct the internal state of the contract after obtaining these data.
The characteristics of rollup (such as zkRollup) using validity proofs are: every time the contract discloses transaction data, it comes with a "computational integrity proof" that these transactions have been executed correctly, so the new state root should be XXX; if If the proof can pass the verification of the contract, the contract will update the state root; if the proof cannot pass the verification, the contract will refuse to update.
The scheme of rollup (such as Optimistic Rollup) using error proof is the opposite: every time anyone discloses transaction data for the contract, they 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 that the new state after transaction processing is not YYY at all; 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.
These two solutions must publish data on the chain, so they 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). Thinking a little deeper, if these transaction data can be released in a place with less data constraints, or in other words, if they don’t occupy the space of Layer-1 blocks, then the processing capacity can be doubled. If there are many such places, it can also produce a multiplied effect.
(1) This method of "download if you want to download, and don't download if you don't want to download" 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- 1) must also obtain the transaction data corresponding to the proof when accepting the proof, otherwise it will fail to pass the verification. (There is no need to provide transaction data, and there is also a solution to promote the root of the contract state by only verifying the proof, called Validium, which is not rollup). In other words, if only zk rollup is considered, then the "data sharding" method is no different from large blocks in terms of bandwidth. Regardless of who the data was sent to and where it was stored in the first place, all nodes must download it.
in conclusion
(2) For optimistic rollup, if you are willing to take a more optimistic assumption, of course you can. You can not download transaction data at all, and only keep the latest state root of finality. Only when a dispute occurs, download the relevant From the point of view of the whole node, it 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 are not sure 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, the optimistic rollup solution is to ensure that all full nodes have a backup of historical transactions, so users can easily rebuild their own state and submit state proofs (or assertions) to complete withdrawals; 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 of the people who obtained the transaction data abides by the agreement; in the data sharding mode, you do not know how many people will go Request this part of transaction data.
All in all, when the "data sharding" mode is combined with zk rollup, it cannot provide greater scalability in terms of bandwidth, but has the same effect as expanding the block space; when combined with optimistic rollup, compared with large blocks, Its scalability advantage is inversely proportional to the frequency of challenges; more seriously, it risks degenerating optimistic rollup into plasma (by definition, optimistic rollup does not exist anymore, and should be referred to by another name Something between optimistic rollup and plasma).
secondary title
in conclusion
The Rollup solution is actually a phoenix that flew out after learning bloody lessons from the Layer-2 development process. Its biggest feature is that it provides sufficient protection for the safety of users' funds. Because anyone who has obtained the transaction data can rebuild the state, and the blockchain guarantees the continuous data availability of these transaction data, the rollup scheme can provide the second-to-none user protection among layer-2 schemes. Only with such a solution, users dare to really use it. Abandoning this benefit and designing a system based on the optimistic assumption of maximum performance can only design things that users are afraid to use.
