Ethereum-Entwickler haben einen Fix für einen Fehler bei der Behandlung von Einzahlungen im kommenden Glamsterdam-Upgrade zusammengeführt, der es einem Block-Builder ermöglicht hätte, ETH zu erhalten, die für einen neuen Validator bestimmt waren, nachdem zunächst entschieden worden war, die vorgeschlagene Änderung abzulehnen.
Zusammenfassung
- Ethereum hat am 26. Oktober einen Fix für die Behandlung von Einzahlungen in Glamsterdam zusammengeführt.
- Der Fehler hätte Staking-Einzahlungen Buildern gutschreiben können, die denselben öffentlichen Schlüssel teilen.
- Die Entwickler lehnten die Korrektur zunächst ab, bevor sie zusätzliche Tests genehmigten.
- Eine separate Untersuchung zur Vertragskompatibilität hat die Hoodi-Aktivierung von Glamsterdam verzögert.
Laut Ethereums Konsens-Spezifikationen hat Maintainer Justin Traglia die Korrektur am 26. Oktober zusammengeführt, nachdem der Entwickler avsetsin ein Problem damit identifiziert hatte, wie ausstehende Einzahlungen während des Gloas-Forks verarbeitet würden. Die Änderung trennt Builder-Einzahlungen von Validator-Einzahlungen anhand ihrer Withdrawal-Credentials und verhindert, dass Gelder auf dem falschen Konto landen, wenn beide denselben öffentlichen Schlüssel verwenden.
Die Schwachstelle betraf Regeln, die sich in Entwicklung befanden, nicht einen bestätigten Diebstahl aus Ethereums Mainnet. Die Entwickler haben die Korrektur in die Spezifikationen aufgenommen, obwohl einzelne Konsens-Clients das überarbeitete Verhalten noch implementieren und testen müssen.
Ethereum-Glamsterdam-Fehler legte Risiko bei Validator-Einzahlungen offen
Das Problem entstand aus Änderungen, die im Rahmen von Glamsterdams verankerter Proposer-Builder-Trennung geplant waren, welche die Blockkonstruktion und die Blockvorschlagung unterschiedlichen Rollen zuweist. Builder stellen Transaktions-Payloads zusammen, während Validatoren durch Ethereums Proof-of-Stake-System an der Vorschlagung und Bestätigung von Blöcken teilnehmen.
Der Forscher avsetsin beschrieb den Fehler am 12. Oktober und identifizierte ein Problem in den Regeln, die zur Verarbeitung von Einzahlungen verwendet werden, die beim Netzwerk-Upgrade ausstehen. Wenn ein Builder sich mit einem öffentlichen Schlüssel registrierte, bevor eine Validator-Einzahlung unter demselben Schlüssel einging, könnte die vorgeschlagene Logik beide Einzahlungen dem Builder gutschreiben.
Der Forscher skizzierte ein Szenario, in dem ein Staking-Betreiber Gelder von einem Liquid-Staking-Protokoll erhält, um einen neuen Validator einzurichten. Indem er sich zuerst als Builder registriert, könnte der Betreiber bewirken, dass die Validator-Einzahlung des Protokolls in das Builder-Guthaben gelangt, wo die Withdrawal-Adresse unter der Kontrolle des Betreibers stehen könnte.
„Der Betreiber kann die Gelder des Protokolls abheben“, warnte avsetsin in dem GitHub-Bericht.
Da der erwartete Validator nicht erstellt würde, könnte der Staking-Dienst Schwierigkeiten haben, den Nachweis zu erhalten, der für den Abschluss seiner normalen Einzahlungs- und Wiederherstellungsverfahren erforderlich ist.
Der Forscher untersuchte potenzielle Expositionen bei Lido, Origin und Rocket Pool durch vorläufige Code-Recherchen. Diese Ergebnisse waren davon abhängig, wie einzelne Protokolle Einzahlungen handhabten, und der Bericht belegte nicht, dass die Projekte Opfer einer Ausnutzung geworden waren.
Entwickler revidieren Entscheidung nach weiterer Prüfung
Die vorgeschlagene Korrektur stieß zunächst auf Widerstand bei Ethereum-Client-Entwicklern, trotz der Beschreibung des Risikos der Einzahlungsweiterleitung durch den Forscher. Am 19. Oktober schloss Traglia den Pull-Request nach Diskussionen unter den Kernentwicklern.
„Es gab zu diesem Zeitpunkt nicht genügend Unterstützung von den Clients, um diese Änderung vorzunehmen“, schrieb Traglia.
Die Entscheidung blieb nicht bestehen, da die Entwickler den Vorschlag am 23. Oktober nach weiterer Prüfung wieder öffneten.
Anschließend genehmigte der Reviewer potuz den Ansatz, forderte jedoch mehr Tests für bestimmte Einzahlungskombinationen. Avsetsin fügte diese Tests am 23. Oktober hinzu und deckte Fälle ab, in denen Builder- und Validator-Einzahlungen einen öffentlichen Schlüssel teilen, aber eine getrennte Behandlung erfordern.
Die endgültige Änderung wurde am 26. Oktober nach weiterer Client-Prüfung in Ethereums Konsens-Spezifikationen zusammengeführt. Sie leitet gültige Validator-Einzahlungen in die Validator-Warteschlange und ermöglicht es legitimen Builder-Einzahlungen, sich zu registrieren oder einem bestehenden Builder Gelder hinzuzufügen.
Die neuen Regeln unterscheiden Einzahlungen anhand von Withdrawal-Credentials, welche die zulässigen Abhebungsvereinbarungen bestimmen. Sie bewahren getrennte Builder- und Validator-Datensätze, selbst wenn derselbe öffentliche Schlüssel in beiden Rollen erscheint.
Hoodi-Verzögerung gibt Entwicklern mehr Zeit für Untersuchungen
Die Spezifikationsaktualisierung traf ein, während Ethereum-Entwickler ein separates Problem untersuchten, das die geplante Aktivierung von Glamsterdam im Hoodi-Testnetz betraf. Die Ethereum Foundation verschob das Upgrade vom 26. Oktober, nachdem Forscher Kompatibilitätsrisiken im Zusammenhang mit EIP-8037 identifiziert hatten.
Wie crypto.news zuvor über die Verschiebung berichtete, entfernte die Entscheidung sowohl die Amsterdam-Ausführungsänderungen als auch die Gloas-Konsensänderungen aus der geplanten Aktivierung von Hoodi. Die vorgeschlagene Erhöhung auf ein Gaslimit von 200 Millionen wurde ebenfalls verschoben.
Der Ethereum-Forscher Toni Wahrstätter erklärte, dass EIP-8037 mit Smart Contracts interferieren könnte, die auf Annahmen über das während der Ausführung verbleibende Gas beruhen. Er identifizierte Fälle, in denen die Gasabrechnung dazu führen könnte, dass eine Transaktion unerwartet zurückgesetzt wird oder ein Ausführungspfad ermöglicht wird, den Entwickler als unerreichbar angenommen hatten.
Das Vertragskompatibilitätsproblem unterscheidet sich von dem Builder-Einzahlungsfehler, der in der GitHub-Korrektur behandelt wurde. Beide betreffen Glamsterdam, doch die Verschiebung der Foundation vom 22. Oktober nannte ausdrücklich die weitere Untersuchung der Interaktion von EIP-8037 mit bestehenden Verträgen.
Ethereum-Clients müssen die überarbeiteten Regeln implementieren
Glamsterdam wurde bereits am 6. Oktober im Sepolia-Testnetz aktiviert, wo Entwickler Änderungen an der Blockkonstruktion und eine höhere Transaktionsverarbeitungskapazität untersuchten. Die anschließende Hoodi-Probe bleibt ungeplant, ohne bestätigtes Datum für die Aktivierung im Ethereum-Mainnet.
Die zusammengeführte Einzahlungskorrektur enthält Regressionstests, die abdecken, wie Einzahlungen während des Gloas-Übergangs klassifiziert werden. Client-Teams müssen die Spezifikationsänderung in ihre Software integrieren und weitere Tests abschließen, bevor die aktualisierten Regeln während eines zukünftigen Netzwerk-Upgrades wirksam werden können.
