'Stateless Ethereum' aims to tackle the blockchain's growing data burden as ETH 2.0 development progresses

The developers behind Stateless Ethereum – a project aimed at preserving the resilience of the ETH 1.0 network despite the continuous growth of the blockchain – will begin its implementation phase by the end of 2020, according to project lead Alexey Akhunov.

In Ethereum, a complete "state" refers to the status of all accounts, balances, and smart contract records on the network. The state is updated every time a new block is created.

Currently, every full node needs to download and store the state of the entire blockchain, which currently weighs in at around 200 gigabytes and grows by 10 to 15 gigabytes every month, according to the Ethereum Foundation blog. This rising storage requirement would then lead to longer sync times and fewer nodes over time, compromising the network’s overall resilience.

The concept of the "stateless client" – which Ethereum co-founder Vitalik Buterin first raised in 2017 – aims to alleviate this problem by letting clients store a partial state. Under the proposed system, each newly mined block would come with what’s called a block witness – a set of Merkle branches consisted of the minimal required information to prove a block's validity. A "stateless" node only needs to store a partial Merkle Tree rather than the entirety of it.

"It takes a long time for many computers to read their hard drive, so block processing is slow if that block needs to access thousands of accounts," Buterin told The Block. "If those clients instead receive the block with the witness containing the data, they don't need to access a hard drive and so can process blocks more quickly."

Moreover, this would allow clients to run a node without consuming a very large amount of hard disk space, he added, and make it much faster to start up a node, as there's no need for a sync process to fetch the state.

Why stateless clients?

"Stateless Ethereum is essentially the idea that you could transform the Ethereum network by introducing different types of nodes," Akhunov explained.

The proposal will also introduce a new syncing mechanism to distribute data to various clients. While some clients will act as the network's data providers, the majority of them can simply acquire the state over the network, which is more efficient than extracting the state from their own databases.

This alternative arrangement would allow people to run nodes on cheaper hardware without giving up full control over their data, Akhunov said.

For example: traditionally, if someone has a multisig wallet, they would have to either run to a full node or use a light client to obtain the transaction data.

If they run a full node, their privacy would be protected, since outsiders could not tell which bits of information out of the entire state they are interested in. However, this requires high-performing equipment. With a light client, although the user can request specific information from the server, the server could potentially figure out where their wallet is located.

Having a stateless client avoids this tradeoff between efficiency and privacy, Akhunov contended. The client will download the part of the state pertaining to the user's wallet. As it starts validating data on the network, it will update the partial state whenever it encounters information relevant to the wallet (e.g. someone sends ETH to their wallet) and will do so in a way that no one can tell whether the user is keeping track of this particular wallet.

Akhunov acknowledged that Ethereum's relative gas cost will have to increase if stateless clients get implemented. There needs to be an extra charge roughly proportional to the size of the witness, he said, to disincentivize nodes from generating a huge witness that will be very slow to propagate.

"I think we're still at the level where state access is underpriced relative to the computation," he said. "So the relative cost of the state access will increase."

Implementation phase to start by the end of 2020

"Stateless Ethereum" is still in the research phase, which will take at least the remainder of 2020 to complete. But Akhunov said that he is planning to start deploying some implementations in the meantime.

Specifically, he will focus on shipping the new sync network and migrating the state to the binary tree before the end of the year – two key steps in Akhunov’s roadmap for the implementation of stateless Ethereum.

"We want to get them implemented even before all the research is done and start testing them as something adjacent to the mainnet, because it's going to validate that the project is actually working and that we can actually deliver something," he said. "After that, we will start working on the witness network and everything else."

The team's initial implementation efforts will focus on the conversion of the current hexary tree into a binary tree, which is expected to cut down the overall witness size by about 50%. However, migrating the entire state to the new binary tree is far from an easy task, and developers would have to regenerate the entire Merkel tree.

Notably, Akhunov has been working on a separate project, called Turbo-Geth, which would enable faster migration to binary tree hashing. While it would take another implementation at least a month to recode the database into the binary format, it would only take minutes for Turbo-Geth to do so.

Turbo-Geth will be released in about a month. After that, the team will create a special sync network to distribute the binary version of the state to anyone who wishes to have it. Once the sync network is built out, developers will schedule a migration time.

"I would like it to happen within the next four months," Akhunov said. "And then people need to get comfortable with it and sync their nodes to actually upgrade themselves to the binary tree. That might take another three to four months.

"In my optimistic projection, we might decide to move into the binary tree by the end of the year," he continued. "And by this time, we should have researched most of the other things, but not implemented."

ETH 1.x in the context of ETH2.0

ETH 1.x brings together a number of upgrades to the existing Proof-of-Work (PoW) protocol and aims to continue improving the Ethereum network as ETH 2.0 gets implemented. However, as a key ETH 1.x project, the performance benefits that stateless clients could potentially bring are not limited to the PoW chain.

Specifically, Akhunov said, the sync network that his team is developing could be useful for sharding – a key feature of the ETH 2.0 blockchain.

In ETH 2.0, there will be a central blockchain, the Beacon Chain, that coordinates all 64 side chains called “shards.” Every shard will act as a full PoS system and contain an independent piece of state and transaction history. Instead of processing all network transactions, each node only processes transactions for a certain shard.

"If we manage to do our work well, then the mechanism that we will be using for this new sync network will actually be very useful for sharding, because then each shard will have its own sync network and it will allow the validators to very efficiently switch between shards," he said.

Buterin has highlighted stateless Ethereum as integral to his overall vision for the network’s gradual transition into Proof-of-Stake (PoS), claiming in his personal roadmap that the project would make the ETH1.0 network more "eth2-friendly."

Indeed, Buterin told The Block that the "most important" reason for statelessness is in the ETH 2.0 context; block verification in ETH 2.0 will not be possible without stateless clients.

"In an ETH 2.0 context, validators are quickly being reassigned to different shards, so they do not have time to fetch the state of a shard they are assigned to and there are too many shards for them to store all the states," he said. "Hence, the only way we can make it possible for eth2 validators to verify blocks is by making validators stateless clients."

But Akhunov downplays the connection, holding the view that progress on ETH 2.0 should not have much impact on his team's work.

"I do not want to design around to ETH 2.0," he said. "I think it should be the other way around because our design space is already very constrained.”