Die Ethereum Foundation untersucht Transaktionszusicherungen, mit denen Nutzer einer Transaktion durchsetzbare Bedingungen für deren endgültiges Ergebnis hinzufügen könnten, statt sich allein auf die Genehmigung der angeforderten Aktion zu verlassen. Die Forschung ist Teil der Initiative „Trillion Dollar Security“ und zielt auf eine Lücke bei der Transaktionssicherheit: Eine gültige Signatur garantiert nicht, dass die resultierenden Kontostände, Berechtigungen oder Kontrollen über ein Konto den Absichten des Unterzeichners entsprechen.
Wichtige Erkenntnisse
- Die vorgeschlagenen Prüfungen würden Transaktionsergebnisse während der Ausführung bewerten und Aktionen rückgängig machen, die gegen eine signierte Regel verstoßen.
- Der Schutz hängt von Regeln ab, die unabhängig von einem möglicherweise kompromittierten Transaktions-Builder genehmigt wurden.
- Die Forschung könnte Sicherheitsrichtlinien für Wallets, delegierte Agenten und Solver-Workflows unterstützen, stellt aber keine angekündigte Einführung dar.
Inhaltsverzeichnis
- Warum die Genehmigung einer Transaktion dennoch zu einem Verlust führen kann
- Wie Transaktionszusicherungen das Ergebnis prüfen würden
- Welche Informationen die vorgeschlagene Implementierung zugänglich machen würde
- Wo Wallets und Protokolle Änderungen vornehmen müssten
- Was Agenten und Solver-Workflows gewinnen könnten
- Fazit
Warum die Genehmigung einer Transaktion dennoch zu einem Verlust führen kann
Ethereum führt die von einem Nutzer genehmigte Anfrage anhand des Codes und des Zustands aus, die zum Ausführungszeitpunkt verfügbar sind. Diese Bedingungen können von dem abweichen, was der Nutzer geprüft hat. Beispielsweise kann sich die Implementierung eines Proxys vor der Ausführung ändern, während die Reihenfolge von Transaktionen den Preis beeinflussen kann, zu dem ein Swap ausgeführt wird.
Die Foundation unterscheidet zwischen irreführenden Anfragen und unerwünschten Ergebnissen. Bei den Angriffen auf Bybit und BadgerDAO zeigten kompromittierte Frontends den Nutzern Signaturanfragen an, die von dem abwichen, was sie ihrer Meinung nach genehmigten. Umgekehrt kann selbst eine korrekt angezeigte Anfrage ein wirtschaftlich schädliches Ergebnis zulassen.
Als Beispiel nennt sie einen Aave- und CoW-Sicherheiten-Swap mit rund 50,4 Millionen aEthUSDT. Die geringe Liquidität von AAVE und die Gasobergrenze von CoW führten zu einer verifizierten Quote von etwa 329 aEthAAVE. Obwohl eine angezeigte Warnung vor einer Preisauswirkung von 99,9 Prozent darauf hinwies, dass der gesamte Wert verloren gehen könnte, unterzeichnete der Nutzer die Transaktion und erhielt Token im Wert von rund 36.000 US-Dollar.
Diese Unterscheidung erklärt, warum bessere Transaktionsbeschreibungen allein nicht ausreichen. Clear Signing hilft Nutzern, die angeforderte Aktion zu verstehen. Eine Simulation schätzt die Auswirkungen anhand eines ausgewählten Blockchain-Zustands. Beides legt für sich genommen keine unabhängige Bedingung für das tatsächlich eintretende Ergebnis fest.
| Element | Details |
|---|---|
| TXTRACE | Erfasst die Nettozustandsänderungen und ausgegebenen Ereignisse der Transaktion. |
| TXDIFF | Ruft Anfangs- und Endwerte für angegebene Adressen und Speicher-Slots ab. |
| EVENTDATACOPY | Kopiert die Daten eines Ereignisses zur Prüfung in den Speicher. |
| Bereitstellungsinformationen | Die vorgeschlagenen Zustandsänderungsdaten umfassen neu bereitgestellte Verträge und deren Code-Hashes. |
Wie Transaktionszusicherungen das Ergebnis prüfen würden
Eine Zusicherung würde den Anfangs- und Endzustand einer Transaktion mithilfe schreibgeschützter Logik vergleichen, nachdem deren Aktionen ausgeführt wurden. Die Bedingung wäre Bestandteil der Transaktion und zusammen mit den Aktionen zu unterzeichnen. Bei Nichterfüllung würden die Aktionen rückgängig gemacht.
Mögliche Regeln wären ein Mindestbetrag, der eingehen muss, eine Ausgabenobergrenze, Einschränkungen für neue Token-Genehmigungen oder die Wahrung der Kontrolllogik eines Kontos. Die vorgeschlagene Prüfmöglichkeit erstreckt sich über Kontostände hinaus auch auf Speicher, Code, neu bereitgestellte Verträge und ausgegebene Ereignisse.
Bereits bestehende Vertragsprüfungen schützen bestimmte Ergebnisse. Uniswap kann Swaps ablehnen, deren Ausgabemenge unter einem festgelegten Mindestwert liegt, und ein Safe-Guard kann den Kontozustand nach der Ausführung prüfen. Die Einschränkung liegt in der Sichtbarkeit: Solche Prüfungen müssen vorwegnehmen, was untersucht werden soll, und sind in der Regel von den Schnittstellen abhängig, die andere Verträge bereitstellen. Ein Proxy muss beispielsweise keine Funktion anbieten, die seine Implementierungsadresse offenlegt.
Native Zusicherungen würden die vollständigen Nettoeffekte einer Transaktion für Prüfungen verfügbar machen, einschließlich Änderungen, nach denen ein gewöhnlicher Guard möglicherweise nicht suchen würde. Eine umfassendere Sichtbarkeit ist jedoch nur dann nützlich, wenn die Regel vertrauenswürdig ist. Ein böswilliges Frontend könnte eine Bedingung vorgeben, die seinen eigenen Angriff zulässt. Die Richtlinie muss daher auf unabhängig genehmigten Absichten, Kontorichtlinien oder geschützter Protokolllogik beruhen.
Welche Informationen die vorgeschlagene Implementierung zugänglich machen würde
Die Ankündigung der Foundation zu nativen Transaktionszusicherungen beschreibt EIP-7906 als mögliche Implementierung, nicht als endgültig festgelegten Entwurf. Sie baut auf den Frame-Transaktionen in EIP-8141 auf, die Validierungs- und Aktionsschritte in einer geordneten Abfolge anordnen. EIP-8141 ist für Hegotá vorgesehen; EIP-7906 hat den Status „Considered for Inclusion“ erreicht, ist aber für dieses Upgrade nicht bestätigt.
Bei diesem Ansatz würde ein schreibgeschützter POST_TX-Frame die Ergebnisse am Ende der Ausführung prüfen. Die vorgeschlagenen Anweisungen für den Datenzugriff würden nur innerhalb dieses Frames ausgeführt, nicht in der gesamten EVM.
Die Informationen würden Nettoeffekte beschreiben und nicht den Verlauf jeder einzelnen Zwischenspeicherung. Ein mehrfach geänderter Speicher-Slot würde mit seinem Anfangs- und Endwert erscheinen; ein Slot, der auf seinen ursprünglichen Wert zurückgesetzt wird, würde nicht angezeigt. Daher ist die Unterscheidung zwischen der Durchsetzung des Endzustands und der Überwachung jedes Ausführungsschritts wichtig.
Bei einer fehlgeschlagenen Prüfung würde der Ausführungsteil zurückgesetzt, die Transaktion aber als fehlgeschlagen im Block verbleiben. Der Gas-Zahler müsste weiterhin für das verbrauchte Gas aufkommen. So wird verhindert, dass absichtlich fehlschlagende Transaktionen den Buildern kostenlose Ausführungsarbeit aufbürden.
Wo Wallets und Protokolle Änderungen vornehmen müssten
Der Vorschlag stellt einen Prüfmechanismus bereit, schreibt dessen Verwendung aber nicht automatisch vor. Bei den Transaktionen eines Nutzers müsste das Wallet seine Sicherheitsrichtlinie in die Transaktionserstellung einbeziehen, statt dem Builder die Möglichkeit zu lassen, sie wegzulassen. Diese Richtlinie könnte sich aus der eigenen Simulation des Wallets ableiten oder als dauerhafte Kontoregel gelten.
Bei Protokollen müsste der Schutz in die Bedingungen für den Zugriff auf eine geschützte Funktion eingebaut werden. Eine Transaktion zu übermitteln, die Zusicherungen unterstützt, wäre nicht ausreichend: Der Aufruf müsste die konkrete Prüfung enthalten, die das Protokoll verlangt. Dadurch würden sich die Integrationsanforderungen für Aufrufer ändern, während sich bei bereits bereitgestellten unveränderlichen Verträgen diese Zugangskontrolle nicht nachträglich ergänzen ließe.
Diese Abhängigkeiten verdeutlichen den Unterschied zwischen einer potenziell leistungsfähigen EVM-Funktion und einer Garantie für Nutzer. Wirksamer Schutz würde sowohl eine solide Bedingung als auch Software erfordern, die deren Anwendung konsequent sicherstellt.
Was Agenten und Solver-Workflows gewinnen könnten
Delegierte Agenten könnten nicht nur durch Berechtigungen, sondern auch durch die Ergebnisse ihrer Aktionen eingeschränkt werden. Begrenzungen für die Verträge, die ein Agent verwenden darf, oder für seine Ausgaben könnten durch Anforderungen ergänzt werden, die festlegen, was nach jeder Transaktion übrig bleibt.
Bei Solver-basierter Ausführung könnte ein Protokoll ein akzeptables Ergebnis festlegen und dem Solver zugleich die Wahl des Ausführungswegs überlassen. Die Garantie wäre auf eine Transaktion innerhalb eines einzelnen Netzwerks beschränkt und würde keinen Pfad über mehrere Chains hinweg umfassen.
Zusicherungen könnten auch prüfen, ob ein Workflow ordnungsgemäß abgeschlossen wurde, etwa indem nicht verwendete Token zurückgegeben und verbleibende Genehmigungen widerrufen werden. Die Foundation bittet Wallet- und Protokollteams um Rückmeldungen, während der Entwurf weiterentwickelt wird. Diese möglichen Anwendungen sind daher Forschungsrichtungen und keine angekündigten Produktfunktionen.
Fazit
Native Transaktionszusicherungen würden einen Teil der Sicherheit von Ethereum-Transaktionen von der Interpretation einer Anfrage auf die Durchsetzung ihres Ergebnisses verlagern. Ihr praktischer Nutzen hinge von vertrauenswürdigen Richtlinien und der Einführung durch die Wallets und Protokolle ab, die für deren Anwendung zuständig sind.
Weitere Nachrichten lesen
Weitere Nachrichten von FinanceVelix
Haftungsausschluss
Dieser Artikel von FinanceVelix dient der allgemeinen Information und stellt keine individuelle Finanz-, Anlage-, Rechts- oder Steuerberatung dar. Kryptopreise können sich schnell ändern, und Sie könnten Ihr gesamtes investiertes Kapital verlieren. Die Angaben entsprechen dem zum Veröffentlichungszeitpunkt verfügbaren Informationsstand und können sich ändern. Prüfen Sie wichtige Informationen eigenständig und wenden Sie sich bei Bedarf an qualifizierte Fachleute. Die Erwähnung eines Vermögenswerts, Unternehmens oder einer Dienstleistung stellt keine Empfehlung dar.
