Opinion | Should Ethereum’s roadmap change?

Since the publication of "A rollup-centric ethereum roadmap" (Chinese translation), the entire community has questioned the roadmap of Ethereum (especially Ethereum 2.0).

The ghost of PoS is hovering over Ethereum.

Since the publication of "A rollup-centric ethereum roadmap" (Chinese translation), the entire community has questioned the roadmap of Ethereum (especially Ethereum 2.0).

On November 18, 2020, in the fifth AMA event of the Eth2.0 research team of the Ethereum Foundation (Chinese excerpt translation), Vitalik clearly stated that the roadmap has changed: (1) The importance of Phase 2 is no longer emphasized for the time being. Phase 1 is committed to realizing data sharding for use in rollup; (2) The beacon chain will have execution functions, that is, after the Eth1-Eth2 merger, the beacon chain block will directly include transactions; (3) The three major tasks after the implementation of Phase 0: light client support, data sharding, and merging will be promoted in parallel, and any module will be launched as soon as it is ready.

The purpose of this article is not to defend the original three-phase roadmap. Instead, this article wants to argue that the three-phase roadmap is illusory, the new roadmap is boring, and no roadmap related to Eth2.0 is worth abandoning Ethereum's current operating model and moving to a PoS-based system.

Here, I will first explain the argumentation ideas and technical difficulties of the initial three-phase roadmap; then analyze the scalability of the new roadmap. Finally, I will argue that the scalability advantage of the new roadmap is too small to make Ethereum risk switching to PoS.

Eth2.0’s three-phase roadmap

Over the past two years, the widely circulated Eth2.0 roadmap has planned three components to be implemented in sequence:

• Phase 0: Beacon Chain with PoS consensus mechanism

• Phase 1: Multiple Shard Chains

• Phase 2: Add execution capabilities to all shards

It can be clearly seen from this roadmap that the original goal of Ethereum 2.0 is to create a "sharded execution" system, which means that each shard has its own state, which changes according to the state transition rules of each shard; 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 system in which "consensus" and "transaction processing (verification)" are decoupled, and the validators assigned to each shard are responsible for verifying the correctness of transactions and states; but the finalization of these states depends on the epoch finalization mechanism of the beacon chain, and the two processes are not completely synchronized. This "PoS beacon chain + multi-shard" architecture seems to make good use of the characteristics of the PoS algorithm itself: in order to solve the "nothing-at-stake" problem (PoS block generation does not require computational effort, so accounts eligible for block generation will try to generate blocks on different forks at the same time, causing the system to fall apart), the Casper algorithm used by Ethereum 2.0 requires users to deposit a portion of the deposit before they can be eligible to generate blocks. If the validator abuses the block generation qualification (for example, supporting two forks at the same time), the deposit will be confiscated. As a result, algorithms like Casper actually create two states on the blockchain that can communicate with each other but change independently: one is the state of ordinary users, and the other is the state of the validator's block weight. 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 decoupled. For any transaction batch and result state, 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 Ethereum's sharding technology, "quadratic sharding", reveals a clue: Assuming that the execution complexity of transactions on the shard can be reduced to the same difficulty as block header verification, the sharded execution architecture can make the processing capacity of the entire system increase quadratically with the linear increase of the processing capacity of the participating nodes. In layman's terms, if the nodes participating in the network (on average) can verify 4 block headers in a period of time, this means that when participating in a shard, the nodes can verify 4 transactions in the same time, and the total system processing capacity 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). It sounds good, but this "quadratic expansion" argument contains the following assumptions:

(1) There is a technology that can simplify the verification of shard transactions to the same difficulty as verifying block headers;

(2) There are no cross-shard transactions, that is, transactions within each shard are completely independent of each other. Cross-shard transactions require the processing capacity of multiple shards and the processing capacity of the beacon chain, which will greatly reduce scalability.

