Eine Gruppe prominenter Ethereum-Entwickler, darunter Vitalik Buterin, hat einen neuen Transaktionstyp (EIP-7702) vorgeschlagen, um die Funktionalität und Sicherheit von Externally Owned Accounts (EOAs) zu verbessern. Der Vorschlag zielt darauf ab, häufige Probleme wie Transaktionsstapelung, Sponsoring und Deeskalation von Privilegien anzugehen.
Gemäß dem EIP-7702-Entwurf fügt der neue Transaktionstyp „ein Feld „contract_code“ und eine Signatur hinzu und wandelt das unterzeichnende Konto (nicht unbedingt dasselbe wie tx.origin) für die Dauer dieser Transaktion in ein Smart Contract Wallet um.“ Der Vorschlag soll eine ähnliche Funktionalität wie EIP-3074 bieten.
Die Motivation hinter EIP-7702 besteht darin, kurzfristige Funktionsverbesserungen für EOAs bereitzustellen, die Benutzerfreundlichkeit von Anwendungen zu erhöhen und in einigen Fällen eine verbesserte Sicherheit zu ermöglichen. Der Vorschlag beschreibt drei besondere Anwendungen: Batching, Sponsoring und Deeskalation von Privilegien.
Während EIP-3074 diese Anwendungsfälle löst, glauben die Autoren von EIP-7702, dass es Bedenken hinsichtlich der Vorwärtskompatibilität gibt. Sie geben an, dass EIP-3074 „zwei Opcodes einführt, AUTH und AUTHCALL, die in einer Welt der ‚Endgame-Kontoabstraktion‘, in der schließlich alle Benutzer Smart-Contract-Wallets verwenden, keinen Nutzen hätten.“
Darüber hinaus argumentieren sie, dass EIP-3074 „zur Entwicklung eines ‚Invoker Contract‘-Ökosystems führt, das vom ‚Smart Contract Wallet‘-Ökosystem getrennt wäre, was zu einer möglichen Fragmentierung der Bemühungen führen würde.“
Die Spezifikation von EIP-7702 beschreibt das Format der Transaktionsnutzlast und den Prozess der Ausführung der Transaktion, bei dem der Vertragscode des unterzeichnenden Kontos vorübergehend festgelegt und am Ende der Transaktion wieder auf leer gesetzt wird.
Die Autoren begründen, wie EIP-7702 EIP-3074-Anwendungsfälle konvertieren kann, und geben an, dass „die Konvertierung eines vorhandenen EIP-3074-Workflows relativ wenig Arbeit erfordert.“
Sie argumentieren außerdem, dass EIP-7702 so konzipiert ist, dass es vorwärtskompatibel mit der zukünftigen Kontoabstraktion ist, wodurch die Schaffung separater Code-Ökosysteme und die Notwendigkeit neuer Opcodes, die möglicherweise veraltet sind, vermieden werden.
Trotz der potenziellen Vorteile erkennen die Autoren an, dass EIP-7702 die Invariante aufhebt, dass ein Kontostand nur aufgrund von Transaktionen sinken kann, die von diesem Konto ausgehen, was Konsequenzen für das Mempool-Design und andere EIPs haben kann.
Wie bei jedem Vorschlag, der Benutzer zur Unterzeichnung eines Vertragscodes verpflichtet, betonen die Autoren, wie wichtig es ist, dass Benutzer-Wallets vorsichtig sind, welchen Vertragscode sie unterzeichnen, und heben die gemeinsamen Sicherheitsüberlegungen mit EIP-3074 hervor.