EIP-3074: EOA-Delegation mit AUTH und AUTHCALL

Definition

EIP-3074, oder Ethereum Improvement Proposal 3074, führt zwei neue Opcodes in die Ethereum Virtual Machine (EVM) ein: AUTH und AUTHCALL. Diese sind darauf ausgelegt, die Funktionalität von Externally Owned Accounts (EOAs) zu erweitern. Eine EOA ist die gängigste Art von Ethereum-Konto, das durch einen privaten Schlüssel kontrolliert wird, vergleichbar mit einem traditionellen Bankkonto, bei dem man die Schlüssel besitzt. Im Gegensatz zu Smart-Contract-Konten fehlte EOAs historisch die Fähigkeit, komplexe Logik auszuführen oder die Kontrolle über ihre Vermögenswerte an eine andere Entität zu delegieren. EIP-3074 behebt diese Einschränkung, indem es einer EOA ermöglicht, ihre Kontrolle vorübergehend an einen Smart Contract, den sogenannten "Invoker", zu delegieren. Diese Delegation erlaubt es dem Invoker-Vertrag, Transaktionen im Namen der EOA zu initiieren, wodurch EOAs effektiv einige fortgeschrittene Funktionen nachahmen können, die typischerweise mit Smart-Contract-Wallets verbunden sind, ohne dass der EOA-Inhaber einen neuen Vertrag bereitstellen oder Gelder migrieren muss. Die Kernidee besteht darin, Entwicklern einen flexiblen Rahmen für die Entwicklung neuartiger Transaktionsschemata für EOAs zu bieten und so die Lücke zwischen der Einfachheit von EOAs und der Programmierbarkeit von Smart Contracts zu schließen.

EIP-3074: Ein Ethereum Improvement Proposal, das die Opcodes AUTH und AUTHCALL einführt, um Externally Owned Accounts (EOAs) die Delegation der Transaktionskontrolle an einen Smart Contract zu ermöglichen.

Kernaussage

Die grundlegende Kernaussage von EIP-3074 ist seine Fähigkeit, bestehende Externally Owned Accounts (EOAs) mit Funktionen auszustatten, die traditionell Smart-Contract-Wallets vorbehalten waren. Dies bedeutet, dass eine EOA durch eine signierte Autorisierung einem bestimmten Smart Contract erlauben kann, in ihrem Namen Aktionen auszuführen, wie das Senden von Transaktionen, die Interaktion mit anderen Verträgen oder sogar die Bezahlung von Gasgebühren für die EOA. Diese Delegation verbessert die Benutzererfahrung auf Ethereum erheblich, indem sie Funktionen wie Gas-Sponsoring, Batch-Transaktionen und benutzerdefinierte Transaktionslogik direkt von einer EOA aus ermöglicht, während die ursprüngliche Adresse und die Kontrolle über den privaten Schlüssel der EOA erhalten bleiben. Es stellt einen bedeutenden Schritt hin zu einem flexibleren und benutzerfreundlicheren Account-Abstraction-Modell auf Ethereum dar, ohne Benutzer dazu zu zwingen, ihre bestehende EOA-Infrastruktur aufzugeben.

Mechanik

EIP-3074 funktioniert durch die Einführung von zwei spezifischen EVM-Opcodes: AUTH (0xf6) und AUTHCALL (0xf7). Der Prozess beginnt damit, dass der Inhaber einer EOA eine Nachricht signiert, die einen bestimmten "Invoker"-Smart-Contract ermächtigt, in seinem Namen zu handeln. Diese Signatur ist entscheidend, da sie die Absicht der EOA, die Kontrolle zu delegieren, kryptografisch beweist. Die signierte Nachricht enthält typischerweise die Adresse des Invoker-Vertrags und eine Nonce, um Replay-Angriffe zu verhindern.

Sobald die EOA diese gültige Signatur bereitgestellt hat, kann der Invoker-Vertrag den AUTH-Opcode verwenden. Der AUTH-Opcode nimmt die Signatur der EOA und die Adresse des Invokers als Eingaben entgegen. Bei der Ausführung verifiziert AUTH die Signatur anhand der Adresse der EOA und setzt, falls gültig, eine spezielle Kontextvariable namens authorized innerhalb des aktuellen Ausführungsrahmens. Diese authorized-Variable speichert vorübergehend die Adresse der EOA, die die Delegation erteilt hat. Es ist wichtig zu verstehen, dass diese Autorisierung nicht dauerhaft ist; sie ist typischerweise für eine bestimmte Transaktion oder eine Reihe von Transaktionen gültig, die durch die signierte Nachricht definiert sind.