Regarding (1), this assumption can be satisfied. Statelessness is such a technology. Its idea is to provide a witness to the transaction access status when propagating transactions (or blocks), so that the transaction verifier can verify the validity of the transaction without holding the state data at the time of transaction execution. This is extremely critical. Without statelessness, the validators participating in shard verification must save the state of the shards, because the validators will be continuously assigned to different shard chains, which means that they must save the state of all shards. In practice, this means that they have to continuously download blocks from all shards and process transactions, thus collapsing the entire system into a large block system (for example: investing resources that can process 16 transactions to process 16 transactions). Unfortunately, to date, Ethereum 1.0 has not developed a sufficiently lightweight stateless method.

There is nothing much to say about (2). If cross-shard transactions cannot be implemented, the sharded execution system is meaningless because each shard is independent. ETH must be able to exist on each shard so that the system can still be based on ETH. To date, there has not been a cross-shard transaction solution that does not increase the processing capacity of the beacon chain. The reason is very simple. For any shard A, due to parallel processing, it is unknown what transactions are happening on any shard B and whether the state of this shard needs to be rewritten. Therefore, there must be a communication layer to credibly prove that a transaction occurred on shard B that attempted to rewrite the state of shard A. Once the beacon chain needs to have the function of processing transactions, the quadratic expansion effect will be broken. (By the way, the chain that meets the needs of this trusted communication layer becomes the de facto Layer-1, while the other shards become the de facto Layer-2, which is very similar to "Layer-1 + Layer-2".)

In addition to questionable scalability, sharded execution also brings up a lot of interesting economic issues. For example, if the processing time of cross-shard transactions exceeds the processing time of a single intra-shard transaction (which is inevitable), this means that the value of ETH on different shards will not be the same. Just like $1 in the United States is not actually the same thing as $1 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 financial applications (that is, Eth1 shard); the other is the price of ETH on other shards; the latter must pay a certain fee and spend a certain amount of time to exchange for the former, so there must be some discount to the former. Similarly, even if there is uniswap on each shard, the transaction slippage of the market on different shards will definitely be different, and everyone will eventually 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 argued that the need for cross-shard transactions is very small - but this also means that the idle transaction processing capacity on other shards is simply meaningless. The technical difficulties of the sharded execution system will not be elaborated here. Those who are interested can think about how the sharded execution system pays the transaction fees.

But what I want to say here is that the design concept of the sharded execution system goes against everyone's actual needs and the laws of development of things. Global state (composability) is not a problem, but something that 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, that Ethereum has the potential to change the world; creating friction for value circulation at the protocol layer is self-defeating. When there is a good basic layer, we should find a way to maintain this basic layer, and let users choose the rest and let the ecosystem evolve by themselves - don't think that design can design an ecosystem, over-design only imposes costs on everyone. The shelving of sharded execution (Phase 2) indirectly confirms the difficulty - in the foreseeable future, this path cannot produce satisfactory results for us. Despite this, I don't think that Eth2.0 researchers 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 sharded execution is the path that Ethereum should choose.

Executable Beacon Link Line Diagram

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 layer for rollup". Without execution sharding, quadratic expansion is out of the question. So, how scalable is this "PoS Layer-1 + rollup + rollup data does not occupy the main chain block space" architecture? To answer this question, let's first look at the interaction mode between the rollup solution 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 occurring in the contract will be regularly made public and published to the main chain, so that any third party can reconstruct the internal state of the contract after obtaining this data. The characteristics of rollups that use validity proofs (such as zkRollup) are: every time the contract publishes transaction data, it is accompanied by a "computational integrity proof" that these transactions have been correctly executed and therefore 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 cannot pass the verification, the contract refuses to update. The scheme of rollups that use fraud proofs (such as Optimistic Rollup) is the opposite: every time anyone publishes transaction data for a contract, they must deposit a deposit and assert that the new state root of the contract is YYY; within a period of time thereafter, anyone else can deposit a deposit and issue a fraud proof to challenge the assertion; the fraud proof proves that the batch of transactions is flawed, or that the new state root after the transaction processing is not YYY; if the challenge is successful, the person who issued the wrong assertion will lose the deposit; if no one challenges for a period of time, the contract updates the state root to YYY. Both solutions must publish data on the chain, so they will occupy on-chain space; moreover, the size of the on-chain space determines the processing volume (TPS) of the rollup system per unit time. If you think more deeply, if these transaction data can be published in a place with smaller data volume constraints, or in other words, it does not occupy the space of the Layer-1 block, then its processing volume can be doubled.

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 into the sharded blocks. The number of shards will increase the processing capacity by many times; the current Ethereum block data volume is about 20-30 KB, which is obviously safe. 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 become a burden on the full node, because you can download these data if you want, and you don't have to download them if you don't want to (that is the meaning of "sharding"). Everyone downloads a little, and I download a little, and 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 again, it is too optimistic and contains too many assumptions: (1) This “download if you want to, don’t download if you don’t want to” approach simply does not work on zk rollup: when zk rollup wants to update the state root, the verifier of the zk rollup contract update operation (that is, the full node of Layer-1) must also obtain the transaction data corresponding to the proof when accepting the proof, otherwise it will fail the verification.

