This EIP extends EIP-7928 by attaching the post-block storage trie root to every Block Access List (BAL) entry that records state modifications. Partially stateful nodes can then verify the post-block state root without holding the full storage tries of modified accounts.
Motivation
A BAL exposes per-slot post-values but not the post-block storage trie root of each modified account. A node that holds only a partition of the state therefore cannot derive the storage root for a modified account it does not store, and so cannot reconstruct the state-trie leaf needed to verify the post-block state root.
Including the post-block storage root for every modified account closes this gap. Combined with the balance, nonce, and code information already present in the BAL, any node can assemble the full state-trie leaf for every modified account regardless of which portion of state it retains.
It is painful to populate the canonical empty MPT root, 0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421, in the BAL for every mutated account.
The majority of mutated accounts are EOAs with either balance changes, such as transfer recipients, or nonce changes, such as transaction senders. These accounts do not have any storage slots. When the post-transaction storage is empty (it’s empty, or all the storages have been wiped), we can use an empty slice as the replacement.
In RLP encoding, the empty slice is encoded as 0x80, which can be easily distinguished from any valid string.
Hmm that’s a good point. Here I should specify that this only affects to accounts whose STORAGE is not-null.
I’d say that we can just check that codesize != null or something alongisde this. On this way, we get the updates only for contracts instead of the account ones which I agree are useless.
State replication & geographical distribution (helps snap-syncing other nodes)
New RPC-network-provider models. Store what you want, announce the ranges you hold and get queried and payed for it.
Running dapp-specific RPCs
Run FOCIL includer nodes
I feel these will be the new “Full nodes” once ZKEVMs arrive to mainnet. Won’t make sense to run a full node at all.
You have a fully-working impl capable of syncin both mainnet and bal-devnet-7 and keep following the tip of the chain(in the case of the latter, mainnet doesn’t have BALs so we can’t yet do this).