Nach einer erfolgreichen AUTH-Operation kann der Invoker-Vertrag den AUTHCALL-Opcode verwenden. Der AUTHCALL-Opcode funktioniert ähnlich wie der bestehende CALL-Opcode, jedoch mit einem entscheidenden Unterschied: Jeder Aufruf, der mit AUTHCALL getätigt wird, erscheint so, als ob er von der in der authorized-Kontextvariablen gespeicherten Adresse stammt und nicht vom Invoker-Vertrag selbst. Das bedeutet, wenn die EOA "Alice" den Invoker-Vertrag "InvokerX" autorisiert hat, wird jeder von InvokerX initiierte AUTHCALL von anderen Smart Contracts so behandelt, als hätte Alice den Aufruf selbst getätigt. Dieser Mechanismus ermöglicht es dem Invoker, Aktionen wie das Übertragen von Token, die Interaktion mit DeFi-Protokollen oder die Ausführung komplexer mehrstufiger Operationen im Namen von Alice durchzuführen, während die zugrunde liegenden Transaktionen weiterhin Alice's EOA zugeschrieben werden. Die authorized-Variable ist spezifisch für den aktuellen Ausführungsrahmen, was bedeutet, dass verschachtelte Aufrufe unterschiedliche authorized-Konten oder gar kein authorized-Konto haben können, was eine sichere und isolierte Delegationsumgebung bietet.

Trading-Relevanz

EIP-3074 hat mehrere tiefgreifende Auswirkungen auf den Kryptowährungshandel, insbesondere für Benutzer, die auf Externally Owned Accounts (EOAs) angewiesen sind. Einer der bedeutendsten Vorteile ist das Potenzial für Gas-Sponsoring. Mit EIP-3074 kann eine EOA einen Invoker-Vertrag autorisieren, ihre Transaktionsgebühren zu bezahlen. Dies bedeutet, dass Trader potenziell Trades ausführen könnten, ohne ETH für Gas halten zu müssen, da der Invoker (der eine zentralisierte Börse, ein DeFi-Protokoll oder ein spezialisierter Dienst sein könnte) die Kosten übernimmt. Dies senkt die Eintrittsbarriere für neue Benutzer erheblich und optimiert das Trading-Erlebnis, insbesondere in Zeiten hoher Netzwerküberlastung, in denen Gaspreise prohibitiv sein können.

Darüber hinaus erleichtert EIP-3074 Batch-Transaktionen und benutzerdefinierte Transaktionslogik. Stellen Sie sich ein Szenario vor, in dem ein Trader einen Token für die Ausgabe an einer dezentralen Börse (DEX) genehmigen und dann sofort einen Swap ausführen möchte. Derzeit erfordert dies zwei separate Transaktionen, die jeweils Gasgebühren verursachen und eine Benutzerbestätigung erfordern. Mit EIP-3074 könnte eine EOA einen Invoker-Vertrag autorisieren, beide Aktionen in einer einzigen, atomaren Transaktion durchzuführen. Dies spart nicht nur Gasgebühren, sondern verbessert auch die Effizienz und reduziert das Risiko von Front-Running zwischen den Genehmigungs- und Swap-Schritten. Invoker-Verträge könnten auch ausgeklügelte Handelsstrategien implementieren, wie z.B. automatisiertes Rebalancing, Stop-Loss-Orders oder komplexe Arbitrage-Möglichkeiten, die alle im Namen der EOA ausgeführt werden, ohne dass der EOA-Inhaber jeden einzelnen Schritt manuell signieren muss. Dies eröffnet Möglichkeiten für fortgeschrittenes, programmatisches Trading direkt von einer EOA aus und verwischt die Grenzen zwischen traditioneller EOA-Nutzung und den Fähigkeiten von Smart-Contract-basierten Trading-Bots.

Risiken

Obwohl EIP-3074 erhebliche Vorteile bietet, birgt es auch neue Risikovektoren, die Benutzer verstehen müssen. Das primäre Risiko liegt in der Delegation der Kontrolle selbst. Wenn eine EOA eine Nachricht signiert, die einen Invoker-Vertrag autorisiert, gewährt sie diesem Vertrag im Wesentlichen die Fähigkeit, in ihrem Namen zu handeln. Wenn der Invoker-Vertrag bösartig ist oder Schwachstellen enthält, könnte er potenziell die Gelder der EOA abziehen oder unautorisierte Transaktionen ausführen. Benutzer müssen äußerste Vorsicht walten lassen, wenn sie Invoker-Verträge zur Autorisierung auswählen. Es ist von größter Bedeutung, die Kontrolle nur an seriöse, geprüfte und gut verstandene Smart Contracts zu delegieren. Eine einmal übertragene signierte Autorisierung kann vom Invoker verwendet werden, um Aktionen durchzuführen, und das Widerrufen dieser Autorisierung ist möglicherweise nicht so einfach wie das bloße Nicht-Signieren zukünftiger Transaktionen, abhängig vom Umfang der ursprünglichen Autorisierung.

