Why Decentralized State is important for Ethereum

Execution Layer Research
1

Thanks @gballet for reviews and feedbacks.

Summary

This article describes how Decentralized State (DS) can address upcoming challenges for Ethereum as planned upgrades reach the mainnet. We will begin by outlining these problems, highlighting the limitations of currently proposed solutions, explain how Decentralized State offers a viable path forward and why it is important to consider it early.

An in depth technical analysis and specification of Decentralized State protocol is out of scope of this article.

Problems

To define the problems, we assume several upgrades from the strawmap reach Ethereum as planned:

  • FOCIL (EIP-7805) - Already SFI for Hegotá
  • Native AA (Account Abstraction) - Frame tx (EIP-8141) is already CFI for Hegotá, but any form of Native AA that requires state access (beyond nonce and ETH balance) for tx validation would be relevant for this post
  • Stateless Clients - We assume it is viable to run a validator node without storing the Execution Layer (EL) state. This requires one of:

The assumption is that once Stateless Clients are available, most full nodes will eventually become Stateless nodes. Full nodes currently serve purposes other than validating the blockchain, and some of them can’t be served by Stateless nodes. Maintaining these functionalities in a decentralized manner is important for protocol health, as relying on centralized entities creates long term risk.

Stateless validator nodes will still have non-trivial disk requirements (likely hundreds of GB), as they must run a full Consensus Layer client, store (partial) blobs (via PeerDAS) and store blocks (or at least partial blocks via Block-in-Blobs (EIP-8142)).

Mempool & Focil

A healthy protocol requires a large public mempool. To participate, clients must check transaction validity. Currently, this involves checking the signature, nonce, and ETH balance. However, mempool designed for Frame transactions (and most likely other Native AA solutions) requires clients to at least access sender’s storage, and sender’s and payer’s bytecode for tx validation.

Inclusion List (IL) committee members have similar requirements as Mempool members → they want to be able to validate the transaction. If they can’t validate what they include, FOCIL becomes vulnerable to spam, undermining its core function.

Syncing Full Nodes

One of the core properties of Ethereum is that anyone can run a full node to verify the blockchain. If full nodes are the sole providers of state data, syncing new nodes may become difficult as existing nodes might limit data serving to preserve their own resources (assuming number of full nodes is significantly smaller than today).

Self-sovereign access to blockchain

The majority of end-users and wallets rely on RPC providers to access Ethereum. Without them, they can’t even query balance, create new transactions, or do almost anything. If a user wants to access Ethereum in a censorship resistant and private manner, they have to either run some kind of light client and query the full node for data, or run a full node.

The Light Ethereum Subprotocol (LES) is practically not supported (due to lack of incentives and non-trivial requirements), and fewer full nodes will make similar protocols even less feasable. So the only reliable way to access Ethereum state (in censorship resistant and private way) will be to run a full node. But with L1 scaling that we plan to achieve, hardware and bandwidth requirements to run a full node will go up, making it less of an option for average person.

Currently proposed solutions

The earliest solution that helps with some of these issues is VOPS (Validity-Only Partial Statelessness), where each node stores only account trie (or only leaves of the account trie). While sufficient for non-Native AA transactions, supporting Native AA requires extending it to “VOPS-like” solutions that include additional data - either the data that a specific node cares about (unclear how easy it would be to sync this data the first time) and / or some small subset of data that all nodes store (e.g. first few slots of every account).

In order for VOPS-like to be used for mempool / FOCIL, we would have to restrict what Native AA tx can do during validation even more than current Frame Tx mempool restrictions (i.e. Frame Tx can call any smart contract and access any sender’s storage slot, which VOPS-like doesn’t support). This limits the usefulness of Native AA / FOCIL features.

Probably more importantly is that VOPS-like solutions don’t help with self-sovereign access! Users can’t query balances (beyond ETH) or create transactions (as gas estimation requires executing the full transaction).

To my knowledge, there is no concrete solution for the self-sovereign access and full node synching. They are either considered not big enough problems, or rely on centralized entities (with enough centralized providers, one can design client where small bits of information is fetched from multiple sources, which gives some level of censorship resistance and privacy).

