Ethereum Foundation wirbt für Transaktions-Assertions, die bei falschem Ergebnis zurückrollen
Victoria Shinder2 Min. LesezeitDie Trillion-Dollar-Security-Initiative der Ethereum Foundation hat am 5. Oktober ihre Argumente für native Transaktions-Assertions veröffentlicht: Regeln, die zusammen mit einer Transaktion signiert werden, deren Endergebnis prüfen und sie zurückrollen, wenn das Ergebnis nicht dem entspricht, was der Nutzer akzeptiert hat.
Das Problem. Ethereum führt genau das aus, was signiert wurde, und eine Signatur bindet an eine Anfrage, nicht an deren Ergebnis. Der Beitrag unterscheidet zwei Fehlerarten. Bei einem Absichtsfehler zeigt ein kompromittiertes Frontend eine Anfrage, während der Nutzer eine andere freigibt – wie bei Bybit und BadgerDAO. Bei einem Ergebnisfehler gibt der Nutzer die richtige Anfrage frei, doch der Zustand, auf den sie trifft, führt zu einem Ergebnis, das er nicht akzeptiert hätte: Bei einem Collateral-Swap über Aave und CoW tauschte ein Nutzer rund 50,4 Mio. USD in aEthUSDT und erhielt Token im Wert von etwa 36.000 USD, nachdem er eine Warnung vor 99,9 % Preiseinfluss bestätigt hatte.
Warum bestehende Schutzmechanismen nicht reichen. Clear Signing erklärt die Anfrage, hängt aber von korrekter Dekodierung ab; Simulation sagt Wirkungen für einen gewählten Zustand voraus, der sich ändern kann – im Fall Radiant Capital tauschte Schadsoftware die Nutzlast beim Signieren aus. Vertragsprüfungen wie amountOutMinimum bei Uniswap oder der Guard checkAfterExecution bei Safe greifen, aber nur für vorab gewählten Zustand; keine kann die EVM fragen, was sich sonst noch geändert hat.
Der Vorschlag. EIP-7906 baut auf den Frame-Transaktionen aus EIP-8141 auf und ergänzt am Ende einen schreibgeschützten POST_TX-Frame. Drei neue Opcodes legen das Ergebnis offen: TXTRACE zählt Netto-Zustandsänderungen und Events auf, TXDIFF liefert Anfangs- und Endwerte für bestimmte Adressen und Slots, EVENTDATACOPY kopiert Event-Daten in den Speicher. Änderungen sind netto: Ein fünfmal geschriebener Slot erscheint einmal, ein auf den Ausgangswert zurückgesetzter gar nicht. Schlägt die Assertion fehl, wird die Ausführung zurückgerollt, die Transaktion bleibt aber als fehlgeschlagen im Block und der Gaszahler zahlt – so können Angreifer Builder nicht kostenlos fehlschlagende Transaktionen ausführen lassen.
Grenzen, die die Autoren nennen. Eine Assertion ist nur so gut wie ihre Quelle; ein kompromittiertes Frontend kann eine schreiben, die den Angriff erlaubt. EIP-7906 macht Assertions nicht verpflichtend, und ein bereits bereitgestellter unveränderlicher Vertrag kann sie nicht nachträglich verlangen. EIP-8141 ist für das Upgrade Hegotá vorgesehen; EIP-7906 ist "Considered for Inclusion", aber nicht bestätigt.