Ethereum-Spezifikation: Gloas-Fork schreibt Validator-Einlagen keinen Buildern mehr gut
Victoria Shinder1 Min. LesezeitEthereums Konsensspezifikation wurde geändert, um ein Szenario fehlgeleiteter Gelder beim Gloas-Fork zu schließen, der Konsensschicht-Hälfte des Upgrades Glamsterdam. Issue 5735 im Repository consensus-specs beschrieb, wie der Onboarding-Schritt des Forks eine von einer Partei bezahlte Validator-Einlage einem Builder gutschreiben konnte, den eine andere Partei kontrolliert; Pull Request 5736, eröffnet am 12. Oktober, behob das und wurde am 26. Oktober übernommen.
Ursache war eine Weiterleitungsregel: Sobald eine ausstehende Einlage einen Builder registrierte, füllten spätere Einlagen für denselben öffentlichen Schlüssel diesen Builder auf, unabhängig von ihren Auszahlungsdaten; eine Validator-Einlage verschwand so aus der Validator-Warteschlange und landete im Builder-Guthaben. Das Issue nennt ein Beispiel: Ein Staking-Protokoll finanziert die erste Validator-Einlage eines Betreibers und verlangt vor weiteren Zahlungen den Nachweis, dass der Validator die Auszahlungsadresse des Protokolls trägt. Stellt der Betreiber zuvor eine Builder-Einlage für denselben neuen Schlüssel in die Warteschlange, gehen beim Fork beide Beträge an den Builder, und der Betreiber kann die Mittel des Protokolls abziehen. Ein Validator-Eintrag entsteht nicht, was auch den Rückweg des Protokolls blockieren kann.
Die Korrektur leitet ausstehende Einlagen beim Fork nach Auszahlungsdaten weiter. Validator-Einlagen bleiben in der Validator-Warteschlange, auch wenn ein Builder denselben Schlüssel nutzt; eine gültige Builder-Einlage registriert oder füllt den Builder auf; eine Builder-Einlage für einen bestehenden Builder füllt ihn unabhängig von der Signatur auf; und eine ungültige Builder-Einlage ohne Builder wird verworfen, außer es existiert ein Validator mit diesem Schlüssel oder eine gültige Validator-Einlage ist eingereiht. Regressionstests kamen hinzu; drei Testfälle wurden umbenannt, vier erfordern nun BLS.
Was das bedeutet
Den Fehler gab es nur während des einmaligen Fork-Übergangs — genau in dem Code, der vor dem Einsatz im Mainnet am wenigsten echte Belastung erfährt. Betroffen gewesen wären Staking-Protokolle, die Einlagen von Betreibern vorfinanzieren; die Korrektur kam vor der Aktivierung, nicht nach einem Verlust.