Ethereum dicht lek in Glamsterdam-upgrade dat staking-stortingen bij builders kon laten belanden

Ethereum heeft een fout uit de Glamsterdam-upgrade gehaald waardoor iemand ETH kon wegsluizen die staking-diensten hadden bedoeld voor nieuwe validators. Opvallend is vooral de route ernaartoe: dezelfde fix werd een week eerder nog afgewezen en kwam er pas door toen een heel ander probleem de planning stillegde.

Twee rollen, één sleutel

Voor wie de techniek niet dagelijks volgt: Glamsterdam knipt twee taken uit elkaar die nu nog samen bij validators liggen. Builders stellen blokken met transacties samen, validators kiezen en bevestigen die blokken en zetten daarvoor ETH vast. Beide partijen kunnen ETH storten en dat geld hoort strikt gescheiden te worden bijgehouden.

Precies daar ging het mis, en wel tijdens de overgang zelf. Op het moment van de fork verwerkt Ethereum stortingen die nog in de wachtrij staan. Onderzoeker avsetsin, die als lid van de GitHub-organisatie van Lido staat vermeld, beschreef hoe een operator zich eerst als builder registreert met een bepaalde publieke sleutel. Stort een staking-dienst daarna ETH om onder diezelfde sleutel een validator te starten, dan zouden de conceptregels beide stortingen aan de builder toekennen. "De operator kan het geld van het protocol opnemen", schreef avsetsin. Omdat er nooit een validator ontstaat, kan de staking-dienst ook niet het bewijs leveren dat nodig is om het geld terug te halen.

Avsetsin keek in wat hij zelf "snel AI-onderzoek" noemde naar mogelijke gevolgen voor Lido, Origin en Rocket Pool, en benadrukte dat het om voorwaardelijke bevindingen in de code gaat en niet om bevestigde aanvallen. Bestaande controles die een eerdere builder-storting weigeren, zouden de aanval kunnen tegenhouden. Volgens een verslag van ChainCatcher bracht Lido-engineeringlead Dmitry Gusakov het risico ook ter sprake in het ontwikkelaarsoverleg ACDC #189, waarbij hij aangaf dat het probleem alleen speelt tijdens de fork-overgang en niet bij gewone stortingen daarna.

Eerst nee, toch ja

Hier wordt het verhaal interessant. Op 19 oktober ging de voorgestelde aanpassing de prullenbak in. "Er was op dit moment niet genoeg steun van clients om deze wijziging door te voeren", schreef Justin Traglia, die de consensusspecificaties van Ethereum onderhoudt. Clients zijn de softwarepakketten waarmee validators aan het netwerk deelnemen. Volgens ChainCatcher speelde de krappe planning rond Sepolia en Hoodi een rol. Het gevolg: de verdediging kwam op het bordje van de staking-protocollen zelf te liggen.

Toen kwam de vertraging. De Ethereum Foundation meldde op 22 oktober dat de geplande Glamsterdam-activatie op testnet Hoodi niet doorging. Core-ontwikkelaars wilden eerst beter onderzoeken hoe EIP-8037 uitpakt voor smart contracts die al op mainnet draaien. Die extra tijd gaf ruimte om de deposit-fix opnieuw te bekijken. Avsetsin voegde op 23 oktober tests toe en Traglia voegde de wijziging maandag samen.

Wat er nu verandert

De nieuwe regels sorteren openstaande stortingen op hun withdrawal credentials, de instelling die bepaalt waar het geld uiteindelijk naartoe kan. Een validator-storting blijft dus bij de validator, ook als een builder dezelfde sleutel gebruikt. Clientteams zijn er al mee bezig: in de GitHub-repository van ChainSafe staat inmiddels een pull request die stortingen bij de Gloas-fork via credentials routeert in plaats van via de publieke sleutel.

Wij vinden het een leerzaam moment. Een upgrade die een nieuwe rol in het protocol introduceert, raakt onvermijdelijk aan aannames waarop staking-diensten hun beveiliging hebben gebouwd. Dat een risico eerst als "niet gepland" wordt weggezet omdat de testkalender krap is, en pas door toeval alsnog wordt opgelost, zegt iets over de druk waaronder dit soort upgrades wordt afgerond. Voor gewone ETH-houders is er geen actie nodig. Glamsterdam heeft wel eerst een nieuwe datum op Hoodi nodig voordat er over mainnet kan worden gesproken.