Wichtiger Ethereum (ETH) Fehler könnte endlich behoben sein - U.Today

Angriff auf den Validator-Pubkey-Cache

Einer der Konsens-Clients von Ethereum hat einen Fix für einen Angriff auf den Validator-Pubkey-Cache implementiert, wie aus einem Pull-Request auf GitHub hervorgeht. Der Patch behebt eine Schwachstelle im Zusammenhang mit dem Gloas-Fork, die dazu führen könnte, dass einige Knoten gültige Signaturen aufgrund eines Fehlers im globalen Pubkey-Cache ablehnen. Gloas ist der Teil der Konsensschicht des bevorstehenden Glamsterdam-Upgrades.

Mechanismus des Angriffs

Das Problem liegt in einem Mechanismus, bei dem der Client die öffentlichen Schlüssel der Validatoren und deren Indizes in einem globalen Cache speichert. Technisch gesehen sollten Einzahlungen, die bereits finalisiert sind, die gleichen Validatoren auf jeder Kette ergeben, obwohl es an der Fork-Grenze zu Abweichungen kommen kann. Der Angreifer benötigt drei ausstehende Einzahlungen kurz vor der Fork: die erste ist eine große Aufladung für einen bestehenden Validator, während die anderen beiden neue Schlüssel sind: A mit Builder-Berechtigungen und B mit regulären Validator-Berechtigungen.

Folgen des Angriffs

Auf der kanonischen Kette verbraucht die Aufladung den Balance-Churn, sodass A und B nach der Fork verarbeitet werden. A wird ein Builder, und B erhält den nächsten Validator-Index. Auf der Seitenkette des Angreifers wird der aufgeladene Validator vor der Fork bestraft, und seine Einzahlung wird übersprungen. Dies führt dazu, dass A früher verarbeitet wird und im Wesentlichen Bs Index übernimmt. Der fehlerhafte Cache nahm fälschlicherweise an, dass beide Ketten die gleichen Validatoren produzieren würden und importierte As Schlüssel global. An der Fork würden betroffene Knoten alle gültigen Signaturen von B auf der kanonischen Kette ablehnen und abspalten.

Komplexität des Angriffs

Realistisch betrachtet ist der Angriff jedoch etwas kompliziert, da er eine Bestrafung im richtigen Moment und eine Seitenkette erfordert, sodass es unwahrscheinlich ist, dass er zufällig passiert. Laut dem Pull-Request besteht die Lösung darin, Schlüssel nur zum globalen Pubkey-Cache hinzuzufügen, sobald deren Aktivierungsberechtigungs-Epoche finalisiert ist. Eine neue HeadPubkeys-Struktur kombiniert auch Schlüssel aus dem Head-State und dem globalen Cache, sodass Knoten Schlüssel nicht verpassen, wenn die Kette ohne neue Blöcke finalisiert.

Ausblick

Ob andere Konsens-Clients ein ähnliches Problem hatten, muss noch bestätigt werden. Mit anderen Worten, je näher das Glamsterdam-Upgrade rückt, desto mehr Randfälle rund um die Fork-Grenze müssen die Entwickler berücksichtigen.