(There is also a solution that does not require transaction data and only verifies proofs to advance the contract state root, called Validium, which is not a rollup.) In other words, if we only consider zk rollup, then the "data sharding" method is no different from large blocks in terms of bandwidth. Regardless of who the data was originally sent to and where it was stored, the full node must download it. (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, only keep the latest state root that obtains finality, and only download relevant transaction data when a dispute occurs. From the perspective of the full node, it does not lose the ability to verify the contract state; but from the user's perspective, things are completely different: you begin to be unsure 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 backups of historical transactions, so users can easily rebuild their status and submit status proofs (or assertions) to complete withdrawals; but if this guarantee is lost, you are not sure whether you can rebuild the status. 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 complies with the protocol; in the data sharding mode, you don’t know how many people will request this part of the transaction data. In short, when the "data sharding" mode is used with zk rollup, it cannot provide greater scalability in terms of bandwidth, but has the same effect as expanding the block space; when used with optimistic rollup, its scalability advantage is inversely proportional to the frequency of challenges compared to large blocks; more seriously, it puts optimistic rollup at risk of degenerating into plasma (by definition, there is no optimistic rollup, and another name should be used to refer to this thing between optimistic rollup and plasma).

in conclusion

The Rollup solution is actually a phoenix that has learned from the bloody lessons of the development of Layer-2. Its greatest feature is that it provides full protection for the security of users' funds. Because anyone who obtains the transaction data can reconstruct the state, and the blockchain guarantees the perpetual data availability of these transaction data, the rollup solution can provide the best user protection among the layer-2 solutions. Only with such a solution will users dare to really use it. Abandoning this benefit and designing the system based on the optimistic assumption of maximizing performance can only design something that users dare not use. As long as you realize that rollup is essentially a contract design pattern, the myth that "PoS + data sharding + rollup can provide greater throughput" can be seen through at a glance - rollup can provide the same scalability regardless of the consensus, and data sharding can provide more. It is just because other security assumptions are introduced that rollup sacrifices security in exchange for throughput - the problem is that such contracts, which are less secure and more scalable than rollup, have appeared before, and they cannot be designed on the pow chain, but no one uses them even if they are designed.

Since 2017, the Ethereum community has been struggling to explore secure scalability solutions for practical needs. Many people may have believed that "PoS + sharding" can provide strong scalability, but that is a "sharded execution system" with its own problems. The "executable beacon link" in front of us is nothing more than sacrificing the properties of the contract itself in exchange for throughput. To this day, there is no evidence that Ethereum should embrace PoS for scalability. In the final analysis, only performance improvements that meet user needs are truly meaningful performance improvements. If we do not start from the actual needs of users, but instead start from the assumption of technical beauty or maximizing performance, we can only design castles in the air. If possible, let users make their own decisions. Worrying too much at the protocol layer often increases friction. Should Ethereum's roadmap change? Of course, we should abandon these unrealistic fantasies and go back to ask what users need.