EIP-8435: Last-Written Block in PBT Leaves

EIPs
1

Carrying EIP-8188’s write-age signal into the Partitioned Binary Tree

EIP-8188 records, for every account and storage slot, the block at which it was last written. That gives clients a consensus-level signal for separating recently written state from state that has not been written in a long time, and the tiering proposals EIP-8295 and EIP-8296 build their pricing on it.

EIP-8188 defines the field for the MPT. It adds a fifth element to the account RLP and wraps each storage slot in a two-element RLP list. The Partitioned Binary Tree of EIP-8297 has no RLP: account fields sit at fixed byte offsets in the account leaf, and a storage leaf holds only the raw 32-byte word. So once the tree changes, the field has nowhere to live.

This EIP gives last_written_block a place in PBT leaves. Like EIP-8188, it changes no gas costs, removes no state and needs no resurrection mechanism.

What this EIP does

  • Accounts: last_written_block (4 bytes) goes into the existing account BASIC_DATA. It uses the 3 reserved bytes plus 1 byte freed by narrowing code_size from 4 bytes to 3. nonce and balance do not move, and accounts grow by 0 bytes.
  • Storage slots: the leaf value grows from 32 to 36 bytes: the unchanged slot value, then a 4-byte last_written_block. This applies to header slots 0..63 and to slots in the storage zone. Keys do not change.
  • Update rules: writes set the field to the current block number, reads never touch it, and a reverted write restores the old value. These are EIP-8188’s rules, with the one difference described below.
  • Retrieval: the field is part of the leaf’s committed value, so it can be read at will and proven against the state root with an ordinary EIP-8297 inclusion proof.

What differs from EIP-8188

EIP-8188 (MPT) This EIP (PBT)
Account encoding fifth RLP element bytes 1..4 of BASIC_DATA
Slot encoding RLP list [value, last_written_block] 36-byte value: slot value, then the field
Growth per account 5 bytes 0 bytes
Growth per slot 6 bytes 4 bytes
Field width variable (RLP integer) fixed 4 bytes
Storage write updates the account’s field yes no

No storage-to-account cascade. In EIP-8188, writing a storage slot also updates the account’s last_written_block. That follows from the MPT’s shape: the account RLP contains storageRoot, so any storage write rewrites the account leaf anyway. The PBT has no storage_root. An account’s header and its storage are separate leaves, and a storage write never touches BASIC_DATA. A cascade would add a header rewrite that the tree does not otherwise need, so this EIP leaves it out.

The result is that the two fields are independent. An account’s last_written_block dates its header (balance, nonce, code), and each slot’s field dates that slot.

Why put the field inside the leaf

  • One read, one write, one proof. The metadata travels with the value it dates. No second leaf has to be kept in step with the first.
  • It deletes and reverts with the state. When a slot is set to zero, its leaf goes and the metadata goes with it.
  • It works wherever the leaf is stored. A client that moves cold leaves out of its main database still has the field, because the field is in the leaf.

FAQ

Doesn’t the metadata bloat the state?
Less than under EIP-8188. In the worst case, where every slot is rewritten after the fork, this EIP adds about 6 GB (1.5B slots × 4 bytes, and nothing for accounts). EIP-8188 estimates 10.8 GB for the MPT encoding. Both figures are calculated from EIP-8188’s state counts, not measured.

Why only 4 bytes?
PBT fields sit at fixed offsets, so the width has to be fixed. Three bytes is already too small for mainnet’s block height, and 4 is the most BASIC_DATA can give without taking space from nonce or balance. Four bytes lasts until block 2^32 - 1, which EIP-8188 puts at about 1,600 years away at 12-second slots.

Why narrow code_size?
It is the only header field whose range is capped far below its width. Three bytes hold about 256 times the 64 KiB code size limit. EIP-7864 already specified a 3-byte code_size at the same offset.

Does a 36-byte storage leaf cost more to hash?
Not with BLAKE3, the hash in EIP-8297’s reference implementation. A storage leaf’s hash input still fits in two 64-byte blocks. This needs rechecking once EIP-8297 fixes its hash.

Does it work with the tiering proposals?
Yes. EIP-8295 and EIP-8296 only read last_written_block. Both state that EIP-8188 “owns the encoding and the rules that update” the field, and that they read it to classify state. Their rule is per leaf: “The tier of each leaf MUST be determined from its last_written_block”, and a surcharge applies to each existing leaf an operation writes.

This EIP gives every account leaf and every storage leaf that field, so the same rule applies on the PBT:

  • A balance or nonce write is classified from the account’s BASIC_DATA leaf.
  • An SSTORE is classified from the slot’s own leaf.
  • The raw block number is kept, so EIP-8295’s periods and EIP-8296’s cutoff are derived from it exactly as on the MPT.

In those two EIPs, an SSTORE can also surcharge the account “via the storageRoot cascade”. That prices an account-leaf write the MPT performs. The PBT performs no such write, so on the PBT an SSTORE is priced by the slot alone. In both trees the field dates the last time that leaf was written, which is what the tiering rules price.

Update Log

  • 2026-10-04: initial draft

External Reviews

None as of 2026-10-04.

2 Likes