Nimbus Stateless Roadmap

[bhartnett]

Here is a roadmap for implementing statelessness in Nimbus.

Short term

Create a merkle (partly) stateless client:

• This would be similar to Ress (the Reth stateless client).
• It works by sharing the block witnesses and separate bytecode over a custom RLPx sub protocol (currently only supported by Reth).
• We could pair implement the same subprotocol and pair with the Reth nodes.
• It would require making Nimbus support running in a stateless configuration where it would peer with Reth and/or Nimbus full nodes to fetch the block witness data and bytecode on demand.
• Nimbus full nodes will also be updated to store the block witnesses and code for the full history. Not an archive node but would be storing more data than a regular full node. Perhaps this can be disabled by default.

Medium term

Create a light full node which has all the state but excluding the merkle branches:

• Stores the state values only.
• Doesn't have any merkle branches stored locally so is not able implement eth_getProof RPC for example.
• Having this depends on having a stateless client implemented.
• Either merkle, binary or zk stateless client can support his idea.
• Should decrease storage cost by approx 2x (according to Vitalik).

Create a binary tries stateless client:

• Would need to create a new binary tries library for this.
• Vitalik suggested that this change is useful even when moving to zkvms because binary tries which will use a more optimal hash function such as Poseidon will improve prover efficiency.

Longer term

Create a zk stateless client which uses a zkvm:

• Still being specked out with the ethproofs.org work.

Create a partially stateless node:

• Uses stateless verification and builds on top of a stateless client.
• The node stores a subset of the state (without merkle branches).
• The state selected to be stored could be configured by the node operator or configured in a system smart contract.
• This ideas was suggested by Vitalik in an eth research post.

Prior Stateless Work

Prior work in Nimbus implemented both generation and verification of block witnesses based on the specs here: https://github.com/ethereum/portal-network-specs/blob/01a49a8c9bf08121ecde1b9270a6f2f679cb2568/witness.md

A backup of the stateless code is in this branch for future reference: https://github.com/status-im/nimbus-eth1/tree/stateless-backup. At some point we may want to re-enable these features.

The AccountCache / AccountLedger holds a data structure called the WitnessCache which records every touched account and storage slot for each block. After executing a block of transactions the code supports getting the keys and building a block witness from these keys.

The idea is that these generated witnesses would be shared by block producers and used by stateless clients in order to verify blocks without having to store the state locally.

[bhartnett]

Here is the PR which removed this code for the time being: #2295

[bhartnett]

Issue created for the merkle stateless client task here.

[kevaundray]

Still going over the design space, but its likely that the EL will not need to do the networking/client work like ress does and instead it would be done on the CL side -- here is a rough proof of concept: sigp/lighthouse#7755

[bhartnett]

Still going over the design space, but its likely that the EL will not need to do the networking/client work like ress does and instead it would be done on the CL side -- here is a rough proof of concept: sigp/lighthouse#7755

Yes I agree that the Ress RLPx sub-protocol won't be needed/used in protocol for Ethereum but we may end up implementing it or something similar just to get our proof of concept fully working. This project is just the first step before we update it to implement binary tries and then later the zk-stateless work.

Makes sense that the CL could do the proof verification without an EL however something to keep in mind is that it will be valuable for the EL to have access to the proofs and state diffs so that we can implement light RPC full nodes which can provide trustless access to the state without having to depend on a third party RPC provider. Vitalik mentioned the idea of extending a stateless EL client to store the full (or partial) state without storing the merkle branches which should provider a x2 (or greater) storage reduction (see here). In order for the stateless EL client to follow the chain and update its copy of the state it should verify these proofs and then update its state using the proven state diffs.

[kevaundray]

Yep I agree that for partially stateless nodes, a new type of EL will need to be able to fetch the proofs.

For that, we could use the engine_api, this should be okay since even a partially stateless node would need to have a CL attached anyways.

For binary trees, makes sense to implement, we are currently running benchmarks on the MPT to see if/when we need to switch to binary trie

[bhartnett]

Yep I agree that for partially stateless nodes, a new type of EL will need to be able to fetch the proofs.

For that, we could use the engine_api, this should be okay since even a partially stateless node would need to have a CL attached anyways.

For binary trees, makes sense to implement, we are currently running benchmarks on the MPT to see if/when we need to switch to binary trie

Yeah that could work and actually if the CL verifies the proofs then the light EL could simply apply the state diffs from the CL assuming the engine API is updated to support this use case.