Fehlerbehebung im Ethereum Glamsterdam-Upgrade
Die Ethereum-Entwickler haben einen kritischen Fehler in der Einzahlungsverwaltung im bevorstehenden Glamsterdam-Upgrade behoben. Dieser Fehler hätte es einem Blockbauer ermöglicht, ETH zu erhalten, die für einen neuen Validator bestimmt waren, nachdem eine anfängliche Entscheidung getroffen wurde, die vorgeschlagene Änderung abzulehnen. Laut den Konsensspezifikationen von Ethereum hat der Maintainer Justin Traglia die Korrektur am 26. Oktober zusammengeführt, nachdem der Entwickler avsetsin ein Problem mit der Verarbeitung ausstehender Einzahlungen während des Gloas-Forks identifiziert hatte.
Änderungen zur Fehlervermeidung
Die Änderung trennt die Einzahlungen von Blockbauern von den Einzahlungen der Validatoren gemäß ihren Abhebungsberechtigungen. Dadurch wird verhindert, dass Gelder auf das falsche Konto gelangen, wenn beide dasselbe öffentliche Schlüssel verwenden. Die Schwachstelle betraf Regeln, die sich in der Entwicklung befanden, und nicht einen bestätigten Diebstahl aus dem Ethereum-Hauptnetz. Die Entwickler haben die Korrektur in die Spezifikationen aufgenommen, obwohl einzelne Konsens-Clients die überarbeitete Funktionalität noch implementieren und testen müssen.
Ursprung des Problems
Das Problem entstand aus Änderungen, die im Rahmen der im Glamsterdam verankerten Trennung von Vorschlagenden und Blockbauern geplant waren. Diese Trennung weist den Blockbau und den Blockvorschlag verschiedenen Rollen zu. Blockbauer stellen Transaktionspayloads zusammen, während Validatoren am Vorschlagen und Bestätigen von Blöcken durch das Proof-of-Stake-System von Ethereum 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 während des Netzwerk-Upgrades warten.
„Der Betreiber kann die Gelder des Protokolls abheben“, warnte avsetsin im GitHub-Bericht.
Da der erwartete Validator nicht erstellt würde, könnte der Staking-Dienst Schwierigkeiten haben, den Nachweis zu erbringen, der erforderlich ist, um seine normalen Einzahlungs- und Wiederherstellungsverfahren abzuschließen.
Untersuchung und Widerstand
Der Forscher untersuchte potenzielle Expositionen, die Lido, Origin und Rocket Pool durch vorläufige Codeforschung betreffen. Diese Ergebnisse hingen davon ab, wie einzelne Protokolle Einzahlungen handhabten, und der Bericht stellte nicht fest, dass die Projekte einen Exploit erlitten hatten. Die vorgeschlagene Korrektur stieß zunächst auf Widerstand von Ethereum-Client-Entwicklern, trotz der Beschreibung des Einzahlungs-Routing-Risikos durch den Forscher. Am 19. Oktober schloss Traglia die Pull-Anfrage nach Diskussionen unter den Kernentwicklern.
„Es gab nicht genug Unterstützung von den Clients, um diese Änderung zu diesem Zeitpunkt vorzunehmen“, schrieb Traglia.
Die Entscheidung blieb jedoch nicht bestehen, da die Entwickler den Vorschlag am 23. Oktober nach weiterer Prüfung wieder eröffneten. Anschließend genehmigte der Prüfer potuz den Ansatz, forderte jedoch weitere Tests für spezifische Einzahlungskombinationen. Avsetsin fügte diese Tests am 23. Oktober hinzu, die Fälle abdeckten, in denen Blockbauer- und Validator-Einzahlungen ein öffentliches Schlüssel teilen, aber eine separate Handhabung erfordern.
Zusammenführung der Änderungen
Die endgültige Änderung wurde am 26. Oktober nach weiterer Überprüfung durch die Clients in die Konsensspezifikationen von Ethereum zusammengeführt. Sie leitet gültige Validator-Einzahlungen in die Validator-Warteschlange, während sie legitimen Blockbauer-Einzahlungen erlaubt, sich zu registrieren oder Gelder zu einem bestehenden Blockbauer hinzuzufügen.
Die neuen Regeln unterscheiden Einzahlungen durch Abhebungsberechtigungen, die die zulässigen Abhebungsvereinbarungen bestimmen. Sie bewahren separate Aufzeichnungen für Blockbauer und Validatoren, selbst wenn dasselbe öffentliche Schlüssel in beiden Rollen erscheint.
Zusätzliche Probleme und Verschiebungen
Das Spezifikationsupdate kam, während die Ethereum-Entwickler ein separates Problem überprüften, 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 Ausführungsänderungen von Amsterdam als auch die Konsensänderungen von Gloas aus der geplanten Aktivierung von Hoodi. Die vorgeschlagene Erhöhung auf ein Gaslimit von 200 Millionen wurde zusammen mit ihnen verschoben.
Der Ethereum-Forscher Toni Wahrstätter erklärte, dass EIP-8037 mit Smart Contracts interferieren könnte, die auf Annahmen über verbleibendes Gas während der Ausführung basieren. Er identifizierte Fälle, in denen die Gasabrechnung dazu führen könnte, dass eine Transaktion unerwartet zurückgesetzt wird oder einen Ausführungsweg ermöglicht, von dem die Entwickler angenommen hatten, dass er unerreichbar sei.
Das Problem der Vertragskompatibilität ist von dem Blockbauer-Einzahlungsfehler, der in der GitHub-Korrektur behandelt wurde, zu unterscheiden. Beide betreffen Glamsterdam, aber die Verschiebung der Foundation am 22. Oktober nannte speziell die weitere Untersuchung der Interaktion von EIP-8037 mit bestehenden Verträgen.
Glamsterdam wurde bereits am 6. Oktober im Sepolia-Testnetz aktiviert, wo die Entwickler Änderungen beim Blockbau und eine höhere Transaktionsverarbeitungskapazität untersuchten. Die anschließende Hoodi-Probe bleibt nicht terminiert, ohne ein bestätigtes Datum für die Aktivierung im Ethereum-Hauptnetz.
Die zusammengeführte Einzahlungsänderung enthält Regressionstests, die abdecken, wie Einzahlungen während des Gloas-Übergangs klassifiziert werden. Die Client-Teams müssen die Spezifikationsänderung in ihre Software integrieren und weitere Tests durchführen, bevor die aktualisierten Regeln während eines zukünftigen Netzwerk-Upgrades in Betrieb genommen werden können.
