Updated **It is a very interesting time to discuss and practice stateless Ethereum at least in the Account level for now. Vitalk Buterin has an attractive proposal on the statelessness roadmap and Dankrad feist released a strong writing on Verkle trie for Eth1 state.
**

I personally am extremely excited about the Statelessness and feasible ways to implement a practical step toward this goal through the concept of stateless Account abstraction model for now and looking very forward to the next potential milestones and whether we would see further Stateless implementation in  Eth1 and Eth2.

I posted a blurb about the concept of Stateless Account abstraction on Ethresearch earlier. I believe stateless verification in blockchain systems introduces a range of possibilities.

For instance,As vitalik tweeted, a light node can be designed to fully verify specific blocks by prioritizing them based on the total quantity of deposited stake held by nodes that submit alert messages about those blocks. This selective verification process allows light nodes to conserve computational resources by focusing on potentially malicious or invalid blocks. In addition to stake-based selection and alert messages, stateless account abstraction (AA) brings further advantages. One notable benefit is client-side validation, where the verification process can be partially offloaded to clients. This reduces the amount of redundant computation performed by the network, as clients can independently validate certain aspects of transactions or blocks.

Furthermore, client-side caching is facilitated by stateless AA. Clients can store and reuse verified results, such as transaction outputs or contract states, allowing for faster processing of subsequent transactions. By minimizing redundant computations and leveraging cached data, transaction processing times can be significantly improved.

To continue the thread, I would like to share some insights and discuss some essential security questions raised in the context of Replay protection, witness Update, and DOS Attacks in Xtreamly’s proposed model. I want to express my gratitude to Yoav Weis for considering our proposal and asking insightful questions about it with his sane insights.

“UserOp.signature in 4337 is essentially a witness. It can be a signature over the UserOp to prove its validity against a currently valid key. But it could also be something totally different, e.g. a ZK proof of membership.  Technically you could have an account with no possibility of key rotation, and then the signature check would be stateless (like with an EOA).  But even then, the operation is not really stateless because replay protection needs to update some form of nonce.”

How do we solve replay protection while remaining stateless?

In order to mitigate transaction replay attacks within our stateless system, which bears resemblance to stateless cryptocurrencies, we introduce the concept of "state" as a vector denoted by v = (vi)i∈[0,n) with a size of n. This vector maps user i to vi = (addri |bali) ∈ Zp, where addri represents the user's address and bali represents their balance. However, to accommodate the inclusion of ci, the transaction counter for each user, we modify the mapping to vi = (addri |ci |bali).

It is important to note that this modification is straightforward, yet it reduces the available space for addri depending on the bit requirements of ci and bali. Typically, vi ∈ Zp occupies approximately 256 bits. To address this limitation, we propose employing two additional Accumulator-Based Sparse Vector Commitments (aSVCs). One aSVC is responsible for mapping i to addri, while the other aSVC maps i to (ci |bali).

Our key insight lies in utilizing distinct n-SDH parameters, such as (g τ i ) and (h τ i ), in the two aSVCs, where the logarithm of g to the base h is unknown. By doing so, we can aggregate commitments, proofs, and update keys in a manner that introduces zero computational and communication overhead within our stateless Atomic Action (AA) framework.

In the context of enabling statelessness, the local validation state can be represented by a short cryptographic commitment. This commitment contains the necessary information to validate transactions without relying on a persistent or global state. It provides a snapshot or summary of the required validation data, such as account balances or other relevant information.

the elimination of nonces in a stateless AA scheme by using a session-based protocol and commitment verification does not guarantee that a transaction will remain valid forever, especially if the global state is updated. If the global state change affects the conditions or requirements for the transaction to remain valid, the transaction may no longer be considered valid according to the updated rules.

“Similarly, it may be challenging to update the implementation of the account if it's stateless.  E.g. transition from a simple multisig to an account with social recovery, while retaining the same address.  This is typically handled using a proxy pattern, but a proxy implies having an implementation slot in storage, which wouldn't be stateless.

At a more general level, if you produce a witness that doesn't depend on the state, then the same transaction remains valid forever, regardless of changes to the account, replay, etc.  And if the witness does depend on the state somehow (e.g. a witness on the state at a certain block), then you still need to solve the problem of DoS through mass invalidations.  A single state change could invalidate O(n) witnesses after the nodes already spent O(n) CPU cycles processing them when they were added to the mempool.”

How do we prevent DOS attacks in our model?

We could simply use multiple bounded aSVCs together with cross-commitment proof aggregation, which aSVC we leveraged as core scheme supports [GRWZ20].

In the end, it’s important to note, the proposal is still in the R&D phase and our initial work is focused on the Geth client. We’ll provide more data and public source code accordingly.