Partnered With:

Opinion: Understanding Ethereum and its future from the perspective of "state"

Read this article in 37 Minutes

Just like the Ethereum paradigm faces design trade-offs, all of these scalability solutions face trade-offs

Original title: "Viewpoint: Understanding Ethereum and its future from the perspective of "state""

Original source: Ethereum enthusiasts (ID: ethfans)

I. Introduction

Since its creation in 2015, the Ethereum blockchain has experienced 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, have naturally attracted 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.

The point of this article is that, just as the Ethereum paradigm faces design trade-offs, so do all these scalability schemes; Whether it is worth it or not requires us to return to Ethereum itself, to 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 programs and reveal our gains and losses.

This article will start by explaining the meaning of "state", revealing the ultimate spear and Achilles' heel of Ethereum, and then discussing various improvement directions. "Rich state" is the source of the "combinability" of 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 by people will affect "combinability", and which "scalability" has more obvious meaning.

2. Ethereum as a paradigm

< span>(1) Rich state and composability

What is "state"? 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 blockchain protocol can be roughly divided into two parts, one part is Consensus mechanism, the other part is the state transition rules (sometimes called "consensus rules"); the former defines block rules, which indicate when all nodes participating in the blockchain need to update the blockchain database locally state (for example, as a node of the Ethereum blockchain, whenever a block with proof-of-work that meets the difficulty requirements is received, the node updates the latest state of the local blockchain database); and the state The conversion rules define what transactions are valid ("an account cannot spend more money than its own balance"), and also define how the node should update the state when processing the transaction ("this transaction means that account A transferred 5 2 coins to account B, then the balance of account A will be subtracted 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 The 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 a breakthrough innovation?

We often hear that Ethereum is special because it "introduces A Turing-complete programming language that supports programmability" and so on. In fact, this statement is not accurate 2. Because it doesn't mean anything to allow a more complex programming language, as Bitcoin can be programmed; allowing Bitcoin to use the solidity programming language doesn't get you an Ethereum. What's really special about Ethereum is its "rich statefulness"3 : it allows one contract to call another contract, and, apart from the block size itself, imposes no restrictions 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 contract A state...Thus, although a state is stored in the A contract, 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 the asset (use conditions) to be Constantly get stricter and more complex control; this means that, theoretically speaking, a state 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 a Part of the global state, and requires 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.

Yes, now we have collected three attributes like collecting dragon balls:

< section>(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, which is shared with all other accounts Public;

(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 summon 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 contract's The combinations can be infinitely varied. 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, is it? 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 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 lies in: 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 contract The status update of the Ethereum node is calculated by the Ethereum node (and the user who initiates the calculation request pays for it). This "serverless" architecture is very comfortable; however, these states will be permanently stored in Ethereum's fully verified In the node, although you need to pay for each update, it is unavoidable that the state data saved locally by the node will continue to accumulate and expand.

The reason why the expansion of state data is a problem is that it will bring more and more High hard disk (random) read and write load. 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 has also been 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. Therefore, the research on the state rent mechanism also stagnated in 2019 5. 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 don't see a satisfying, fundamentally The solution to this problem, and "statelessness", let's be realistic, also faces many challenges. We will talk about this later.

In short, the global state, on-chain computing and rich state, not only make the contracts on Ethereum composable, but also make the network of Ethereum trapped in the centralized Dangerous; just like the Lord of the Rings in the novel "Lord of the Rings", it can not only summon powerful forces, but also swallow 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 Ethereum

< p>

In this chapter, we will analyze four development directions of Ethereum: Layer-2 scheme, fragmentation, 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.

(1) Layer-2 scheme< /h3>

The idea behind the Layer-2 scheme comes from a simple but very precise intuition: the reason why Ethereum is facing a throughput problem The bottleneck is because the bandwidth, computing power, and ability to maintain state data of the nodes that make up the Ethereum network are limited, and it is difficult to improve; simply requiring the nodes of the entire network to process more transactions per unit time, the operation of the nodes The requirements will inevitably rise, which will damage the decentralization; however, from the perspective of use, it is not necessary to put all the state on the Ethereum, and it is not necessary to let all the state calculations happen on the Ethereum; We can save the intermediate state (or all states) of a contract elsewhere, and user interaction (that is, state updates) does not occur on the Ethereum blockchain; only when the user considers it necessary to settle a certain state , and then send the status to Ethereum, which will be confirmed by Ethereum.

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 participating in a After the two users of the channel lock the funds into the contract, the transactions between the two will not be sent to the chain after that. They use other communication tools to exchange signed messages with each other, and thus achieve mutual agreement on the status of the channel. Consensus (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 think that there is no need to interact (or it is necessary to temporarily settle once), the mutually approved The state and the signatures of the two parties are sent to Ethereum, and then Ethereum updates the state of the contract and settles funds for the two according to this state.

If you regard the Layer-2 scheme as a design pattern of the contract, you will see more clearly - The Layer-2 scheme chooses not to use 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 for something extremely valuable: faster Faster transaction speed (although the confirmed intermediate state is not as secure as the state of the main chain), lower handling fees, and smaller burden on the main chain nodes.

But why hasn’t the Layer-2 approach 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 main network. 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 the following, we will see how the Rollup solution solves this problem.)

( 2) Fragmentation

Another intuition to improve Ethereum and increase Ethereum throughput is : The throughput of Ethereum is limited, because each full node must process all transactions on the chain; if we can let each node process only a part of the transaction, and different groups of nodes 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 of these groups of nodes; that is, the burden on a single node does not increase, but the throughput of the entire system increases (and the finer the grouping, the greater the throughput. the larger the multiplier). This is called "sharding".

An interesting question about sharding 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, if the front-end technology required by the sharding architecture It can be realized, how meaningful this structure can be.

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 That is to say, one shard cannot know the internal state of another shard in real time. 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 time, the more unbearable the delay; The application will never schedule the processing power on other shards through cross-shard transactions, because it is meaningless 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 people think that these "idle" shard throughput can be used by more niche applications. I think that Layer-2 solutions can achieve the same Effect, and less changes to the underlying layer, more secure.)

(three ) Statelessness (statelessness)

Statelessness is the only way to face the state The upgrade direction of the data expansion problem 7.

In the current Ethereum protocol, the transaction itself does not carry the state it accesses information, and it is for this reason that nodes processing transactions must maintain state data as a precondition for executing state transition functions. 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 state it visits Therefore, a block is verifiable by itself, without the node processing the transaction having state.

Actually, statelessness is to change the structure of Ethereum blocks and change the The verification method of the block. 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.

However, to be honest, statelessness currently faces many, many design challenges. Specifically:

(1) Statelessness requires a proof (witness) of the accessed state attached to the block/transaction, and the scale of this part of data may be very large Large, the current block data size of Ethereum is about 20-40 KB, but the size of the witness data may be at the MB level (depending on the size of the accessed state volume);

(2) Only maintenance Witness can only be assembled by nodes with all the states, 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 Pricing 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 states 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 methods 8.

I am biased to believe that the future of Ethereum is some scheme inspired by statelessness, if not statelessness.

(4) Rollup scheme

The Rollup scheme is a Layer-2 scheme, which is special in that it will use the Transactions are published on the Ethereum blockchain.

Like other Layer-2 schemes, the Rollup scheme also stores the state off-chain, and does not The nodes of Ethereum are required to calculate the new state of the contract; however, the transactions that will change the state of the contract are published as data, which means that any third party can rely on these public data and public rules to calculate state of the contract (although a contract on Ethereum cannot utilize these states).

As mentioned earlier, when the Lyaer-2 contract chooses to move the state calculation outside the Ethereum chain, and It conceals its own contract state, which introduces risks to users: users do not know whether the operator of the Layer-2 contract will send an invalid state to the chain for the blockchain to finalize, if the operator Being able to do this is equivalent to directly stealing the user's funds; in addition, the user does not know whether the operator of the Layer-2 contract will review his own transaction and freeze his 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, the Ethereum implements 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; With a deposit, if the submitted status root is invalid, the person who reports the status root can get the original submitter's deposit, 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 a transaction to Ethereum to update the 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 without your permission, Maker DAO cannot confiscate your DAI; at the same time, assuming it also discloses the construction method of computational integrity, 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 51% attacking the rollback state, the attacker can 51% of the time censorship attack to inject the wrong state root into the contract; or you can bet that everyone who has calculated the latest state of the contract will not 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.

In other words, if the user is willing to deposit money into a stateful contract (such as compound, maker dao, uniswap), then There is no reason not to want to deposit into a rollup contract (if you have to add a qualifier, it is a zk-rollup contract). With zk-rollup, the layer-2 solution can already provide users with the greatest degree of financial security that contracts on the Ethereum blockchain can provide. Obviously, only by doing this will it be possible to achieve mass adoption.

All Layer-2 schemes can be regarded as a compromise towards statelessness: Layer-2 scheme itself is a stateless state (for other contracts, the internal state of the Layer-2 contract is inaccessible), no matter how complicated the internal state is, it will not increase the burden on the Ethereum node; at the same time, update the Layer-2 contract (the state root) At this time, the role of Ethereum is more of verification, that is, verifying that the update of the state root is valid, rather than calculating the state root by itself. However, in the rollup era, the Layer-2 solution proved that it can be as safe as a stateful contract, and its promise can be realized.

Four. Conclusion

< p>

In summary, in this article, I explain where Ethereum's "composability" comes from, and whether various hotly debated scalability schemes sacrifice this Combination, what did you get in exchange? Readers may notice that when I reason and evaluate, I put a lot of emphasis on "what we have achieved/get" and "what people's behavior shows they need". Yes, it is from this perspective that I explain the charm of the rollup scheme (in fact, this may be one of the core motivations for me to write this article). In my opinion, such a thinking tendency can make the starting point of our thinking more reliable, avoid guessing the needs of users, and avoid investing in building castles in the air.

In the flow of history, I have seen people choose certain things among the optional things, which makes me have to think that these things are important and there is no reason to have confidence in technologies that neither increase what people choose, nor sacrifice what people actually choose.