The Ethereum state is a data structure that stores all account balances, smart contract codes, and storage contents on the blockchain. As the blockchain grows in size, the state data also grows, and it becomes increasingly challenging for nodes to store and access the data.
As the Ethereum network grows, so too does the amount of data that it needs to store and process. This data takes many forms, including the account balances of individual users, the code and data of smart contracts, and the history of transactions that have taken place on the network.
While this data is essential for the network to function, it also presents a significant challenge in terms of storage and processing requirements.
When discussing Statelessness in the context of Ethereum, it’s important to consider it at two levels: the protocol layer and its interaction with Account Abstraction.
At the protocol layer, Statelessness refers to the ability to validate blocks without relying on any state information. Instead, full witnesses, such as Merkle proofs, are included in blocks, allowing nodes to validate transactions without storing any state. This would make the Ethereum network more lightweight and less reliant on centralized service providers.
However, implementing Statelessness at the protocol layer alone would not be enough to fully realize its benefits. That’s where Account Abstraction comes in. Account Abstraction is a proposed upgrade to the Ethereum network that would allow for more complex transactions, such as those involving multiple contracts or smart contracts interacting with other blockchains.
By implementing Statelessness in conjunction with Account Abstraction, Ethereum users would be able to interact with the blockchain without needing to store a large amount of state information locally. This would make the network more accessible, scalable, and decentralized.
Let's first start off with the Protocol level:
In Ethereum’s current stateful model, every node on the network needs to store a copy of the entire blockchain state, which includes information about all the user accounts, their balances, and the smart contracts they interact with. This makes the network slow and resource-intensive, as each node needs to process and store a large amount of data.
Storing the state on slow permanent storage is impractical, and it can lead to centralization as only a few nodes can afford to run full nodes with expensive solid-state drives, or SSDs. Additionally, the cost of state growth is another significant problem as it increases the cost of running a node and impacts the network’s performance and scalability.
Importance of Statelessness in Ethereum protocol level:
Addressing concerns of centralization and pushing the industry towards true decentralization requires solutions like state rent and statelessness in the blockchain space. Moxie Marlinspike pointed out that relying on third-party providers like Infura and Alchemy to interact with the blockchain creates a central point of failure. On the other hand, Vitalik Buterin has been exploring the concept of Stateless Ethereum since 2017. full statelessness unlocks a tremendous potential that any amount of partial statelessness cannot. Partial statelessness and state rent are similar in that they both require some form of payment for introducing something into an active state and a witness to reactivate a state that has become inactive. This would eliminate reliance on centralized service providers and allow users to access the chain locally, even in situations where they are being blacklisted.
Currently, all validators have to run the full Eth1 execution at all times, which is not feasible for a shard where only a committee needs to sign a block. This is because only a small portion of validators need to sign the block, and the rest only need to trust that there is at least one honest member of the committee. To achieve this, the load on all validators needs to be roughly equal, and sending a validator to become an Eth1 committee member for a long time is not ideal as it can lead to extreme peaks and make committees more vulnerable to attacks. In addition, easy fraud proofs for Eth1 blocks are necessary to ensure the committee has done its work correctly, and this is only possible if Eth1 becomes fully stateless.
So far, Two primary ideas have crystallized: state rent and statelessness. State rent proposes that in order to keep a state element in active memory, a continuous payment is required. Statelessness, on the other hand, allows blocks to come with full witnesses, eliminating the need for the state to validate whether a block is valid.
However, there are further ideas worth exploring on the spectrum of statelessness. Partial statelessness involves reducing the amount of states required to validate blocks by requiring witnesses only for some older states. Weak statelessness validates blocks without requiring a state, but proposing blocks still necessitates the full state.
Statelessness in Account Abstraction level:
The stateless account abstraction proposed by Xtreamly is a novel paradigm for Ethereum without the need to change in current Ethereum consensus mechanism in which the system operates in a stateless manner without retaining any historical information about a user’s state. Generally, the underlying smart contract defines the conditions that need to be satisfied without relying on an external state or having any side effects. Each interaction is self-contained and not influenced by the server’s previous state, relying only on the data available at that moment.
each client request must carry all required information, including authentication keys, for the server to perform and respond to the request. Stateless protocols treat each action as a standalone event. This ensures that the conditions for executing the transaction remain the same and eliminates the risk of changing validity.
As a result, each client request must contain all necessary information, including authentication keys, for the server to execute and respond to the request. Stateless protocols consider each action as an independent event, ensuring that the transaction’s execution conditions remain the same, thus eliminating the risk of changing validity.
Our approach for stateless Account abstraction for Ethereum as an account based blockchain, has significant implications providing a new way to design and implement secure and scalable systems. The removal of historical state information from the system reduces the storage requirements and enhances the performance of the network. Furthermore, the stateless paradigm promotes interoperability and composability, enabling the creation of new, more complex applications that can be composed of smaller, self-contained smart contracts.
Recall in Account- based systems the miners maintain a database with balances and transaction validity is checked against this database (instead of UTXO). To implement Stateless Account abstraction in the account-based model, we propose a framework that allows for stateless Account abstraction based on the UTXO model with efficient Proof synchronization, block commitment, and scalable and cheap verification method based on zk-snark on Ethereum.
In the account model, nodes keep track of a vector containing the balances of all accounts to validate transactions. When Alice wants to send δ tokens to Bob, she sends a transaction that contains this information. Using Merkle trees to provide stateless validation in the account model may seem like a viable option. However, there is a fundamental issue with this approach. For example, if Alice wants to send 5 tokens to Bob and has a balance of vA ≥ 5, Alice would need to include a Merkle tree proof of her current balance in her transaction. This proof alone is insufficient to update Bob’s balance to vB + 5 unless Alice also includes Bob’s local proof in her transaction, which is not feasible in a cryptocurrency system. Instead, Alice should be able to send money to Bob through a fixed public address.
Xtreamly has developed a unique approach to address a problem using a Distributed vector commitment scheme that improves the proof size and verification time. Unlike other vector commitment schemes, such as Merkle trees and accumulator-based vector commitments, our approach is state-independent and offers improved performance. Our proposed scheme is asymptotically better than the lattice scheme and comparable to the RSA scheme. In practice, our proof size is less than 0.15KB for l ≤ 32, while the lattice scheme has a proof size of 62–78KB, and the RSA scheme has a proof size of 0.256 KB.
Our UpdateProof algorithm is a key feature of our approach, as it allows for a fixed update key for an index i, which can be used to update all proofs πj, regardless of the index j. This is in contrast to other constructions, such as the RSA-based construction of Calalano and Fiore and the recent one by Lai and Malavolta, which require a different update key for each combination of i and j. This can be cumbersome in stateless validation applications, as parties would have to include a large number of update keys for each transaction, making it difficult to update proofs efficiently. Our fixed key approach enables logarithmic computation time for synchronizing local proofs, making it a more efficient solution.
Stay tuned for more articles on our innovative approach that allows for more efficient Stateless Ethereum.
