Towards Ethereum 2.0: Understanding “Stateless Authentication Mechanism”

The most well-known changes in Ethereum 2.0 are staking and sharding. These changes are inspired by Ethereum.

When Ethereum was launched in 2015, it introduced the concept of a “universal” blockchain, where anyone can build applications that interact with ETH and various tokens on the network. These applications have opened the door to maturity for decentralized finance (DeFi) and have developed into financial products that hold more than $1 billion in mortgage assets.

It will still take 2-3 years for Ethereum 2.0 to fully launch, and Eth 2.0 will be deployed as an independent blockchain composed of a beacon chain and multiple shard chains, while Eth 1.0 It needs to be modified and upgraded to become one of the shard chains in Eth 2.0. This means that the current Ethereum 1.0 blockchain needs to be changed, and it will continue to operate and continue to develop for the next 5 to 10 years. And Eth 1.x is the code name for the upgraded version of Ethereum 1.0. The primary goal of Eth 1.x is to solve the growing data burden of the current blockchain.

When people talk about Ethereum and its state scale, you may have heard of “state bloat”. This means that paying a GAS fee will allow your data to be permanently stored on the Ethereum blockchain, resulting in an infinite and growing state, in which there is even a lot of useless data. State is expanding in storage space, which means that as the network is used, Ethereum nodes need more storage or higher performance hardware. In the long run, this increases the threshold for the operation of Ethereum nodes, and whenever the block GAS limit increases, state growth becomes a bigger problem.

Statelessness

The concept of stateless client was first proposed by Vitalik in the context of exploring Sharding, but it was also discussed later in the discussion around Eth1.X. At first this approach was considered too complicated, but as the Trinity bean sync approach demonstrated the feasibility of semi-statelessness for light clients, the concept of stateless clients gained a lot of support.

What is “status”?

To explain stateless Ethereum, we first need to understand the concept of “state”. When we refer to “state”, we generally mean “the state of the transaction.”

The complete “state” of Ethereum describes the current state of all accounts and balances, as well as the collective history of all smart contracts deployed and running in the EVM. Each final block on the chain has one and only one state, which is jointly confirmed by all participants in the network. Whenever a new block is added to the chain, the state will change and update accordingly. The core idea of ​​the stateless client is that the entire state is not accessed when the transaction process is executed in the block.

Eth 1.X expansion problem

The focus of Eth1.x research is to transfer the current Ethereum chain to a “stateless client” (Stateless Ethereum), and the ultimate goal is to smoothly transition to an executive environment in Eth2.0 (Executive Environment).

Ethereum has been released for nearly 5 years. Behind the amazing growth, the industry has also noticed what its bottleneck is. As it becomes more and more difficult to run full nodes, the Ethereum network may become more and more centralized; As the network delay increases, its speed may become slower and slower; with the emergence of “state expansion”, block verification may become more difficult. Ultimately, as transaction throughput reaches the upper limit and client improvements become more and more difficult to achieve, both end users and core developers will be frustrated.

Ethereum 2.0

Ethereum 2.0 is the largest open source in the history of the cryptocurrency field. It aims to provide a new system to achieve more of the expected goals of Ethereum. You may have heard of Casper (Proof of Stake) and sharding, but it contains many goals that Ethereum 2.0 will include.

Since many improvements of Ethereum 2.0 are definitely breakthrough changes for the existing ETH1.0, these changes will be built on the Eth2 chain, and the existing Ethereum 1.0 chain will be “inserted” (turned into a shard) In the new system. In this way, Eth2 does not need to perform complex upgrades to the existing network, and the Ethereum network will operate normally and enjoy all the benefits of the new system.

The core purpose of Eth 1.X is twofold:

(A) Extend the life of Eth 1.0.

(B) Link with Eth 2.0.

Since the shards in Eth 2.0 will be stateless, “stateless” will be a prerequisite for participating in Eth 2.0 block verification. If Eth 1.0 is compatible with Eth 2.0, it must support stateless operation so that it can transition smoothly and interface with Eth 2.0.

Specifically, it is to find a way for some nodes in the Ethereum network to keep a copy of the entire Ethereum state as an option, not a requirement. Therefore, the current Ethereum network must be able to support lightweight nodes that do not preserve the complete network state: “stateless nodes” participate in the verification of new blocks in the network.

It is important that the transition to the stateless or semi-stateless paradigm will damage the existing Eth1.0 network less than methods such as state rent, because this method will not bring significant changes to existing clients. Stateful nodes and stateless light clients can coexist at the same time, and the semi-stateless (semi-stateless) Ethereum will provide more opportunities to experiment with different client implementations. At the same time, shards in Eth2.0 will almost certainly be stateless, so when the time is right, this will open up a new path for Eth1.0 to eventually transition to Serenity.

Eth2.0 will develop towards the goal of statelessness, which means that light (stateless) nodes will be able to verify all transactions and all parts of the state without actually storing any state. Statelessness allows light clients to exist in various states/stateless, and each state requires different specifications to make the node easier to access.

Since each shard has its own unique state, the verifier in Eth2 needs to perform state changes on the state of the verified shard. The stateless protocol saves the verifier from downloading the state of the shard every time it switches, but only needs to download the binary merkle tree representing the data (which is much smaller). The more shards, the more endless the state growth will be. There will always be services like exchanges or block explorers that encourage them to keep all the state/data of the shard chain and deliver them accurately regardless of cost.

This opens the door for software that acts as a “state provider” that provides the state part of the transaction change to the validator so they can easily perform state changes. The state repeater helps to completely transfer the disk I/O and storage-intensive parts of the verification process to another entity. This opens the door to interesting incentive schemes (for state, this has always been an issue with Ethereum), and greatly benefits validators who no longer need to keep the entire shard state.

The above introduction, I believe that readers should have a simple understanding of the changes needed to upgrade the current Eth 1.0 to Eth 1.x. After the Eth 1.x upgrade is completed, people will be able to run their own stateless nodes (light nodes) with cheap hardware, and more light nodes that can participate in verification can further maintain the security of the entire network.

Only Eth1.x with a stateless verification mechanism can smoothly interface with the Eth2.0 beacon chain and other shard chains, officially allowing the Ethereum network to enter the lightweight Eth 2.0 constructed by the stateless verification mechanism and sharding technology future.