Van 60 miljoen richting 200 miljoen gas per blok.
Ethereum begint vanmiddag op Sepolia aan een forse capaciteitstest zodra Glamsterdam wordt geactiveerd. Prysm v7.2.1 laat validators vanaf dat moment standaard mikken op een gaslimiet van 200 miljoen.
De fork staat gepland voor 6 oktober om 13:53:36 UTC, oftewel 15:53:36 uur Nederlandse tijd.
Maar één detail telt: Sepolia springt niet in één blok rechtstreeks van 60 naar 200 miljoen.
200 miljoen is een doel, geen harde nieuwe grens
De verandering loopt via EIP-8261.
Die introduceert een GAS_LIMIT_SCHEDULE waarmee Ethereum-clients per epoch een standaarddoel voor de gaslimiet kunnen gebruiken.
Voor Sepolia staat dat doel vanaf Glamsterdam op 200 miljoen gas. Prysm v7.2.1 neemt die instelling automatisch over wanneer een validator geen eigen waarde heeft ingesteld.
Dat betekent niet dat blokken vanaf 15:53 uur onmiddellijk 200 miljoen gas kunnen bevatten.
De bestaande Ethereum-regel blijft gelden waarbij de gaslimiet per blok slechts beperkt ten opzichte van het vorige blok kan veranderen. EIP-8261 verandert die geldigheidsregel niet.
De daadwerkelijke limiet moet dus geleidelijk richting 200 miljoen bewegen wanneer voldoende validators dat doel blijven volgen.
Dat onderscheid maakt de test belangrijker dan alleen een nieuw getal in een configuratiebestand.
Prysm repareert last-minute verschil met vorige release
Prysm v7.2.1 verscheen op 5 oktober, minder dan een dag voor de geplande Glamsterdam-fork.
De release bevat het Sepolia-schema voor 200 miljoen gas standaard. Validators hoeven daarvoor geen aparte instelling meer toe te voegen.
Bij Prysm v7.2.0 lag dat anders.
Die versie ondersteunt Glamsterdam op Sepolia, maar was uitgebracht voordat de nieuwe gasplanning in de Sepolia-configuratie was opgenomen. Daardoor bleef de standaardvoorkeur daar op 60 miljoen staan.
Operators die met v7.2.0 toch naar 200 miljoen wilden, moesten dat handmatig instellen.
Versie 7.2.1 haalt dat verschil weg.
Vanaf epoch 353.024 wordt 200 miljoen automatisch de standaardvoorkeur.
Drie keer meer gas is niet drie keer meer transacties
Gas meet grofweg hoeveel rekenwerk en opslaghandelingen binnen een Ethereum-blok mogen plaatsvinden.
Een hogere limiet geeft daardoor ruimte voor meer activiteit.
Maar 200 miljoen tegenover 60 miljoen betekent niet automatisch dat
Ethereum ruim drie keer zoveel transacties per seconde verwerkt.
Niet iedere transactie gebruikt evenveel gas.
Een simpele
ETH-overdracht kost iets anders dan een ingewikkelde interactie met meerdere smart contracts.
Ook moeten nodes de grotere blokken op tijd ontvangen, uitvoeren en controleren.
De echte test is daarom niet hoeveel transacties theoretisch in een blok passen.
De vraag is hoeveel extra werk het netwerk betrouwbaar kan verwerken.
Ethereum wil weten waar nodes beginnen te kraken
Een hogere gaslimiet vergroot de hoeveelheid uitvoering die in korte tijd kan plaatsvinden.
Execution clients krijgen daardoor meer werk. Nodes moeten meer wijzigingen in de blockchainstate verwerken en validators moeten binnen dezelfde tijdslimieten tot geldige blokken komen.
Ethereum-ontwikkelaars hebben de verhoging daarom gekoppeld aan Glamsterdam, waar juist meerdere wijzigingen zijn opgenomen die uitvoering efficiënter moeten maken.
De Ethereum Foundation noemt ePBS en Block-Level Access Lists als de twee grootste onderdelen van de upgrade.
Daarmee wordt de hogere gaslimiet ook een praktijktest voor die wijzigingen.
ePBS geeft execution meer tijd
Enshrined Proposer-Builder Separation verandert de manier waarop blokken worden gebouwd.
Een validator die een blok voorstelt, hoeft niet zelf de volledige inhoud samen te stellen. Gespecialiseerde builders kunnen daarvoor concurreren.
Met EIP-7732 wordt een groter deel van die relatie rechtstreeks in het Ethereum-protocol opgenomen.
Consensuscontrole en executioncontrole worden daarbij verder uit elkaar getrokken. Validators krijgen zo meer ruimte om de execution payload te controleren.
Dat wordt interessanter wanneer blokken zwaarder worden.
Een gaslimiet heeft weinig waarde als validators de extra berekeningen niet binnen de beschikbare tijd kunnen verwerken.
Block-Level Access Lists moeten parallel werk mogelijk maken
Ook Block-Level Access Lists spelen mee.
Glamsterdam laat per blok vastleggen welke accounts en opslaglocaties tijdens de uitvoering worden aangeraakt.
Clients kunnen daardoor delen van het werk eerder en vaker parallel uitvoeren.
De Ethereum Foundation noemt onder meer parallelle state reads, parallelle transactieverwerking en efficiëntere berekening van state roots.
Dat is precies het soort verbetering dat nodig wordt wanneer Ethereum veel meer gas per blok wil verwerken.
De 200 miljoen-test staat dus niet los van Glamsterdam.
Hij leunt op de technische veranderingen die hogere Layer-1-capaciteit haalbaarder moeten maken.
Prysm verandert tegelijk de verspreiding van data
Versie 7.2.1 zet ook partial data columns standaard aan.
Daarbij versturen nodes data op celniveau in plaats van altijd een volledige kolom door te sturen. Een node kan dus alleen de delen verspreiden die hij daadwerkelijk bezit.
Prysm koppelt dit aan PeerDAS en noemt het een efficiëntere manier om data over het netwerk te verspreiden. Operators kunnen nog terugschakelen naar volledige kolommen.
Ook hier draait het om schaal.
Meer capaciteit helpt weinig wanneer iedere extra hoeveelheid data zich één-op-één vertaalt naar veel meer netwerkverkeer voor iedere node.
Builders krijgen nieuwe knoppen
De nieuwste Prysm-release bevat daarnaast meerdere instellingen voor builders.
Validators kunnen onder meer builder-URL's, minimale biedingen, een boostfactor en maximale executionbetalingen configureren.
Ook is de standaardtijd waarin Prysm op builderbiedingen wacht verhoogd van 300 naar 600 milliseconden.
Die wijzigingen hangen samen met Gloas en ePBS.
Builders krijgen binnen Glamsterdam een explicietere rol in het protocol. Validatorsoftware moet daarom preciezer kunnen bepalen met welke builders wordt gewerkt en onder welke voorwaarden.
De upgrade van vandaag test dus tegelijkertijd blokcapaciteit én een nieuwe marktstructuur voor block building.
200 miljoen gaat niet automatisch naar mainnet
Daar ligt de belangrijkste grens.
Deze configuratie geldt voor Sepolia.
De Ethereum Foundation heeft nog geen activatiemoment vastgesteld voor Glamsterdam op Hoodi of Ethereum-mainnet. Beide staan officieel nog op TBD.
Ook EIP-8261 maakt 200 miljoen niet tot een verplichte bovengrens voor Ethereum.
Het voorstel noemt de geplande waarde een standaarddoel en aanbevolen maximum. Een operator kan technisch een andere voorkeur instellen.
Blokken met een andere gaslimiet blijven geldig zolang ze voldoen aan de bestaande regels voor de verandering tussen opeenvolgende blokken.
Dat maakt Sepolia de plek waar developers eerst kunnen zien wat er gebeurt wanneer validators veel hoger mikken.
De echte test begint pas na de fork
Voor gewone ETH-houders is voor de Sepolia-upgrade geen actie nodig.
Nodeoperators op het testnet moeten wel Glamsterdam-compatibele execution- en consensussoftware draaien. De Ethereum Foundation waarschuwt dat nodes zonder ondersteuning na de fork de geüpgradede keten niet correct kunnen blijven volgen.
Daarna begint het interessante deel.
Niet of een configuratiebestand het getal 200 miljoen accepteert.
Maar of Sepolia richting die capaciteit kan bewegen zonder dat block propagation, execution of validatorprestaties zichtbaar verslechteren.
Ethereum zet vanmiddag het gaspedaal niet in één keer drie keer dieper.
Het verhoogt vooral het doel.
Sepolia moet daarna bewijzen hoeveel van die ruimte het netwerk werkelijk aankan.