Ein weiteres wichtiges Anliegen ist der Umfang der Autorisierung. Die signierte Nachricht, die AUTH ermöglicht, kann die spezifischen Aktionen definieren, die ein Invoker ausführen darf, oder sie könnte breit gefasst sein und eine umfassende Kontrolle gewähren. Eine schlecht konzipierte oder übermäßig permissive Autorisierung könnte zu unbeabsichtigten Folgen führen. Wenn beispielsweise eine EOA einen Invoker autorisiert, beliebige Mengen eines bestimmten Tokens auszugeben, könnte dieser Invoker potenziell alles ausgeben. Im Gegensatz zu traditionellen Smart-Contract-Genehmigungen (z.B. ERC-20 approve), bei denen ein spezifisches Ausgabenlimit festgelegt wird, kann die Delegation über EIP-3074 umfassender sein. Benutzer müssen die Details der Autorisierungsnachricht, die sie signieren, sorgfältig prüfen und genau verstehen, welche Berechtigungen sie für wie lange erteilen. Die "Alles-oder-Nichts"-Natur der Delegierung der Kontrolle an einen bestimmten Invoker für einen definierten Umfang bedeutet, dass ein einziger Fehler bei der Autorisierung schwerwiegende finanzielle Auswirkungen haben könnte. Daher werden robuste Benutzeroberflächen und eine klare Kommunikation von dApps, die EIP-3074 implementieren, unerlässlich sein, um diese Risiken zu mindern und sicherzustellen, dass Benutzer fundierte Entscheidungen über ihre delegierten Berechtigungen treffen.

Geschichte und Beispiele

EIP-3074 entstand aus dem anhaltenden Streben nach Account Abstraction auf Ethereum, einem langjährigen Ziel, alle Konten wie Smart Contracts verhalten zu lassen, um größere Flexibilität und Programmierbarkeit zu bieten. Historisch hat Ethereum zwischen EOAs (kontrolliert durch private Schlüssel) und Contract Accounts (kontrolliert durch Code) unterschieden. Diese Unterscheidung schuf eine Dichotomie, bei der EOAs einfach, aber begrenzt waren, während Contract Accounts mächtig, aber Bereitstellung und Verwaltung erforderten. EIP-3074, erstmals von Sam Wilson, Matt Garnett und anderen vorgeschlagen, stellt einen protokollbasierten Ansatz dar, um diese Lücke für bestehende EOAs zu schließen. Es wurde parallel zu anderen Account-Abstraction-Bemühungen entwickelt, insbesondere ERC-4337. Während ERC-4337 sich auf eine Smart-Contract-basierte Lösung konzentriert, die keine Protokolländerungen erfordert, führt EIP-3074 neue Opcodes direkt in die EVM ein und bietet einen anderen Weg zu ähnlichen Funktionalitäten für bestehende EOAs.

Ein praktisches Beispiel für die Nützlichkeit von EIP-3074 könnte in einer dezentralen Anwendung (dApp) gesehen werden, die eine nahtlose Benutzererfahrung bieten möchte. Stellen Sie sich einen Benutzer vor, der an einem Liquiditätspool teilnehmen möchte, was typischerweise die Genehmigung von zwei Token und deren anschließendes Hinzufügen zum Pool beinhaltet. Mit EIP-3074 könnte die dApp dem Benutzer eine einzige Autorisierungsanfrage präsentieren. Nach der Signatur könnte ein von der dApp verwalteter Invoker-Vertrag dann AUTHCALL verwenden, um alle notwendigen Genehmigungen und die endgültige Liquiditätszuführung in einer einzigen, gebündelten Transaktion auszuführen, wobei die dApp möglicherweise sogar die Gasgebühren sponsert. Ein weiterer überzeugender Anwendungsfall betrifft die soziale Wiederherstellung. Ein EOA-Inhaber könnte einen bestimmten Smart Contract autorisieren, einen Wiederherstellungsprozess einzuleiten, falls sein privater Schlüssel verloren geht, wodurch vertrauenswürdige Wächter einen neuen Schlüssel genehmigen können. Dies geht über die einfache Transaktionsdelegation hinaus zu komplexerem Kontomanagement. Darüber hinaus könnte EIP-3074 Abonnementzahlungen direkt von einer EOA aus ermöglichen, wobei ein Benutzer einen Vertrag autorisiert, wiederkehrende Zahlungen bis zu einem bestimmten Limit zu leisten, ohne jede Zahlung manuell bestätigen zu müssen. Diese Beispiele verdeutlichen, wie EIP-3074 darauf abzielt, den Benutzerkomfort zu verbessern und die Fähigkeiten von Standard-Ethereum-Wallets zu erweitern.

