From 9217ad821cbce5a18b220cdff90949106cf8372e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toni=20Wahrst=C3=A4tter?= Date: Thu, 12 Feb 2026 08:10:42 +0100 Subject: [PATCH 1/9] Add EIP: eth/71 --- EIPS/eip-xxxx.md | 130 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 EIPS/eip-xxxx.md diff --git a/EIPS/eip-xxxx.md b/EIPS/eip-xxxx.md new file mode 100644 index 00000000000000..7927daa6910ea5 --- /dev/null +++ b/EIPS/eip-xxxx.md @@ -0,0 +1,130 @@ +--- +eip: XXXX +title: eth/71 - Block Access List Exchange +description: Adds peer-to-peer exchange of block-level access lists to the eth protocol +author: Toni Wahrstätter (@nerolation) +discussions-to: https://ethereum-magicians.org/t/eip-xxxx-eth-71-block-access-list-exchange/27725 +status: Draft +type: Standards Track +category: Networking +created: 2026-02-12 +requires: 7928 +--- + +## Abstract + +This EIP modifies the 'eth' p2p protocol to support block-level access list (BAL) exchange. It adds two new messages, `GetBlockAccessLists` (0x12) and `BlockAccessLists` (0x13), enabling peers to request and serve BALs for synchronization and parallel execution. + +## Motivation + +[EIP-7928](./eip-7928.md) introduces block-level access lists that record all state locations accessed during block execution. These lists enable parallel disk reads, parallel transaction execution, and executionless state updates. + +For syncing clients to leverage these capabilities, BALs must be obtainable from peers. The Engine API provides BALs from the consensus layer during normal operation, but historical BALs and peer-based sync require wire protocol support. + +## Specification + +### Block Header Extension + +The block header is extended with a new field after `requests-hash`: + +``` +block-header = [ + ... + requests-hash: B_32, + block-access-list-hash: B_32, +] +``` + +The `block-access-list-hash` field contains `keccak256(rlp.encode(block_access_list))` as defined in [EIP-7928](./eip-7928.md). This field MUST be present in headers after the Amsterdam fork and absent for earlier blocks. + +### Block Access List Encoding + +BALs are RLP-encoded as a list of account changes, sorted lexicographically by address: + +``` +block-access-list = [account-changes₁, account-changes₂, ...] + +account-changes = [ + address: B_20, + storage-changes: [[slot: B_32, [[block-access-index: P, value: B_32], ...]], ...], + storage-reads: [slot₁: B_32, slot₂: B_32, ...], + balance-changes: [[block-access-index: P, balance: P], ...], + nonce-changes: [[block-access-index: P, nonce: P], ...], + code-changes: [[block-access-index: P, code: B], ...], +] +``` + +Where `block-access-index` indicates when the change occurred: +- `0` for pre-execution system contract calls +- `1...n` for transactions (in block order) +- `n+1` for post-execution system contract calls and withdrawals + +See [EIP-7928](./eip-7928.md) for complete BAL generation rules and inclusion semantics. + +### New Protocol Messages + +#### GetBlockAccessLists (0x12) + +``` +[request-id: P, [blockhash₁: B_32, blockhash₂: B_32, ...]] +``` + +Request BALs for the given block hashes. The number of BALs that can be requested in a single message is subject to implementation-defined limits. + +BALs are only available for blocks after [EIP-7928](./eip-7928.md) activation and within the weak subjectivity period (~3533 epochs). Requests for unavailable BALs return empty entries. + +#### BlockAccessLists (0x13) + +``` +[request-id: P, [block-access-list₁, block-access-list₂, ...]] +``` + +Response to `GetBlockAccessLists`. Each element corresponds to a block hash from the request, in order. Empty BALs (RLP-encoded empty list `0xc0`) are returned for blocks where the BAL is unavailable. + +The recommended soft limit for `BlockAccessLists` responses is 10 MiB. + +### Validation + +When a BAL is received, clients MUST validate it by computing `keccak256(rlp.encode(bal))` and comparing against the `block-access-list-hash` in the corresponding block header. + +## Rationale + +### Separate Messages vs. Block Body Extension + +BALs are transmitted via dedicated messages rather than extending block bodies because: + +1. **Size**: BALs average ~70 KiB, significantly increasing block propagation overhead if bundled. +2. **Optional retrieval**: Not all sync strategies require BALs. Snap sync can reconstruct state without them. +3. **Retention policy**: BALs may be pruned after the weak subjectivity period, while block bodies are retained longer. + +### Message IDs + +Message IDs 0x12 and 0x13 follow sequentially from the existing eth/69 messages (BlockRangeUpdate is 0x11). + +### Response Size Limit + +The 10 MiB soft limit aligns with existing protocol conventions and accommodates multiple BALs per response while remaining within typical message size constraints. + +## Backwards Compatibility + +This EIP changes the eth protocol and requires rolling out a new version, eth/71. Supporting multiple protocol versions is standard practice. Rolling out eth/71 does not break older clients, as they can continue using eth/69 or eth/70. + +This EIP requires the Amsterdam hard fork for the header field extension. The new messages are only meaningful for post-Amsterdam blocks. + +## Security Considerations + +### Validation Cost + +BAL validation requires computing a keccak256 hash of the RLP-encoded list. For typical BALs (~70 KiB), this is negligible. For worst-case BALs at high gas limits, validation remains bounded by the block gas limit. + +### Amplification + +A `GetBlockAccessLists` request can trigger responses larger than the request. Implementations SHOULD apply rate limiting and respect the soft response size limit to prevent amplification attacks. + +### Unavailable Data + +Clients MUST handle empty responses gracefully. A peer returning empty entries for available blocks may be misbehaving but could also have pruned the data legitimately. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From ae868e001ee230d9e8f3b370f69afb14699e061e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toni=20Wahrst=C3=A4tter?= <51536394+nerolation@users.noreply.github.com> Date: Thu, 12 Feb 2026 08:51:46 +0100 Subject: [PATCH 2/9] Update EIPS/eip-8519.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- EIPS/eip-xxxx.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-xxxx.md b/EIPS/eip-xxxx.md index 7927daa6910ea5..c6562fada7bf38 100644 --- a/EIPS/eip-xxxx.md +++ b/EIPS/eip-xxxx.md @@ -1,5 +1,5 @@ --- -eip: XXXX +eip: 8159 title: eth/71 - Block Access List Exchange description: Adds peer-to-peer exchange of block-level access lists to the eth protocol author: Toni Wahrstätter (@nerolation) From 8fc2531a72666f0c45f67c4dd9c215f6f7a4d784 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toni=20Wahrst=C3=A4tter?= Date: Thu, 12 Feb 2026 08:53:38 +0100 Subject: [PATCH 3/9] rename eip file --- EIPS/eip-8159.md | 130 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 EIPS/eip-8159.md diff --git a/EIPS/eip-8159.md b/EIPS/eip-8159.md new file mode 100644 index 00000000000000..7927daa6910ea5 --- /dev/null +++ b/EIPS/eip-8159.md @@ -0,0 +1,130 @@ +--- +eip: XXXX +title: eth/71 - Block Access List Exchange +description: Adds peer-to-peer exchange of block-level access lists to the eth protocol +author: Toni Wahrstätter (@nerolation) +discussions-to: https://ethereum-magicians.org/t/eip-xxxx-eth-71-block-access-list-exchange/27725 +status: Draft +type: Standards Track +category: Networking +created: 2026-02-12 +requires: 7928 +--- + +## Abstract + +This EIP modifies the 'eth' p2p protocol to support block-level access list (BAL) exchange. It adds two new messages, `GetBlockAccessLists` (0x12) and `BlockAccessLists` (0x13), enabling peers to request and serve BALs for synchronization and parallel execution. + +## Motivation + +[EIP-7928](./eip-7928.md) introduces block-level access lists that record all state locations accessed during block execution. These lists enable parallel disk reads, parallel transaction execution, and executionless state updates. + +For syncing clients to leverage these capabilities, BALs must be obtainable from peers. The Engine API provides BALs from the consensus layer during normal operation, but historical BALs and peer-based sync require wire protocol support. + +## Specification + +### Block Header Extension + +The block header is extended with a new field after `requests-hash`: + +``` +block-header = [ + ... + requests-hash: B_32, + block-access-list-hash: B_32, +] +``` + +The `block-access-list-hash` field contains `keccak256(rlp.encode(block_access_list))` as defined in [EIP-7928](./eip-7928.md). This field MUST be present in headers after the Amsterdam fork and absent for earlier blocks. + +### Block Access List Encoding + +BALs are RLP-encoded as a list of account changes, sorted lexicographically by address: + +``` +block-access-list = [account-changes₁, account-changes₂, ...] + +account-changes = [ + address: B_20, + storage-changes: [[slot: B_32, [[block-access-index: P, value: B_32], ...]], ...], + storage-reads: [slot₁: B_32, slot₂: B_32, ...], + balance-changes: [[block-access-index: P, balance: P], ...], + nonce-changes: [[block-access-index: P, nonce: P], ...], + code-changes: [[block-access-index: P, code: B], ...], +] +``` + +Where `block-access-index` indicates when the change occurred: +- `0` for pre-execution system contract calls +- `1...n` for transactions (in block order) +- `n+1` for post-execution system contract calls and withdrawals + +See [EIP-7928](./eip-7928.md) for complete BAL generation rules and inclusion semantics. + +### New Protocol Messages + +#### GetBlockAccessLists (0x12) + +``` +[request-id: P, [blockhash₁: B_32, blockhash₂: B_32, ...]] +``` + +Request BALs for the given block hashes. The number of BALs that can be requested in a single message is subject to implementation-defined limits. + +BALs are only available for blocks after [EIP-7928](./eip-7928.md) activation and within the weak subjectivity period (~3533 epochs). Requests for unavailable BALs return empty entries. + +#### BlockAccessLists (0x13) + +``` +[request-id: P, [block-access-list₁, block-access-list₂, ...]] +``` + +Response to `GetBlockAccessLists`. Each element corresponds to a block hash from the request, in order. Empty BALs (RLP-encoded empty list `0xc0`) are returned for blocks where the BAL is unavailable. + +The recommended soft limit for `BlockAccessLists` responses is 10 MiB. + +### Validation + +When a BAL is received, clients MUST validate it by computing `keccak256(rlp.encode(bal))` and comparing against the `block-access-list-hash` in the corresponding block header. + +## Rationale + +### Separate Messages vs. Block Body Extension + +BALs are transmitted via dedicated messages rather than extending block bodies because: + +1. **Size**: BALs average ~70 KiB, significantly increasing block propagation overhead if bundled. +2. **Optional retrieval**: Not all sync strategies require BALs. Snap sync can reconstruct state without them. +3. **Retention policy**: BALs may be pruned after the weak subjectivity period, while block bodies are retained longer. + +### Message IDs + +Message IDs 0x12 and 0x13 follow sequentially from the existing eth/69 messages (BlockRangeUpdate is 0x11). + +### Response Size Limit + +The 10 MiB soft limit aligns with existing protocol conventions and accommodates multiple BALs per response while remaining within typical message size constraints. + +## Backwards Compatibility + +This EIP changes the eth protocol and requires rolling out a new version, eth/71. Supporting multiple protocol versions is standard practice. Rolling out eth/71 does not break older clients, as they can continue using eth/69 or eth/70. + +This EIP requires the Amsterdam hard fork for the header field extension. The new messages are only meaningful for post-Amsterdam blocks. + +## Security Considerations + +### Validation Cost + +BAL validation requires computing a keccak256 hash of the RLP-encoded list. For typical BALs (~70 KiB), this is negligible. For worst-case BALs at high gas limits, validation remains bounded by the block gas limit. + +### Amplification + +A `GetBlockAccessLists` request can trigger responses larger than the request. Implementations SHOULD apply rate limiting and respect the soft response size limit to prevent amplification attacks. + +### Unavailable Data + +Clients MUST handle empty responses gracefully. A peer returning empty entries for available blocks may be misbehaving but could also have pruned the data legitimately. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From f83bf70bc2d2509720fc9eb757136cb9aeb94d95 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toni=20Wahrst=C3=A4tter?= Date: Thu, 12 Feb 2026 08:53:57 +0100 Subject: [PATCH 4/9] delete old file --- EIPS/eip-8159.md | 2 +- EIPS/eip-xxxx.md | 130 ----------------------------------------------- 2 files changed, 1 insertion(+), 131 deletions(-) delete mode 100644 EIPS/eip-xxxx.md diff --git a/EIPS/eip-8159.md b/EIPS/eip-8159.md index 7927daa6910ea5..c6562fada7bf38 100644 --- a/EIPS/eip-8159.md +++ b/EIPS/eip-8159.md @@ -1,5 +1,5 @@ --- -eip: XXXX +eip: 8159 title: eth/71 - Block Access List Exchange description: Adds peer-to-peer exchange of block-level access lists to the eth protocol author: Toni Wahrstätter (@nerolation) diff --git a/EIPS/eip-xxxx.md b/EIPS/eip-xxxx.md deleted file mode 100644 index c6562fada7bf38..00000000000000 --- a/EIPS/eip-xxxx.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -eip: 8159 -title: eth/71 - Block Access List Exchange -description: Adds peer-to-peer exchange of block-level access lists to the eth protocol -author: Toni Wahrstätter (@nerolation) -discussions-to: https://ethereum-magicians.org/t/eip-xxxx-eth-71-block-access-list-exchange/27725 -status: Draft -type: Standards Track -category: Networking -created: 2026-02-12 -requires: 7928 ---- - -## Abstract - -This EIP modifies the 'eth' p2p protocol to support block-level access list (BAL) exchange. It adds two new messages, `GetBlockAccessLists` (0x12) and `BlockAccessLists` (0x13), enabling peers to request and serve BALs for synchronization and parallel execution. - -## Motivation - -[EIP-7928](./eip-7928.md) introduces block-level access lists that record all state locations accessed during block execution. These lists enable parallel disk reads, parallel transaction execution, and executionless state updates. - -For syncing clients to leverage these capabilities, BALs must be obtainable from peers. The Engine API provides BALs from the consensus layer during normal operation, but historical BALs and peer-based sync require wire protocol support. - -## Specification - -### Block Header Extension - -The block header is extended with a new field after `requests-hash`: - -``` -block-header = [ - ... - requests-hash: B_32, - block-access-list-hash: B_32, -] -``` - -The `block-access-list-hash` field contains `keccak256(rlp.encode(block_access_list))` as defined in [EIP-7928](./eip-7928.md). This field MUST be present in headers after the Amsterdam fork and absent for earlier blocks. - -### Block Access List Encoding - -BALs are RLP-encoded as a list of account changes, sorted lexicographically by address: - -``` -block-access-list = [account-changes₁, account-changes₂, ...] - -account-changes = [ - address: B_20, - storage-changes: [[slot: B_32, [[block-access-index: P, value: B_32], ...]], ...], - storage-reads: [slot₁: B_32, slot₂: B_32, ...], - balance-changes: [[block-access-index: P, balance: P], ...], - nonce-changes: [[block-access-index: P, nonce: P], ...], - code-changes: [[block-access-index: P, code: B], ...], -] -``` - -Where `block-access-index` indicates when the change occurred: -- `0` for pre-execution system contract calls -- `1...n` for transactions (in block order) -- `n+1` for post-execution system contract calls and withdrawals - -See [EIP-7928](./eip-7928.md) for complete BAL generation rules and inclusion semantics. - -### New Protocol Messages - -#### GetBlockAccessLists (0x12) - -``` -[request-id: P, [blockhash₁: B_32, blockhash₂: B_32, ...]] -``` - -Request BALs for the given block hashes. The number of BALs that can be requested in a single message is subject to implementation-defined limits. - -BALs are only available for blocks after [EIP-7928](./eip-7928.md) activation and within the weak subjectivity period (~3533 epochs). Requests for unavailable BALs return empty entries. - -#### BlockAccessLists (0x13) - -``` -[request-id: P, [block-access-list₁, block-access-list₂, ...]] -``` - -Response to `GetBlockAccessLists`. Each element corresponds to a block hash from the request, in order. Empty BALs (RLP-encoded empty list `0xc0`) are returned for blocks where the BAL is unavailable. - -The recommended soft limit for `BlockAccessLists` responses is 10 MiB. - -### Validation - -When a BAL is received, clients MUST validate it by computing `keccak256(rlp.encode(bal))` and comparing against the `block-access-list-hash` in the corresponding block header. - -## Rationale - -### Separate Messages vs. Block Body Extension - -BALs are transmitted via dedicated messages rather than extending block bodies because: - -1. **Size**: BALs average ~70 KiB, significantly increasing block propagation overhead if bundled. -2. **Optional retrieval**: Not all sync strategies require BALs. Snap sync can reconstruct state without them. -3. **Retention policy**: BALs may be pruned after the weak subjectivity period, while block bodies are retained longer. - -### Message IDs - -Message IDs 0x12 and 0x13 follow sequentially from the existing eth/69 messages (BlockRangeUpdate is 0x11). - -### Response Size Limit - -The 10 MiB soft limit aligns with existing protocol conventions and accommodates multiple BALs per response while remaining within typical message size constraints. - -## Backwards Compatibility - -This EIP changes the eth protocol and requires rolling out a new version, eth/71. Supporting multiple protocol versions is standard practice. Rolling out eth/71 does not break older clients, as they can continue using eth/69 or eth/70. - -This EIP requires the Amsterdam hard fork for the header field extension. The new messages are only meaningful for post-Amsterdam blocks. - -## Security Considerations - -### Validation Cost - -BAL validation requires computing a keccak256 hash of the RLP-encoded list. For typical BALs (~70 KiB), this is negligible. For worst-case BALs at high gas limits, validation remains bounded by the block gas limit. - -### Amplification - -A `GetBlockAccessLists` request can trigger responses larger than the request. Implementations SHOULD apply rate limiting and respect the soft response size limit to prevent amplification attacks. - -### Unavailable Data - -Clients MUST handle empty responses gracefully. A peer returning empty entries for available blocks may be misbehaving but could also have pruned the data legitimately. - -## Copyright - -Copyright and related rights waived via [CC0](../LICENSE.md). From 2dcb3db90e953fa71436fa849aff4f3e9e8f4a9e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toni=20Wahrst=C3=A4tter?= Date: Thu, 12 Feb 2026 08:59:53 +0100 Subject: [PATCH 5/9] add correct ethmag url --- EIPS/eip-8159.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-8159.md b/EIPS/eip-8159.md index c6562fada7bf38..6c32c99e35d2bf 100644 --- a/EIPS/eip-8159.md +++ b/EIPS/eip-8159.md @@ -3,7 +3,7 @@ eip: 8159 title: eth/71 - Block Access List Exchange description: Adds peer-to-peer exchange of block-level access lists to the eth protocol author: Toni Wahrstätter (@nerolation) -discussions-to: https://ethereum-magicians.org/t/eip-xxxx-eth-71-block-access-list-exchange/27725 +discussions-to: https://ethereum-magicians.org/t/eip-8159-eth-71-block-access-list-exchange/27725 status: Draft type: Standards Track category: Networking From 8b97ccf0b3e45410c4e7a16f13e0d62c7becbeb5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toni=20Wahrst=C3=A4tter?= Date: Thu, 12 Feb 2026 09:51:29 +0100 Subject: [PATCH 6/9] fix linter errors --- EIPS/eip-8159.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-8159.md b/EIPS/eip-8159.md index 6c32c99e35d2bf..9b59078ac38944 100644 --- a/EIPS/eip-8159.md +++ b/EIPS/eip-8159.md @@ -55,6 +55,7 @@ account-changes = [ ``` Where `block-access-index` indicates when the change occurred: + - `0` for pre-execution system contract calls - `1...n` for transactions (in block order) - `n+1` for post-execution system contract calls and withdrawals From e553f5beebaf512583142389544bcf1f744df86f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toni=20Wahrst=C3=A4tter?= Date: Thu, 12 Feb 2026 16:27:33 +0100 Subject: [PATCH 7/9] fix header fild, remove reference to WSP --- EIPS/eip-8159.md | 35 ++++++++++++++++++++++++++--------- 1 file changed, 26 insertions(+), 9 deletions(-) diff --git a/EIPS/eip-8159.md b/EIPS/eip-8159.md index 9b59078ac38944..0239403882a805 100644 --- a/EIPS/eip-8159.md +++ b/EIPS/eip-8159.md @@ -13,7 +13,7 @@ requires: 7928 ## Abstract -This EIP modifies the 'eth' p2p protocol to support block-level access list (BAL) exchange. It adds two new messages, `GetBlockAccessLists` (0x12) and `BlockAccessLists` (0x13), enabling peers to request and serve BALs for synchronization and parallel execution. +This EIP modifies the 'eth' p2p protocol to support Block-level Access Lists (BALs). It adds two new messages, `GetBlockAccessLists` (0x12) and `BlockAccessLists` (0x13), enabling peers to request and serve BALs for synchronization and parallel execution. ## Motivation @@ -35,7 +35,7 @@ block-header = [ ] ``` -The `block-access-list-hash` field contains `keccak256(rlp.encode(block_access_list))` as defined in [EIP-7928](./eip-7928.md). This field MUST be present in headers after the Amsterdam fork and absent for earlier blocks. +The `block-access-list-hash` field contains `keccak256(rlp.encode(block-access-list))` as defined in [EIP-7928](./eip-7928.md). This field MUST be present in headers after the Amsterdam fork and absent for earlier blocks. ### Block Access List Encoding @@ -46,14 +46,31 @@ block-access-list = [account-changes₁, account-changes₂, ...] account-changes = [ address: B_20, - storage-changes: [[slot: B_32, [[block-access-index: P, value: B_32], ...]], ...], - storage-reads: [slot₁: B_32, slot₂: B_32, ...], - balance-changes: [[block-access-index: P, balance: P], ...], - nonce-changes: [[block-access-index: P, nonce: P], ...], - code-changes: [[block-access-index: P, code: B], ...], + storage-changes, + storage-reads, + balance-changes, + nonce-changes, + code-changes, ] + +storage-changes = [slot-changes₁, slot-changes₂, ...] +slot-changes = [slot: B_32, [storage-change₁, storage-change₂, ...]] +storage-change = [block-access-index: P, value: B_32] + +storage-reads = [slot₁: B_32, slot₂: B_32, ...] + +balance-changes = [balance-change₁, balance-change₂, ...] +balance-change = [block-access-index: P, balance: P] + +nonce-changes = [nonce-change₁, nonce-change₂, ...] +nonce-change = [block-access-index: P, nonce: P] + +code-changes = [code-change₁, code-change₂, ...] +code-change = [block-access-index: P, code: B] ``` +`storage-changes` MUST be sorted by slot. Changes within each slot MUST be sorted by `block-access-index`. `storage-reads` MUST be sorted by slot. + Where `block-access-index` indicates when the change occurred: - `0` for pre-execution system contract calls @@ -72,7 +89,7 @@ See [EIP-7928](./eip-7928.md) for complete BAL generation rules and inclusion se Request BALs for the given block hashes. The number of BALs that can be requested in a single message is subject to implementation-defined limits. -BALs are only available for blocks after [EIP-7928](./eip-7928.md) activation and within the weak subjectivity period (~3533 epochs). Requests for unavailable BALs return empty entries. +BALs are only available for blocks after [EIP-7928](./eip-7928.md) activation and within the retention period defined therein. Requests for unavailable BALs return empty entries. #### BlockAccessLists (0x13) @@ -96,7 +113,7 @@ BALs are transmitted via dedicated messages rather than extending block bodies b 1. **Size**: BALs average ~70 KiB, significantly increasing block propagation overhead if bundled. 2. **Optional retrieval**: Not all sync strategies require BALs. Snap sync can reconstruct state without them. -3. **Retention policy**: BALs may be pruned after the weak subjectivity period, while block bodies are retained longer. +3. **Retention policy**: BALs may be pruned per [EIP-7928](./eip-7928.md), while block bodies are retained longer. ### Message IDs From ea0d2b1bb54547e785cb68d013ff2c76d85e5dd3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toni=20Wahrst=C3=A4tter?= Date: Thu, 12 Feb 2026 16:30:14 +0100 Subject: [PATCH 8/9] clarify BAL item ordering --- EIPS/eip-8159.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-8159.md b/EIPS/eip-8159.md index 0239403882a805..08e6a1e00928cc 100644 --- a/EIPS/eip-8159.md +++ b/EIPS/eip-8159.md @@ -69,7 +69,7 @@ code-changes = [code-change₁, code-change₂, ...] code-change = [block-access-index: P, code: B] ``` -`storage-changes` MUST be sorted by slot. Changes within each slot MUST be sorted by `block-access-index`. `storage-reads` MUST be sorted by slot. +`storage-changes` MUST be sorted lexicographically by slot. Changes within each slot MUST be sorted by `block-access-index` ascending. `storage-reads` MUST be sorted lexicographically by slot. Where `block-access-index` indicates when the change occurred: From 62ad72b16644aeb7c3bbe84b9749f839d5de2b43 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Toni=20Wahrst=C3=A4tter?= <51536394+nerolation@users.noreply.github.com> Date: Sun, 15 Feb 2026 11:47:39 +0100 Subject: [PATCH 9/9] Update EIPS/eip-8159.md Co-authored-by: Jochem Brouwer --- EIPS/eip-8159.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-8159.md b/EIPS/eip-8159.md index 08e6a1e00928cc..9513df472b688a 100644 --- a/EIPS/eip-8159.md +++ b/EIPS/eip-8159.md @@ -8,7 +8,7 @@ status: Draft type: Standards Track category: Networking created: 2026-02-12 -requires: 7928 +requires: 7928, 7975 --- ## Abstract