Additionally, VOPS-like solutions are being adjusted to fit all currently known use cases (e.g. adjusting what Frame Tx can do during validation, private mempool, etc.). What about use cases that arise in the future? Where does a VOPS-like client get the data that it needs but doesn’t have?

Decentralized State

Decentralized State (DS) proposes distributing the entire recent head state (sufficient to handle re-orgs, e.g. since the last finalized checkpoint) across nodes participating in the mempool, FOCIL, or even wider set. Since Stateless validators already face non-trivial disk requirements (see above), contributing additional storage to the DS protocol should be manageable.

Under DS, each node stores a protocol-assigned portion of the state (with proof), ensuring even distribution across the network. This data should always be up-to-date with the head of the chain, and it should be easy to find nodes that store state that we are interested in.

Nodes would additionally store data most relevant to their specific needs (local cache).

Mempool and FOCIL nodes

In order to efficiently validate transactions (including Native AA transactions), nodes can also store minimal state needed to validate all transactions from all blocks from the last X months. The X should be big enough to cover 90-95% of incoming transactions. The remaining 5-10% should be processed by fetching data from the DS protocol.

This can be optimized even further: the first node that validates the transaction can propagate the state needed for validation (with proof). Alternatively, a node can obtain the state needed for validation from a peer that sent the transaction.

Notice that this is similar to VOPS-like design, but instead of trying to limit the state needed for validation, we can fetch it from the network on demand. Introduced latency should be small enough and it should be tolerable if it affects a small percentage of transactions.

Self-sovereign access

Users that care about self-sovereign access can, on top of their dedicated DS share, store data that they care about the most (e.g. their balances). The rest of the data would still be available to them, but with some added latency.

DS enables users to create transactions and propagate them with the necessary validation state included. This is achieved in a censorship resistant and private manner.

Full-node synching

By spreading the state across the network, full nodes can sync the head state quickly and reliably by fetching data in parallel from multiple peers.

New State structure

The current state structure, Merkle Patricia Trie (MPT), is not very friendly for Stateless Proofs, zkEVM and other improvements. When designing a new state structure we have to consider all of these and other aspects: performance, post-quantum, etc.

DS should also be considered, as not every state structure is equally friendly to DS designs. The main challenges are ensuring even state distribution across peers and efficiently proving parts of the state. Here is how friendly some state designs are to DS:

  • Verkle Tree EIP-6800 is very friendly to evenly distributing state across peers, but high n-ary causes some inefficiency in storing internal trie nodes.
  • Unified Binary Tree (UBT) EIP-7864 is extremely friendly for DS design in all main aspects
  • Partitioned Binary Tree, as specified in EIP-8297 at the moment of writing, is not very DS friendly. Storage trie of every account is contained in a single sub-tree. This makes storage partition/subtree hard to evenly distribute across DS peers.
    • However, some adjustments can make it more DS friendly. We can keep account headers, contract code and contract storage partitioned, but unify all storage trees into one subtree (similar to UBT). While this is friendly to DS, it has a trade-off that it’s hard to keep track of all storage slots for a specific contract (same as UBT).

DS and VOPS-like approach

Decentralized State and VOPS-like are not competing designs. Even if VOPS-like is considered a minimal solution that nodes need to support, it can be done together with DS. Nodes that want to support minimal spec would be VOPS-like only nodes, while DS-VOPS hybrids would support a wider set of use cases.

Conclusions

Decentralized State offers a solution to many of the hurdles Ethereum will face as Stateless clients become standard. To get the most effective solution, it would be best if DS is considered a core part of the protocol, or at least part of some core components, e.g. Mempool / FOCIL.

Additional research is needed on how it should interact with all parts of the protocol (mempool, FOCIL, node synching, wallets, etc.), what is best design for new state trie structure, how DS nodes keep their state up-to-date, how content is distributed and discovered on the network, etc.

We first have to figure out the main use cases that DS should support and exact properties that we want, and then consider how we can reuse some of the existing tech (e.g. Portal Network, PeerDAS).

1 Like