this work is still under R&D

The concept of stateless Ethereum opens up possibilities for building a client that can execute blocks in a stateless manner, along with the notion of Stateless Account Abstraction. In a stateless account abstraction, the mempool is separated from the account state, effectively isolating the state from validation and execution logic. Users can participate in the mempool without explicitly providing state information. Instead, their transactions can be verified based on other criteria such as cryptographic proofs and witnesses.

However, proposals like Verkle trie suggest storing the state root in clients instead of the clients holding the state. While this may be beneficial for stateless cryptocurrencies, it doesn’t fully address the problem of witness size and smart contract execution in a stateless setting concerning storing and verifying the contract state. Supporting smart contracts in a stateless setting presents two main challenges related to storing and verifying the contract state.

In the context of smart contracts, the proper execution of contract code relies on the current state of the contract, especially when it involves fund movement. For Alice to initiate a transaction that triggers a contract, she must provide proof validating the accuracy of the existing contract state. Stateless nodes require this proof for execution. This scenario poses two significant challenges. Firstly, we need to determine who is responsible for storing the contract state since any client can submit transactions that trigger contract executions. Secondly, we must find a solution to avoid including the entire contract state within the transaction itself, as the state could be excessively large.

Introducing Xtreamly, the revolutionary proposal for Stateless Account Abstraction, which doesn’t require altering the consensus-layer protocol. In this stateless account abstraction model, the state is separated from validation and execution logic. Users can participate in the mempool without providing explicit state information. Transactions can be verified based on cryptographic proofs and witnesses. By separating the state from the execution logic, clients or nodes can process transactions without storing or maintaining a local copy of the entire blockchain’s state. The necessary state information is provided through witnesses and cryptographic proofs, enabling lightweight and scalable transaction validation and execution.

In our proposed stateless account abstraction model, account state information is generated on-demand using cryptographic proofs. This on-demand generation enhances block verification and synchronization, contributing to improved network performance. Instead of storing the entire account state on the blockchain, the account state can be dynamically computed when needed, rather than being directly stored on the blockchain. When a transaction triggers a contract execution, the user can provide proof validating the correctness of the current contract state. This approach offers greater flexibility and customization by abstracting away the implementation details of underlying account models. Developers can create new account types with tailored functionality and behavior, fostering innovation within the Ethereum ecosystem.

A notable aspect of our stateless account abstraction model is the flexibility it provides in customizing the signature verification logic within cryptographic proofs. This customization can be achieved without significant modifications to the fundamental infrastructure and consensus mechanisms of Ethereum. By focusing on the cryptographic proof generation and verification process, alternative signature schemes can be seamlessly integrated, expanding the possibilities for secure and efficient transaction validation.

In our proposed model, nodes only store the necessary information to validate transactions, eliminating the need to maintain the entire blockchain state. Our Stateless Light client builds upon this concept, allowing clients to interact with the blockchain without storing the complete state or participating in full consensus. Miners and clients no longer need to store the full ledger state. Instead, the state, which includes users’ account balances, is distributed among all users using an authenticated data structure. Miners store a concise digest of the ledger state, while each user maintains their account balance. Transaction validation includes proofs of sufficient balance from users.

Our main idea is to use an aggregatable subvector commitment (aSVC) proposed by Alin Tomescu et al. to store the state root and associated proofs in a compact manner for stateless verification. Instead of including the state root directly in each block, it can be replaced with the commitment, with the associated Proving Key and Verification Key provided. By utilizing an aSVC for storing the state root and associated proofs, the storage requirements for each block can be reduced, as only the commitment and keys need to be included. This approach improves the efficiency of stateless verification by providing a compact representation of the necessary information for validation. Verifiers can efficiently validate the inclusion or non-inclusion of transactions within a block during the verification process using the aSVC and the associated Verification Key.

Challenge (i): Who stores the contract state?
By using ASVC, the contract state can be stored and maintained by the stateless client itself. The client stores commitments or cryptographic hashes of the state instead of the entire state. This reduces the burden of storing the contract state on any specific entity and allows the client to independently validate the state correctness using aSVC-based proofs.

Challenge (ii): Avoiding inclusion of the contract state in transactions
With the use of aSVC, the contract state doesn’t need to be directly included in the transaction. Instead, the transaction can include a reference to the commitment or cryptographic hash of the state. This reference serves as a concise representation of the state without the need to transmit the entire state, which could be too large. Stateless nodes can use the reference and aSVC-based proofs to verify the correctness of the state during contract execution.

By leveraging aSVC in a stateless client, these challenges can be effectively addressed. The client can securely store and validate the contract state without relying on external entities. Additionally, the use of aSVC allows for efficient referencing and verification of the contract state without the need for its inclusion in the transaction.