Ethereum-EIP voegt schrijfleeftijd toe aan PBT-leaves

Gepubliceerd op Ethereum Magicians op 4 oktober, brengt een conceptvoorstel hetlast_written_block-signaal van EIP-8188 naar de Partitioned Binary Tree (PBT) van EIP-8297. Er is nog geen EIP-nummer toegekend. Het veld komt rechtstreeks in de PBT-leaves terecht.

EIP-8188 registreert bij welk block elk account en elke storage-slot voor het laatst is beschreven. EIP-TBD behoudt dat signaal, maar verandert waar en hoe het wordt gecodeerd, omdat de PBT geen RLP kent.

Voor accounts komt het 4-bytelast_written_block-veld in de bestaandeaccountBASIC_DATA terecht, waarbij drie gereserveerde bytes worden gebruikt plus één byte die vrijkomt doorcode_size te verkleinen van vier naar drie bytes. De accountgrootte neemt niet toe. Het concept merkt op dat drie bytes ongeveer 256 keer de code-size-limiet van 64 KiB kunnen bevatten, en EIP-7864 specificeerde al een 3-bytecode_size op dezelfde offset.

Storage-slots dragen de directe kosten. De waarde van hun leaf groeit van 32 bytes naar 36 bytes, waarbij de extra vier bytes na de slotwaarde worden geplaatst. Schrijfacties zettenlast_written_block op het huidige blocknummer; leesacties laten het ongewijzigd; teruggedraaide schrijfacties herstellen de vorige waarde.

Die laatste regel is ook waar EIP-TBD afwijkt van zijn voorganger. Onder EIP-8188 werkt het beschrijven van een storage-slot ook hetlast_written_block-veld van het account bij. EIP-TBD verwijdert die cascade van storage naar account vanwege de structuur van de PBT. Het veld van een account en het veld van een slot kunnen daardoor verschillende schrijfgebeurtenissen weerspiegelen.

De in het concept genoemde statekosten liggen lager dan die van EIP-8188. Het conceptvoorstel schat in het worst-case scenario ongeveer 6 GB extra state — 1,5 miljard slots vermenigvuldigd met vier bytes. De schatting van EIP-8188 voor zijn Merkle Patricia Tree-codering was 10,8 GB. Dat is 4,8 GB minder, een reductie van 44,4%:(10,8 GB - 6 GB) / 10,8 GB = 44,4%.

De besparing gaat gepaard met een beperkter signaal. Omdat storage-schrijfacties de accountmetadata niet bijwerken, kan iets dat de leeftijd van een account uitleest niet elke onderliggende slot-schrijfactie als een accountschrijfactie behandelen onder deze indeling. Het conceptvoorstel stelt dat het ontwerp werkt met de tiering-voorstellen EIP-8295 en EIP-8296, die alleenlast_written_block uitlezen — de voorstellen die volgens het concept het signaal kunnen gebruiken, omdat zij toegang tot het veld behouden terwijl de PBT zijn eigen leaf-formaat gebruikt.

State met veel storage draagt de extra bytes. Bij de worst-case schatting van het concept zijn 1,5 miljard slots goed voor ongeveer 6 GB extra state; accounts kennen geen groei in omvang. Voor protocollen die data over schrijfleeftijd gebruiken, is het concrete gevolg het volgende: leesacties kunnen het veld gebruiken, maar aannames moeten overeenkomen met de PBT-regel dat leesacties het veld nooit vernieuwen en storage-schrijfacties het accountveld niet vernieuwen.

De veldbreedte ligt onder de voorgestelde indeling vast op vier bytes, bruikbaar tot block2^32 - 1. Bij slots van 12 seconden schat het concept die horizon op ongeveer 1.600 jaar — een vaste toevoeging van vier bytes per slot onder de voorgestelde indeling, afgewogen tegen een limiet die het conceptvoorstel ver buiten elke operationele zorg plaatst.

Het EIP-nummer van het voorstel en een eventueel implementatietijdpad voor EIP-8297 staan nog niet vast in het concept. Wat het concept wél vastlegt: als deze indeling wordt aangenomen, dragen PBT-storage-leaves de schrijfleeftijd bij een omvang van 36 bytes, blijven account-leaves op hun bestaande omvang, en kunnen EIP-8295 en EIP-8296 het signaal uitlezen dat ze nodig hebben.