Een specificatiewijziging die op 26 oktober is samengevoegd dicht een fout in Ethereum's stortingsverwerking die node-operators had kunnen toestaan om stortingen van stakers die in de wachtrij stonden om te leiden naar saldi onder hun eigen controle zodra de Glamsterdam-upgrade van het netwerk actief wordt. De oplossing belandde in de consensus-specs-repository — de referentieregels die Ethereum's client-teams implementeren — twee weken nadat de fout op GitHub was gemeld. Alleen stortingen die bij activatie van de fork nog in de wachtrij stonden, konden verkeerd worden gerouteerd, en omdat Glamsterdam de mainnet nog niet heeft bereikt, is er geen geld verloren.

Hoe een operator de staking van een staker had kunnen afpakken

Pooled staking-protocollen verdelen vaak het werk van het runnen van een validator. Het protocol zet de ETH in, terwijl een externe node-operator de ondertekeningssleutel van de validator beheert. Ethereum houdt ondertekening en opnames gescheiden, zodat een operator een validator kan runnen zonder de stake van het protocol te kunnen opnemen.

Glamsterdam combineert wijzigingen op de execution-laag met een upgrade van de consensus-laag genaamd Glo en voegt builders toe als een nieuw soort deelnemer onder enshrined proposer-builder separation. Builders stellen het transactiedragende deel van elk blok samen en beheren hun eigen saldi. Bij de fork converteert Ethereum kwalificerende stortingen die nog in de wachtrij staan naar builder-accounts.

In die conversie zat de fout. Volgens de oude regel zorgde eenmaal een openstaande storting voor een builder-registratie voor een sleutel ervoor dat elke latere storting voor die sleutel de builder aanvulde, ongeacht waar de opname-credentials naartoe wezen. Een operator kon een builder-storting voor een nieuwe sleutel in de wachtrij zetten vanaf een adres onder zijn controle. Als een staking-protocol vervolgens een validator-storting voor dezelfde sleutel financierde, en beide stonden bij de fork nog open, dan zou de ETH van het protocol zijn bijgeschreven op het builder-saldo van de operator, dat de operator daarna kon opnemen. Er zou ook geen validator worden aangemaakt. Sommige protocollen geven de rest van een stake pas vrij nadat is aangetoond dat een nieuwe validator hun opname-credentials draagt, en dat bewijs zou nooit zijn gekomen.

In een vervolgreactie somde de auteur van het issue de ontwerpen op die de bug had kunnen verstoren: Lido's predeposit guarantee, Origin's OETH en Rocket Pool's Saturn, waarbij hij de lijst aanduidde als snel AI-ondersteund onderzoek dat fouten kan bevatten. In elk geval zou de blootstelling een eerste storting zijn geweest — 1 ETH in de voorbeelden van Lido en Rocket Pool — met de rest van de stake vergrendeld totdat herstelstappen waren uitgevoerd. De auteur omschreef deze als voorwaardelijke codebevindingen, geen actieve exploits.

Verworpen op 19 oktober, een week later samengevoegd

De oplossing werd op 12 oktober voorgesteld. Na discussie tijdens twee kernontwikkelaarsoproepen werd hij op 19 oktober gesloten wegens gebrek aan client-ondersteuning, en de testoproep stelde voor hem te prototypen na de Hoodi-testnet-upgrade in plaats van het schema te verstoren.

Drie dagen later stelde de Ethereum Foundation de activatie van Glamsterdam op Hoodi uit om te onderzoeken hoe EIP-8037 omgaat met bestaande smart contracts, een probleem dat niets met stortingen te maken had. De extra tijd heropende het debat. Een reactie van 23 oktober op de agenda van de volgende testoproep koppelde de stortingswijziging aan het herziene tijdschema, de auteur voegde diezelfde dag stortingsvolgorde-tests toe, en de wijziging werd op 26 oktober samengevoegd.

Wat de nieuwe regel doet

Na de fork volgen builder- en validator-stortingen al aparte paden onder EIP-8282. De oplossing past dezelfde logica toe op de wachtrij bij de fork: opname-credentials, niet de publieke sleutel, bepalen waar elke openstaande storting naartoe gaat.

Hergebruik van één sleutel voor een validator en een builder blijft toegestaan; het in elke storting opgegeven doel bepaalt nu welke account ermee wordt gefinancierd.

Wat er nog moet gebeuren vóór de fork

Het samenvoegen van de specificatie is slechts de eerste stap; client-teams moeten dezelfde regel nu uitrollen. Een Teku-wijziging geopend op 27 oktober stond nog in review, en het equivalent van Lodestar bleef open.

Een late wijziging moet bovendien identiek in elke client terechtkomen. Oudere referentietests coderen de vorige routering, dus een client die de nieuwe regel volgt, zakt ervoor. De auteur van Teku meldt dat hij slaagt voor de tests die zijn gegenereerd uit de bijgewerkte specificatie, die nog niet is verpakt in een specificatiererelease. Als clients de fork bereikten met verschillende regels voor dezelfde wachtrij, zouden ze verschillende saldi berekenen en het oneens zijn over de status van de chain.

De Foundation heeft geen nieuwe Hoodi-datum of Glamsterdam-mainnet-datum vastgesteld. Staking-protocollen die op stortingsbewijzen vertrouwen, hebben ook hun eigen verdedigingslinie: volgens de auteur van het issue kunnen pre-storting-controles die een sleutel afwijzen die al een builder-storting draagt, dit scenario voorkomen. De aandachtspunten van hieraf zijn de twee openstaande client-pull requests, een specificatiererelease die de bijgewerkte tests verpakt, en nieuwe data voor Hoodi en mainnet.