Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans), reprinted by Odaily with authorization.
Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)Ethereum enthusiasts (ID: ethfans), reprinted by Odaily with authorization.
first level title
I. Introduction
Since its creation in 2015, the Ethereum blockchain has gone through five winters and summers. Five years have not only turned the Ethereum Protocol 1 as a concept into reality, made this protocol more mature and more specific, but also exposed the characteristics and trade-offs of such a set of designs. These trade-offs, as a design challenge, naturally attract and continue to attract countless talents to try to improve the usability of Ethereum; among them, the one that brings together the most effort and imagination is to improve "scalability" series of plans.What this article wants to point out is that just as the Ethereum paradigm faces design trade-offs, all these scalability solutions also face trade-offs; and to evaluate whether these trade-offs are worthwhile or not, we need to go back to Ethereum itself, to Ethereum The real problems and real needs of Ethereum nodes and Ethereum users. The "state" perspective, as a perspective for understanding Ethereum itself, can just help us clarify the design of these schemes and reveal our gains and losses.This article will start by explaining the meaning of "state", reveal the ultimate spear and Achilles heel of Ethereum, and then explore various directions for improvement. "Rich state" is the source of "composability" in Ethereum smart contracts, but it is also the biggest weakness of the Ethereum network. From this, we can see which solutions that are often mentioned will affect "combinability", and which "scalability" has more obvious meaning.2. Ethereum as a paradigm(1) Rich state and composabilityWhat is a "status"? The state is the specific situation of a system at a certain moment. Taking the blockchain that implements cryptographic currency as an example, the state of a blockchain at a certain moment is the asset distribution of all addresses on the blockchain at that moment (address A has 10 coins, address B has 100 coins , etc.) (In fact, what we have is just some states, which are interpreted by our minds and social consensus as "assets").From this perspective, each set of blockchain protocols can be roughly divided into two parts, one is the consensus mechanism, and the other is the state transition rules (sometimes called "consensus rules"); the former defines the block generation rules , which indicates when all nodes participating in the blockchain need to update the state of the blockchain database locally (for example, as a node of the Ethereum blockchain, whenever it receives a job that meets the difficulty requirements The node will update the latest state of the local blockchain database); and the state transition rules define what transactions are valid ("an account cannot spend more money than its own balance"), and also It defines how the node should update the state when processing the transaction ("this transaction means that account A transfers 5 coins to account B, then the balance of account A will be reduced by 5, and the balance of account B will be added by 5").For Bitcoin, its consensus mechanism is "PoW + Nakamoto Consensus", and its state transition rules are based on UTXO. For Ethereum, its block generation mechanism is "PoW + Ghost rules", and its state transition rules are based on accounts.So, what is it that makes Ethereum such a groundbreaking innovation?We often hear that the reason why Ethereum is special is that it "introduces a Turing-complete programming language that supports programmability" and so on. In fact, this statement is not accurate 2. Because allowing a more complex programming language doesn't mean anything, in fact, Bitcoin can also be programmed; allowing Bitcoin to use the solidity programming language does not get an Ethereum. What makes Ethereum really special is its "rich statefulness"3: it allows one contract to call another contract, and, apart from the block size itself, imposes no limit on the number of levels of such calls.Contract B can call contract A and change the state of contract A according to the code disclosed by contract A; contract C that calls contract B can also indirectly call contract A and change the state of A contract, but its control logic can be so overlapping and continuously accumulated; if the state is understood as an asset, this is equivalent to allowing the right to use (conditions of use) of the asset to be continuously controlled more strictly and more complicated; this means , theoretically speaking, a status update logic can be infinitely close to financial contracts in real life (because all financial contracts can be superimposed and combined through simple logic). This attribute that allows the accumulation of arbitrary layers of control is the most critical, but how to program this control is secondary.In addition, Ethereum also allows users to write states to the blockchain, making these states part of the global state, and requiring nodes to update the state according to the logic defined by the contract. As a result, a contract can disclose its own state to all other accounts on Ethereum, and the aforementioned rich statefulness really comes into play.That's right, now we have collected three attributes like collecting dragon balls:
(1) Computing paradigm on the chain: contracts can require nodes to perform calculations according to their own defined logic;
(2) Global state: The state of the contract can become part of the global state and be disclosed to all other accounts;(3) Rich state: Contracts can call each other, and there is no limit to the number of stack layers, so the control logic can be accumulated layer by layer;Now we can call out Ethereum's strongest spear: "Composability" (currency LEGO)!The computing method on the chain allows us to have a variety of contracts; the global state allows these contracts to access each other's state; the rich state allows the combination of contracts to be infinitely diverse. So we can not only have the stable currency DAI, but also have a lending market, a lottery application, an application that automatically donates the proceeds of the lottery, and an application that automatically rebalances the savings ratio between different lending markets... …(2) State data explosion problem"Composability" is too good to be true, right? Yes, the trinity of the above three attributes is actually a double-edged sword.The state transition process of Ethereum can be abstracted as: the state transition function takes the old state and transaction list as input, and outputs the new state. This means that Ethereum's full-verification nodes must maintain the latest state of the Ethereum blockchain locally, so that they can execute state functions and use the results to verify the validity of a block (and also agree with other Ethereum nodes. consensus).The contradiction is: for the contract and the developer, the state of the contract is stored on the node of the Ethereum as part of the global state of the Ethereum, and the status update of the contract is calculated by the node of the Ethereum (and also by the node that initiates the calculation request. The user pays), this "serverless" architecture is very comfortable; however, these states will be permanently stored in the full verification node of Ethereum as long as one payment is made, although each update requires payment, but it cannot be avoided. The status data will continue to accumulate and expand.
The reason why the expansion of state data is a problem is that it will bring higher and higher hard disk (random) read and write burdens to full verification nodes. State data is not like block data. Block data is static and does not need to be read and written frequently after persistent storage; however, state data needs to be read and written many times for each additional block. , the burden of reading and writing will become heavier and heavier. In the past few years, we have often heard people say that the full node of Ethereum is difficult to deploy, and this is one of the main reasons. Some time ago, Infura’s free Ethereum node service crashed 4, causing many services that depend on Infura to crash.
This problem is not easy to solve. In the past few years, Ethereum's multiple hard fork upgrades have increased the gas consumption of opcodes that access the state, precisely to curb the creation of new states by contracts at an economic cost. But this is obviously only a palliative solution, because the logic has not changed fundamentally, the state data must continue to be stored on the Ethereum node, but the user who creates the state data only needs to pay once. It was also suggested that in order to change this, some kind of "state rent" mechanism needs to be introduced, requiring the contract that saves the state to pay rent continuously, otherwise the availability of the contract will be terminated. However, this mechanism has unimaginable complexity. On the one hand, it is difficult to determine a reasonable method of collecting rent, and on the other hand, it is also difficult to determine a reasonable payment object. So the research on the state rent mechanism also stagnated in 20195. There are also projects (such as Nervos) that try to define the size of the available state space based on the amount of currency held, so the size of the state data will always have an upper limit, which avoids the problem of state expansion, but this also changes the original assets. economic attributes.
So far, I have not seen a satisfactory fundamental solution to this problem other than "statelessness", which, realistically speaking, also faces many challenges. We will talk about this later.
All in all, the global state, on-chain computing and rich state, not only make the contracts on Ethereum composable, but also make the Ethereum network in danger of centralization; just like the Lord of the Rings in the novel "Lord of the Rings" , can not only summon a powerful force, but also devour the user himself. I worry that Ethereum will bear this burden for a long time.
Next, we use the "state" perspective to understand the design and trade-offs of various scalability solutions.3. The development direction of EthereumIn this chapter, we will analyze four development directions of Ethereum: Layer-2 scheme, sharding, stateless and Rollup scheme. This classification is completely unreasonable, because rollup is a subset of Layer-2 schemes; and statelessness is a pre-sharding technology; even, it is unreasonable to juxtapose them, because Layer-2 schemes hardly require Change the bottom layer of Ethereum, and sharding and statelessness have such requirements. This is done only for the convenience of description and understanding.The idea behind the Layer-2 scheme comes from a simple but very precise intuition: the reason why Ethereum faces a throughput bottleneck is because the bandwidth, computing power, and ability to maintain state data of the nodes that make up the Ethereum network are all Limited, and it is difficult to improve; simply requiring the nodes of the entire network to process more transactions per unit time, the operating requirements of the nodes will inevitably increase, which will damage decentralization; however, from the perspective of use, it does not It is necessary to put all the states on Ethereum, and it is not necessary to let all state calculations happen on Ethereum; we can save the intermediate state (or all states) of a contract in other places, and the user's interaction (That is, the update of the state) does not happen on the Ethereum blockchain; only when the user thinks it is necessary to settle a certain state, then the state is sent to Ethereum for confirmation.In a word: If we can't make the network reach a consensus on more transactions per unit time, then improve the connotation of a single transaction.
The classic Layer-2 scheme "state channel" embodies this idea most thoroughly: when two users participating in a channel lock funds into the contract, transactions between the two will not be sent to the chain afterwards, and they Use other communication tools to exchange signed messages and reach a consensus on the state of the channel (so no matter how many messages they send and receive and how much state data they form, it will not become a burden on Ethereum); until the two People think that there is no need to interact (or it is necessary to temporarily settle once), so they send the mutually recognized state and the signatures of the two people to Ethereum, and then Ethereum updates the state of the contract, and according to this state, the two Person settlement funds.
If you regard the Layer-2 solution as a design pattern of the contract, you will see it more clearly - the Layer-2 solution chooses not to utilize the global state. Another contract cannot know in real time what state is inside a Layer-2 contract (how much money does user A\B\C have), because these states are not on the chain, and therefore, a Layer-2 contract is Cannot be combined with other contracts.Even so, the Layer-2 solution has also exchanged extremely valuable things: faster transaction speed (although the confirmed intermediate state is not as secure as the state of the main chain), lower handling fees, and a smaller burden on the main chain nodes .But why hasn't the Layer-2 solution borne fruit in the past few years? Because before the Rollup scheme appeared, other schemes, including state channels and Plasma, could not prove that the funds locked into their own contracts were as safe as those locked into stateful contracts (neither frozen nor stolen) . In the state channel scheme, if you do not monitor the blockchain at all times, your counterparty can "steal" your money by submitting the old state to the main chain; in the Plasma scheme, you often need to rely on the operator To provide you with proof of your own status, so it is very difficult for the operator itself to defend.This is completely different from the experience of using state contracts on the Ethereum mainnet. Excluding the code risk of the contract, the money you deposit in the contract will not be stolen unless someone launches a 51% attack to cancel your transaction; Withdraw your own funds. (In a later article, we will see how the Rollup solution solves this problem.)Another intuition to improve Ethereum and increase the throughput of Ethereum is: the throughput of Ethereum is limited, because each full node must process all transactions on the chain; if we can let each node only process a part of the transaction, the difference The nodes in the group process different transactions separately (in parallel), then the throughput of the entire system per unit time is equal to the sum of the single-group processing capacity of these groups of nodes; that is, the burden of a single node does not increase, but the overall The throughput of the system is increased (and the finer the packets, the greater the throughput multiplier). This is called "sharding".
An interesting question about sharded architecture is its exact definition. In a classic, non-sharded blockchain architecture, full nodes must (1) repeat all computations; (2) maintain all state; and (3) propagate all blocks/transactions. Some people think that only one of them needs to be broken to be considered fragmented; but from a more strict perspective, all three must be broken to achieve the theoretically derived throughput improvement effect 6 . Different definitions have different effects. Here, the definition I take is that a node at least does not need to maintain all the state of the entire system.
But another more interesting question is how meaningful this architecture can be if all the front-end technologies required by the sharding architecture can be realized.In the sharding architecture conceived by the research team of the Ethereum Foundation, the state of the entire system is divided into several parts, and each part is updated in parallel. The internal state of the slice. When contract A' in shard A tries to call contract B' on shard B, it cannot be assumed that the processor owns the state of shard B, and therefore, the processing result must wait for shard B to complete the state update before returning . As a result, cross-shard transactions must endure the most unbearable cost in transaction processing: delay. The point is that this delay cannot be abstracted with a monetary cost. Because shard B does not know that a transaction that needs to call itself has occurred on shard A, so it can only wait for a trusted communication layer to broadcast this transaction for itself.The higher the value that can be created per unit of time, the more unbearable the delay; and this means that, assuming that there is a shard in a certain DeFi application concentration, these applications will not schedule the processing on other shards through cross-shard transactions at all capacity, because it is meaningless at all and cannot meet the delay requirements of DeFi applications. Similarly, this also means that the processing power of a single shard of the shards aggregated by this DeFi application is the upper limit of its processing power (no difference from a single blockchain). Building houses and building roads in deep mountains and old forests cannot solve the problem of living space for people in metropolises.(Some argue that these "idle" shard throughputs can be exploited by more niche applications. I think a Layer-2 solution can achieve the same effect, but with fewer changes to the underlying layer and is safer.)Statelessness is the only upgrade direction that directly faces the problem of state data expansion 7.In the current Ethereum protocol, the transaction itself does not carry the information of the state it visits. It is for this reason that the node processing the transaction must maintain the state data as a precondition for executing the state transition function. It is precisely because of this that the expansion of state data is a problem (increasing the burden on nodes).
The key to statelessness is to let the transaction/block itself attach the information of the state it visits. Therefore, a block is verifiable by itself, and there is no need for the node processing the transaction to have state.
In fact, statelessness is to change the verification method of Ethereum blocks by changing the structure of Ethereum blocks. There is no need to maintain state data, which eliminates the need to read and write hard disks, and the speed of block verification can also be faster. In addition, each node can either not maintain state data at all, or maintain the state data of some contracts according to its own needs.But, to be honest, statelessness currently faces many, many design challenges. Specifically: (1) Statelessness requires that blocks/transactions be attached with proofs (witness) of the accessed state. The scale of this part of data may be very large. The current block data size of Ethereum is about 20-40 KB. However, the size of the witness data may be at the MB level (depending on the size of the accessed state volume); (2) Only the nodes that maintain all the states can assemble the witness, so who will provide the state for ordinary users? (Actually, this can be regarded as a change in the operating assumption of Ethereum: all full nodes can participate in mining; but not after statelessness is realized); (3) How to price the gas consumption of transactions ? Especially because of the timeliness of the witness, it is not possible to determine how much computation it takes to assemble the witness based on the opcode.Because of these difficulties, Ethereum's full nodes may have to run in this mode of maintaining all state for a long time. However, statelessness is definitely the most exciting direction for current improvements to the Ethereum protocol. Because it directly faces the core problem of Ethereum, and tries to solve this problem from the bottom up. In addition, research on the use of state data in the Ethereum protocol has also nourished other research directions, such as synchronization methods8.I am biased to believe that the future of Ethereum is some kind of scheme inspired by statelessness, if not statelessness.The Rollup scheme is a Layer-2 scheme. Its special feature is that it will publish the transactions used in each state update on the Ethereum blockchain.Like other Layer-2 schemes, the Rollup scheme also stores the state off-chain, and does not require Ethereum nodes to calculate the new state of the contract; however, all transactions that will change the state of the contract are published as data, which means That is, any third party can calculate the state of the contract by virtue of these public data and public rules (although a contract on Ethereum cannot use these states).As mentioned earlier, when the Lyaer-2 contract chooses to move the state calculation out of the Ethereum chain and obscure its own contract state, it introduces risks to the user: the user does not know that the operator of the Layer-2 contract will An invalid state will not be sent to the chain to be finalized by the blockchain. If the operator can do this, it is tantamount to directly stealing the user's funds; in addition, the user does not know the operation of the Layer-2 contract Investors will not censor their own transactions, thus freezing their own funds.There are two ways to solve the problem of stolen funds. One is to ensure that every state transition is valid, that is, every time the state root of the contract is to be updated, let Ethereum execute a verification program for the integrity of the calculation. Only after the verification is passed, the contract is allowed to update the state root. This is the idea of zk-rollup; another idea is to require people to attach a deposit when requesting to update the contract state root. If the submitted state root is invalid, Those who report this state root can get the deposit of the original submitter, which is optimistic-rollup. But the latter idea has a prerequisite: the whistleblower must have a way to obtain the state before the state transition, otherwise there is no way to generate a false proof of the transition.There is only one way to solve the problem of locked funds: weaken the concept of "operator" as much as possible, so that anyone can submit transactions to Ethereum to update the state of the Layer-2 contract. But this goes back to the question: if the submitter does not have the state of the contract, how can he prove the validity of his state access and let the contract release it?
Finally, the Rollup solution solves this problem by "publishing matching transaction data at every state transition". Therefore, although the Rollup contract does not disclose the state on the chain, anyone—including users of the rollup contract—can reconstruct the internal state of a rollup contract based on these public transaction packages. This means that, if properly designed, the funds in the rollup contract can be as safe as the state-saved contracts on the Ethereum blockchain (that is, the contracts we commonly use now)!
Taking zk-rollup as an example, the on-chain verification program ensures that a rollup contract cannot update a wrong state root, just like Maker DAO cannot confiscate your DAI without your permission; at the same time, assuming it also discloses the calculation Integrity construction method, you can directly initiate a state transition to the contract on the chain at any time to withdraw your own money. This is exactly like a normal, stateful contract: there is no way to roll back the state of the rollup contract without a 51% attack, and there is nothing to stop you from getting your money back without a constant 51% attack.Optimistic-rollup relies on some cryptoeconomic assumptions, so it is slightly weaker: in addition to the 51% attack rollback state, the attacker can also inject the wrong state root into the contract through the 51% review attack lasting for a period of time; Take a bet that no one who has calculated the latest state of the contract will observe the error (the probability is extremely small). But Optimistic-rollup can also provide strong custody-free, and you can get your money back at any time.
