Ethereum wijzigt Glamsterdam-regels na ontdekt risico voor stakingstortingen
Ether bedoeld voor een nieuwe validator kon onder de eerdere Glamsterdam-regels bij een blockbuilder terechtkomen. Ethereum-ontwikkelaars hebben die fout nu uit de toekomstige specificatie gehaald.
Dat is geen reparatie van een actief mainnetlek. Glamsterdam draait nog niet op Ethereum-mainnet en er is geen bevestigde diefstal via deze fout.
Het incident laat juist zien waarvoor testfases bestaan: een gevaarlijke interactie werd gevonden voordat de regels naar mainnet gingen.
Builder en validator konden dezelfde sleutel gebruiken
Glamsterdam verandert de manier waarop Ethereum blokken laat bouwen.
Een belangrijk onderdeel is enshrined proposer-builder separation. Builders stellen daarbij blokken samen, terwijl validators ETH vastzetten en andere taken uitvoeren rond het goedkeuren van blokken.
Builders en validators krijgen afzonderlijke registraties.
Het probleem ontstond tijdens de overgang naar die nieuwe regels.
Een builder en validator konden dezelfde publieke sleutel gebruiken, terwijl hun stortingen eigenlijk voor verschillende rollen waren bedoeld.
Eerste storting kon bepalen waar latere ETH terechtkwam
Onderzoeker avsetsin beschreef het probleem op 12 oktober.
Stel dat een operator eerst een geldige builderstorting doet met een bepaalde publieke sleutel.
Daarna stuurt een stakingdienst ETH om onder dezelfde sleutel een validator te starten.
Onder de eerdere overgangsregels kon die tweede storting niet als validatorstorting worden behandeld.
De ETH kon in plaats daarvan aan de al geregistreerde builder worden toegevoegd.
Daarmee verschoof geld van de bedoelde validatorroute naar een andere rol.
Opnamegegevens werden onvoldoende meegenomen
Het verschil tussen beide stortingen was wel zichtbaar.
Ethereum gebruikt zogenoemde withdrawal credentials. Die gegevens bepalen onder meer hoe geld later kan worden opgenomen en welk type storting wordt verwerkt.
Builderstortingen gebruiken binnen de nieuwe opzet een andere vorm dan gewone validatorstortingen.
De oude overgangslogica keek daar niet streng genoeg naar zodra onder dezelfde publieke sleutel al een builder bestond.
Latere stortingen konden daardoor bij die builder belanden.
Operator kon volgens het scenario de ETH opnemen
Dat maakte de fout financieel relevant.
In het voorbeeld uit de melding betaalt een stakingprotocol voor het starten van een validator.
De operator heeft echter eerder zelf een builder onder dezelfde sleutel geregistreerd.
Als de validatorstorting vervolgens aan de builder wordt toegekend, kan de operator volgens de beschreven situatie toegang krijgen tot geld dat niet voor die builder bedoeld was.
De bedoelde validator wordt dan niet aangemaakt.
Dat is meer dan een administratieve fout.
Het kan betekenen dat geld bij de verkeerde partij terechtkomt.
Geen validator betekent ook geen normaal bewijs
Voor sommige stakingdiensten ontstaat daarna nog een tweede probleem.
Zij controleren pas na de eerste storting of de nieuwe validator daadwerkelijk bestaat en de juiste opnamegegevens heeft.
Dat bewijs kan bepalen of de rest van de benodigde stake wordt vrijgegeven.
Maar als de validator door de fout nooit wordt aangemaakt, bestaat dat record niet.
Het protocol kan dan ook het bewijs missen waarop zijn normale controle- of herstelroute vertrouwt.
Welke gevolgen dat precies heeft, hangt af van het ontwerp van de stakingdienst.
Genoemde stakingprotocollen waren geen bevestigde slachtoffers
De oorspronkelijke melding onderzocht mogelijke gevolgen voor verschillende stakingprotocollen.
Daarbij werden onder meer scenario's rond Lido, Origin en Rocket Pool bekeken.
Die analyse was nadrukkelijk conditioneel.
De onderzoeker waarschuwde zelf dat delen met AI waren onderzocht, onvolledig konden zijn en niet bewezen dat de beschreven protocollen daadwerkelijk konden worden aangevallen.
Er is dus geen basis om uit deze issue te concluderen dat deze stakingdiensten geld hebben verloren.
Het probleem zat in de toekomstige Ethereum-regels.
Eerste reparatie kreeg onvoldoende steun
Opvallend is dat de uiteindelijke oplossing niet direct werd aangenomen.
De voorgestelde wijziging lag al op tafel kort nadat het probleem was gemeld.
Op 19 oktober werd de pull request echter gesloten.
Volgens Ethereum-ontwikkelaar Justin Traglia was er na overleg nog onvoldoende steun onder clientteams om de wijziging op dat moment door te voeren.
Dat laat zien dat ook een ogenschijnlijk duidelijke beveiligingsfix andere protocolgevolgen kan hebben.
Een wijziging moet niet alleen het gevonden probleem oplossen.
Zij mag geen nieuwe overgangsfouten introduceren.
Uitstel van Hoodi gaf extra tijd
Daarna veranderde de planning van Glamsterdam.
De Ethereum Foundation stelde op 22 oktober de geplande Hoodi-activatie uit.
De reden daarvoor was een ander probleem: ontwikkelaars wilden de wisselwerking tussen EIP-8037 en bestaande smart contracts verder onderzoeken.
Dat uitstel stond los van het probleem met stakingstortingen.
Het gaf de teams wel extra tijd om opnieuw naar de builder- en validatorlogica te kijken.
Voorstel werd op 23 oktober heropend
Een dag na het Hoodi-uitstel werd de eerdere reparatie opnieuw geopend.
Ontwikkelaars voegden verdere tests toe.
Daarbij werden verschillende volgordes van builder- en validatorstortingen gecontroleerd.
Ook werd onderzocht of de wijziging onverwachte gevolgen had voor andere depositroutes.
Na aanvullende reviews kreeg het voorstel alsnog steun.
Op 26 oktober werd het in de officiële consensus-specificaties samengevoegd.
Withdrawal credentials bepalen nu de route
De nieuwe regel maakt de scheiding explicieter.
Een validatorstorting blijft in de validatorwachtrij, ook wanneer onder dezelfde publieke sleutel al een builder bestaat.
Een geldige builderstorting kan juist een builder registreren of diens saldo verhogen.
De routing hangt daarmee sterker af van de withdrawal credentials van de storting.
Dat voorkomt precies het scenario waarin validator-ETH door een eerdere builderregistratie wordt opgeslokt.
Specificatie aangepast betekent nog niet overal software aangepast
Een merge op GitHub is alleen de eerste stap.
De consensus-specificaties beschrijven hoe Ethereum zich na de upgrade moet gedragen.
Clientontwikkelaars moeten die regels vervolgens correct in hun eigen software verwerken.
Daarna volgen tests tussen verschillende clients.
Pas daarna kan een toekomstige netwerkactivatie de aangepaste regels daadwerkelijk afdwingen.
De merge van 26 oktober betekent dus niet dat Ethereum-mainnet die fix nu heeft gekregen.
Mainnet gebruikte de kwetsbare Glamsterdam-regels überhaupt nog niet.
Glamsterdam heeft nog geen nieuwe Hoodi-datum
Hoodi zou aanvankelijk op 26 oktober naar Glamsterdam gaan.
Die planning is geschrapt.
De Ethereum Foundation heeft nog geen vervangende datum gepubliceerd.
Ook voor mainnet staat nog geen definitieve activatiedatum vast.
Mainnetgebruikers en ETH-houders hoeven vanwege het Hoodi-uitstel volgens de Foundation momenteel niets te doen.
De komende testfase moet eerst aantonen dat de gewijzigde regels correct door verschillende clients worden uitgevoerd.
Dit was geen stakinghack op Ethereum-mainnet
Daarmee is ook de belangrijkste claimgrens duidelijk.
Er is geen bewijs dat een aanvaller via deze Glamsterdam-fout ETH van mainnetstakers heeft gestolen.
De kwetsbare logica hoorde bij de overgang naar toekomstige Gloas-regels.
De ontdekking ging over wat zou kunnen gebeuren wanneer die regels zo werden geactiveerd.
Dat is wezenlijk anders dan een actief lek in het huidige stakingmechanisme.
Toch was het financiële risico concreet genoeg
Dat de fout vóór mainnet is gevonden, maakt hem niet onbelangrijk.
Stakingdiensten kunnen grote bedragen sturen op basis van protocolregels en cryptografische controles.
Wanneer een overgangsregel een storting bij de verkeerde rol boekt, kan de software technisch doen wat de specificatie zegt en financieel toch het verkeerde resultaat produceren.
Daarom is de fix relevant voordat er echt geld onder die nieuwe regels werkt.
De fout zat niet in een gestolen privésleutel.
Hij zat in de vraag welke rekening een geldige storting kreeg toegewezen.
Hoodi moet nu twee aparte dossiers verwerken
Voor Glamsterdam lopen daarmee minstens twee verschillende aandachtspunten naast elkaar.
Het builder- en validatorprobleem heeft nu een aangepaste specificatie.
Het onderzoek rond EIP-8037 was de reden om Hoodi op 22 oktober uit te stellen.
Die dossiers moeten niet worden samengevoegd alsof één bug de hele vertraging veroorzaakte.
Ethereum heeft voor Hoodi nog geen nieuwe activatiedatum aangekondigd.
Dat geeft ontwikkelaars tijd om beide soorten wijzigingen verder te testen voordat de volgende stap wordt gezet.
De fix is binnen, de echte test volgt nog
De gevaarlijke routingregel is nu gewijzigd.
Validatorstortingen moeten tijdens de overgang validatorstortingen blijven, zelfs wanneer dezelfde publieke sleutel ook door een builder wordt gebruikt.
Maar de belangrijkste fase komt nog.
Clientteams moeten aantonen dat zij dezelfde regel correct uitvoeren en dat de nieuwe scheiding geen onverwachte neveneffecten veroorzaakt.
Voor Ethereum-mainnet is voorlopig vooral één feit relevant:
het probleem werd gevonden voordat Glamsterdam daar live ging.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