Häufige Missverständnisse

Eines der häufigsten Missverständnisse bezüglich EIP-3074 ist die Annahme, dass es eine EOA in ein Smart-Contract-Konto umwandelt. Dies ist falsch. EIP-3074 ändert nicht die grundlegende Natur einer EOA. Eine EOA bleibt eine EOA, die weiterhin durch ihren privaten Schlüssel kontrolliert wird. Stattdessen bietet EIP-3074 einen Mechanismus, damit eine EOA ihre Transaktionsinitiierungsautorität an einen Smart Contract delegieren kann. Die Adresse der EOA bleibt die Herkunft der Transaktion aus der Perspektive anderer Verträge, wenn AUTHCALL verwendet wird, aber die eigentliche Ausführungslogik wird vom Invoker-Vertrag gehandhabt. Diese Unterscheidung ist entscheidend: Die EOA wird nicht selbst programmierbar; sie gewährt lediglich einem Smart Contract das vorübergehende Recht, als ihr Proxy zu agieren. Der private Schlüssel behält die ultimative Kontrolle, und die Delegation kann als eine vorübergehende, widerrufliche Vollmacht betrachtet werden, nicht als eine Änderung des Kontotyps.

Ein weiteres häufiges Missverständnis ist, dass EIP-3074 vollständige Account Abstraction von sich aus bietet. Obwohl es ein bedeutender Schritt in Richtung Account Abstraction ist, ist es nicht die vollständige Lösung. Vollständige Account Abstraction zielt auf ein einheitliches Kontomodell ab, bei dem alle Konten beliebige Verifizierungslogik haben und Gas in jedem Token bezahlen können, neben anderen Funktionen. EIP-3074 befasst sich hauptsächlich mit der Delegation der Transaktionsausführung von EOAs. Es ändert nicht von Natur aus, wie Gas bezahlt wird (obwohl es Gas-Sponsoring ermöglicht) oder erlaubt keine beliebigen Signaturschemata direkt innerhalb der EOA. Es löst auch nicht das Problem, dass bestehende Smart-Contract-Wallets nicht in EOAs umgewandelt werden können. Darüber hinaus könnten einige Benutzer fälschlicherweise glauben, dass die Autorisierung eines Invoker-Vertrags bedeutet, dass ihr privater Schlüssel geteilt oder kompromittiert wird. Dies ist falsch. Der private Schlüssel der EOA wird nur verwendet, um die anfängliche Autorisierungsnachricht zu signieren; er wird niemals dem Invoker-Vertrag preisgegeben. Die Sicherheit des privaten Schlüssels der EOA bleibt von größter Bedeutung und ist vom Delegationsmechanismus getrennt. Das Verständnis dieser Nuancen ist wesentlich, um den Umfang und die Grenzen von EIP-3074 innerhalb des breiteren Ethereum-Ökosystems korrekt einzuschätzen.

Zusammenfassung

EIP-3074 führt die Opcodes AUTH und AUTHCALL in die Ethereum Virtual Machine ein und erweitert damit grundlegend die Fähigkeiten von Externally Owned Accounts (EOAs). Indem es EOAs ermöglicht, die Transaktionskontrolle an Smart Contracts zu delegieren, erlaubt dieser Vorschlag bestehenden Wallets den Zugriff auf fortgeschrittene Funktionen wie Gas-Sponsoring, Batch-Transaktionen und benutzerdefinierte Logik, die zuvor Smart-Contract-Konten vorbehalten waren. Dieser Mechanismus beinhaltet, dass eine EOA eine Nachricht signiert, um einen "Invoker"-Vertrag zu autorisieren, der dann AUTH verwendet, um die EOA als den authorized Absender festzulegen, und AUTHCALL, um Transaktionen in ihrem Namen auszuführen. Obwohl EIP-3074 erhebliche Verbesserungen in Bezug auf Benutzererfahrung und Flexibilität bietet, erfordert es auch eine sorgfältige Abwägung der Risiken, die mit der Delegation der Kontrolle an Invoker-Verträge verbunden sind. Es stellt einen entscheidenden Schritt auf Ethereums Weg zu einer umfassenderen Account Abstraction dar und bietet einen flexiblen und leistungsstarken Rahmen für Entwickler und Benutzer gleichermaßen, ohne die Kernnatur von EOAs zu verändern.