Twee Ethereum-gascommits en voorstel voor stateless accounts volgen elkaar snel op

Op 20 augustus verschenen twee commits in de Ethereum EIP-repository — de ene met betrekking tot de rekenregels voor calldata-prijzen, de andere met een wijziging in de inhoud van een bundel-EIP — en de ochtend erna opende EIP-8387 op het Ethereum Magicians-forum met iets structureels: een voorstel om te veranderen wat een Ethereum-account eigenlijk is.

Eerst de calldata-commit. De update van 20 augustus aan EIP-8141 voegt een functie floor_tokens_in(data) toe, gedefinieerd als len(data) * 4. Inhoudsblind, volledig uniform, toegepast op elke in rekening gebrachte byte zonder te kijken wat die bytes bevatten. Dat staat in contrast met de bestaande functie tokens_in, die bytes verschillend weegt op basis van hun waarde — een onderscheid dat terug te voeren is op EIP-7976. Pas floor_tokens_in toe op 100 bytes en je krijgt 400. Elke keer weer. Voor ontwikkelaars van rollups of iedereen die data-intensieve applicaties bouwt, is het directe voordeel dat worstcasescenario’s voor gasraming geen functie meer zijn van wat er in de payload zit. Om duidelijk te zijn: dit is geen plafond. tokens_in kan voor specifieke bytepatronen nog steeds hogere waarden opleveren. Wat het wél oplevert, is een vaste ondergrens die je kunt berekenen voordat je iets deployt.

De tweede commit van 20 augustus betrof EIP-8081, dat meerdere EIP’s bundelt voor gecoördineerde activatie. EIP-8268 ging eruit. EIP-8077, EIP-8094 en EIP-8372 kwamen erbij. De GitHub-log biedt geen toelichting. Herschikkingen van bundels in dit stadium van upgradeplanning volgen doorgaans verschuivende afhankelijkheden, maar wat precies tot de wissel leidde — en wat de drie toevoegingen precies behelzen — staat niet in het beschikbare commit-materiaal. Wie de volledige afhankelijkheidsketen probeert te achterhalen, stuit hier op een leemte.

EIP-8387 opereert in een geheel ander register. Het forumbericht, gedateerd op 21 augustus en getiteld “Stateless Accounts,” stelt voor om stateless accountcreatie toe te voegen aan EIP-8130, als onderdeel van Ethereums langeretermijnwerk op het gebied van privacy en statelessness. Het beschreven model zou accounts laten bestaan zonder permanente on-chain opslag — architectonisch anders dan hoe het nu werkt, waarbij elk extern beheerd account of contract vanaf het moment van aanmaak een plek inneemt in de globale state. Het voorstel stelt dat dit mogelijkheden opent voor ontwerpen van light clients en privacybeschermende transactiestromen die het huidige model uitsluit. Dat is een structurele breuk met een fundamentele aanname, geen parameteraanpassing.

Wie daadwerkelijk moet handelen als iets hiervan doorgaat, hangt af van beslissingen die nog lang niet genomen zijn. Teams achter rollups en ontwikkelaars van wallets zouden hun logica voor gasraming moeten herzien als de floor-functie van EIP-8141 in een netwerkupgrade terechtkomt. Projecten die bouwen op EIP-8130 zouden rekening moeten houden met het stateless model dat EIP-8387 voorstelt — maar het voorstel bevindt zich in de discussiefase, de relatie met EIP-8130 blijft onopgelost, en voor geen van de drie hier besproken voorstellen bestaat een activatiedeadline.

Twee EIP’s waarnaar in gerelateerde discussies wordt verwezen — EIP-7773 en EIP-8386 — komen niet voor in het bronmateriaal van 20 of 21 augustus. Details over APPROVE-faalscenario’s en over wat een “Transaction Events View” precies inhoudt, ontbreken eveneens in de beschikbare documentatie.

Op het moment van schrijven was er voor geen van deze voorstellen een activatietijdlijn openbaar gemaakt.