snap/2 is a draft RLPx capability for state synchronization after block
access lists become available. It keeps the range and bytecode messages from
snap/1. It removes trie-node healing and uses verified block access lists to
move downloaded state between pivot blocks.
This page describes a proposal. It does not claim client support or deployment.
Wire inventory
Messages 0x00 through 0x05 have the same payload and behavior as
snap/1. IDs 0x06 and 0x07 remain reserved and have no
messages in snap/2.
| ID | Message | Payload |
|---|---|---|
0x00 |
GetAccountRange |
snap/1 account-range request |
0x01 |
AccountRange |
snap/1 account-range response |
0x02 |
GetStorageRanges |
snap/1 storage-range request |
0x03 |
StorageRanges |
snap/1 storage-range response |
0x04 |
GetByteCodes |
snap/1 code request |
0x05 |
ByteCodes |
snap/1 code response |
0x08 |
GetBlockAccessLists |
[request_id, block_hashes, response_bytes] |
0x09 |
BlockAccessLists |
[request_id, block_access_lists] |
GetBlockAccessLists requests access lists by block hash. response_bytes is
a soft limit for the whole response.
BlockAccessLists returns entries in request order. The RLP empty string marks
an unavailable item. A server may omit a response suffix to meet its limit.
Synchronization process
The client selects a recent pivot and downloads account ranges, storage ranges, and code at that state root. When the chain advances, it requests each access list between the old and new pivots. It checks each list against the hash in the matching block header, applies the changes in chain order, and continues at the new pivot.
For a reorganization behind the pivot, the client gets orphaned access lists back to the common ancestor. It deletes values changed only on the old branch, fetches those values again, then applies access lists on the new branch. If the needed orphaned lists are not available, it discards the partial state and starts again.
Validation and failure handling
- A server always responds. It uses
0x80for each unavailable list. - Returned items keep request order. A server may remove only a suffix.
- The receiver computes
keccak256(rlp.encode(access_list))and requires a match with the header commitment. - The receiver applies lists in block order.
- A server should keep canonical and orphaned lists for the EIP-7928 retention window, and should serve snapshot ranges for at least the most recent 128 blocks.
- Servers should rate-limit large requests. The default response soft limit is 2 MiB when the requester gives no limit.
Design rationale
The blocks between two pivots form a known, finite set. Their access lists can repair state in a bounded number of requests. This removes the repeated search for missing trie nodes.
History
EIP-8189 defines snap/2 as a draft successor to snap/1. Both capability
versions can coexist during rollout.