Eine am 26. Oktober zusammengeführte Spezifikationsänderung schließt eine Schwachstelle in Ethereums Einzahlungsverarbeitung, die Node-Operatoren ermöglicht hätte, Einzahlungen von Stakern aus der Warteschlange in Guthaben unter ihrer eigenen Kontrolle umzuleiten, sobald das Glamsterdam-Upgrade des Netzwerks aktiviert wird. Der Fix landete im consensus-specs-Repository – den Referenzregeln, die die Ethereum-Client-Teams implementieren – zwei Wochen nachdem die Schwachstelle auf GitHub gemeldet worden war. Nur Einzahlungen, die bei Aktivierung des Forks noch in der Warteschlange standen, hätten fehlgeleitet werden können, und da Glamsterdam das Mainnet noch nicht erreicht hat, gingen keine Gelder verloren.

Wie ein Operator die Einzahlung eines Stakers hätte an sich bringen können

Pooled-Staking-Protokolle teilen sich typischerweise die Arbeit des Betriebs eines Validators. Das Protokoll stellt das ETH bereit, während ein externer Node-Operator den Signing-Key des Validators hält. Ethereum trennt Signing und Withdrawals, sodass ein Operator einen Validator betreiben kann, ohne die Stake des Protokolls abheben zu können.

Glamsterdam kombiniert Execution-Layer-Änderungen mit einem Consensus-Layer-Upgrade namens Gloas und führt Builder als neue Art von Teilnehmer im Rahmen der enshrined proposer-builder separation ein. Builder stellen den transaktionstragenden Teil jedes Blocks zusammen und verwalten eigene Guthaben. Beim Fork wandelt Ethereum qualifizierte Einzahlungen, die noch in der Warteschlange warten, in Builder-Konten um.

In genau dieser Umsetzung lag die Schwach. Nach der alten Regel wurde mit jeder späteren Einzahlung für einen Key, für den bereits eine ausstehende Einzahlung einen Builder registriert hatte, dieses Builder-Guthaben aufgestockt – unabhängig davon, wohin die Withdrawal Credentials verwiesen. Ein Operator konnte für einen neuen Key eine Builder-Einzahlung aus einer von ihm kontrollierten Adresse in die Warteschlange stellen. Wenn das Staking-Protokoll anschließend eine Validator-Einzahlung für denselben Key finanzierte und beide beim Fork noch ausstehend waren, wäre das ETH des Protokolls dem Builder-Guthaben des Operators gutgeschrieben worden, das dieser dann hätte abheben können. Ein Validator wäre zudem gar nicht erst erstellt worden. Einige Protokolle geben den Rest einer Stake erst frei, nachdem nachgewiesen wurde, dass ein neuer Validator deren Withdrawal Credentials trägt – und dieser Nachweis wäre nie eingegangen.

In einem Folgekommentar listete der Autor des Issues Designs auf, die der Fehler hätte stören können: Lidos Predeposit Guarantee, Origins OETH und Rocket Pools Saturn – wobei er die Liste als schnelle, KI-gestützte Recherche kennzeichnete, die Fehler enthalten kann. In jedem Fall wäre die Exposition eine erste Einzahlung gewesen – im Beispiel von Lido und Rocket Pool 1 ETH – während der Rest der Stake bis zum Durchlauf von Wiederherstellungsschritten gesperrt geblieben wäre. Der Autor bezeichnete diese als bedingte Code-Findings, nicht als aktive Exploits.

Am 19. Oktober abgelehnt, eine Woche später zusammengeführt

Der Fix wurde am 12. Oktober vorgeschlagen. Nach Diskussionen auf zwei Core-Developer-Calls wurde er am 19. Oktober aufgrund fehlender Client-Unterstützung geschlossen, und der Testing-Call schlug vor, einen Prototyp erst nach dem Hoodi-Testnet-Upgrade zu erstellen, statt den Zeitplan zu stören.

Drei Tage später verschob die Ethereum Foundation die Aktivierung von Glamsterdam auf Hoodi, um zu untersuchen, wie EIP-8037 mit bestehenden Smart Contracts interagiert – ein Problem, das nichts mit Einzahlungen zu tun hat. Die zusätzliche Zeit belebte die Debatte neu. Ein Kommentar vom 23. Oktober auf der Agenda des nächsten Testing-Calls verknüpfte die Einzahlungsänderung mit dem überarbeiteten Zeitplan, der Autor fügte am selben Tag Tests zur Einzahlungsreihenfolge hinzu, und die Änderung wurde am 26. Oktober zusammengeführt.

Was die neue Regel bewirkt

Nach dem Fork nehmen Builder- und Validator-Einzahlungen unter EIP-8282 bereits getrennte. Der Fix wendet dieselbe Logik auf die Warteschlange zum Zeitpunkt des Forks an: Die Withdrawal Credentials – nicht der Public Key – entscheiden, wohin jede ausstehende Einzahlung geht.

Die Wiederverwendung eines Keys für einen Validator und einen Builder ist weiterhin erlaubt; der in jeder Einzahlung angegebene Zweck entscheidet nun, welches Konto damit finanziert wird.

Was vor dem Fork noch geschehen muss

Die Zusammenführung der Spezifikation ist nur der erste Schritt; die Client-Teams müssen dieselbe Regel nun ausliefern. Eine Teku-Änderung, die am 27. Oktober eingereicht wurde, befand sich noch in Überprüfung, und Lodestars Äquivalent war weiterhin offen.

Eine späte Änderung muss zudem in jedem Client identisch umgesetzt werden. Ältere Referenztests codieren das bisherige Routing, sodass ein Client, der der neuen Regel folgt, diese nicht besteht. Tekus Autor berichtet, die aus der aktualisierten Spezifikation generierten Tests zu bestehen, die noch nicht in einem Spezifikations-Release verpackt wurden. Würden Clients mit unterschiedlichen Regeln für dieselbe Warteschlange den Fork erreichen, würden sie unterschiedliche Guthaben berechnen und über den Zustand der Chain uneinig sein.

Die Foundation hat weder ein neues Hoodi-Datum noch ein Glamsterdam-Mainnet-Datum festgelegt. Staking-Protokolle, die auf Einzahlungsnachweise setzen, haben zudem eine eigene Verteidigungslinie: Laut dem Autor des Issues können Pre-Deposit-Prüfungen, die einen Key ablehnen, der bereits eine Builder-Einzahlung trägt, dieses Szenario verhindern. Die künftig zu beobachtenden Marker sind die beiden offenen Client-Pull-Requests, ein Spezifikations-Release mit den aktualisierten Tests sowie neue Termine für Hoodi und das Mainnet.