Ethereum EIP puts write age into PBT leaves

Published on Ethereum Magicians on October 4, a draft proposal carries EIP-8188’slast_written_block signal into the Partitioned Binary Tree (PBT) of EIP-8297. No EIP number has been assigned yet. The field lands directly in PBT leaves.

EIP-8188 records the block at which every account and storage slot was last written. EIP-TBD keeps that signal but changes where and how it’s encoded, because the PBT has no RLP.

For accounts, the 4-bytelast_written_block field goes into the existingaccountBASIC_DATA, using three reserved bytes plus one byte freed by narrowingcode_size from four bytes to three. Account size does not increase. The draft notes three bytes can hold roughly 256 times the 64 KiB code-size limit, and EIP-7864 already specified a 3-bytecode_size at the same offset.

Storage slots take the direct cost. Their leaf value grows from 32 bytes to 36 bytes, with the extra four bytes placed after the slot value. Writes setlast_written_block to the current block number; reads leave it unchanged; reverted writes restore the previous value.

That last rule is also where EIP-TBD breaks from its predecessor. Under EIP-8188, writing a storage slot also updates the account’slast_written_block. EIP-TBD removes that storage-to-account cascade because of the PBT’s structure. An account’s field and a slot’s field can therefore reflect separate write events.

The draft’s stated state cost is lower than EIP-8188’s. The draft proposal estimates roughly 6 GB of additional state in the worst case — 1.5 billion slots multiplied by four bytes. EIP-8188’s estimate for its Merkle Patricia Tree encoding was 10.8 GB. That’s 4.8 GB less, a 44.4% reduction:(10.8 GB - 6 GB) / 10.8 GB = 44.4%.

The saving comes with a narrower signal. Because storage writes don’t update account metadata, anything reading account age can’t treat every descendant slot write as an account write under this layout. The draft proposal says the design works with tiering proposals EIP-8295 and EIP-8296, which only readlast_written_block — the proposals that the draft says can use the signal, since they retain access to the field while the PBT uses its own leaf format.

Storage-heavy state bears the added bytes. At the draft’s worst-case estimate, 1.5 billion slots account for roughly 6 GB of extra state; accounts see no size increase. For protocols that consume write-age data, the concrete consequence is this: reads can use the field, but assumptions must match the PBT rule that reads never refresh it and storage writes don’t refresh the account field.

The field width is fixed at four bytes under the proposed layout, usable until block2^32 - 1. At 12-second slots, the draft estimates that horizon at about 1,600 years — a fixed four-byte slot addition under the proposed layout traded against a limit the draft proposal puts well outside any operating concern.

The proposal’s EIP number and any implementation timeline for EIP-8297 aren’t established in the draft. What the draft does establish: if this layout is adopted, PBT storage leaves carry write age at 36 bytes, account leaves stay at their existing size, and EIP-8295 and EIP-8296 can read the signal they need.