Darstellung der Ethereum-Kontoabstraktions-Roadmap I: EIP-3074, EIP-5806 und EIP-7702

Nachdem wir die bedeutenden Änderungen beobachtet haben, die durch das Deneb-Upgrade bei Ethereum eingeführt wurden, haben wir begonnen, vorauszuschauen, was der nächste Hardfork, Pectra, bringen wird. Um die kommenden Diskussionen mitzugestalten, versuchen wir, die aktuelle Landschaft der Kontoabstraktion rund um Ethereum und sein Rollup-Ökosystem zu beschreiben, um möglicherweise einen klaren Weg nach vorne aufzuzeigen.

Dieser Bericht bietet einen Überblick über das aktuelle Kontomodell von Ethereum, insbesondere dessen Auswirkungen auf die Gültigkeit von Transaktionen, was genau die Kontoabstraktion beinhaltet und einen Rahmen für die Argumentation darüber. Wir werden uns dann auf den EOA-Programmierbarkeitsansatz konzentrieren, indem wir die EIPs 5086, 3074 und 7702 auswerten, und abschließend erläutern, wie sich dies alles wahrscheinlich auf die Zukunft von Transaktionen auf Ethereum auswirkt.

Obwohl es viel Verwirrung darüber gibt, was Kontoabstraktion ist und was nicht, ist unser Ansatz in dieser Reihe, dass jeder Mechanismus, der es einem Konto ermöglicht, einen Teil seiner Gültigkeitsregeln neu zu definieren, ein Mechanismus zur Kontoabstraktion ist. Darüber hinaus bieten wir eine Klassifizierung dieser Mechanismen an, da die meisten von ihnen vage ähnlich sind und sich überschneiden.

Ein Überblick über die Kontoabstraktion in Ethereum

Die Kontoabstraktion soll die Benutzer- und Entwicklererfahrung im gesamten Ethereum-Ökosystem verbessern. Sie macht On-Chain-Erfahrungen für Benutzer nicht nur zugänglicher und angenehmer, sondern ermöglicht Entwicklern auch, leistungsfähigere Dinge auf Ethereum zu tun und Benutzern noch sinnvoller zu dienen.

Unsere Klassifizierung der Ansätze zur Kontoabstraktion lautet wie folgt:

1. EOA-Erweiterung/Programmierbarkeit : Dazu gehören Änderungen auf Protokollebene, die es EOAs (Externally Owned Accounts) ermöglichen, den Ausführungslogikteil ihrer Gültigkeitsregeln neu zu definieren. Wie in der Entwicklungsgemeinschaft bekannt ist, handelt es sich bei EOAs um Konten, die normalerweise Endbenutzern zugeordnet sind. Lösungen, die diesem Ansatz entsprechen, geben Endbenutzerkonten daher mehr Kontrolle darüber, welche Art von Aktionen sie autorisieren können, als dies heute möglich ist.

2. EOA-Konvertierung/Migration : Dieser Ansatz umfasst Vorschläge, die eine vollständige Konvertierung von EOAs in CAs (Vertragskonten) anstreben. Die wesentliche Idee dieses Ansatzes besteht darin, dass Vertragskonten bereits die meisten Vorteile von Smart Accounts bieten, sodass es nicht mehr nötig sein sollte, die Dinge zu verkomplizieren; jeder sollte einfach ein Vertragskonto als sein primäres Konto verwenden (über Smart Contract Wallets).

Dieser Ansatz umfasst Mechanismen, die den Übergang eines EOA zu einer CA ermöglichen, ohne dass seine Vermögenswerte verschoben werden müssen, wie etwa EIP 7377 und EIP 5003 (in Verbindung mit EIP 3074).

3. Smart Accounts : Diese Gruppe von Vorschlägen umfasst Designs, die es sowohl EOAs als auch CAs ermöglichen, sich wie „Smart Accounts“ zu verhalten, indem sie ihre Gültigkeitsregeln völlig neu definieren können.

Es wurden bereits verschiedene Vorschläge zur Erstellung von Smart Accounts und zur Verankerung der Account-Abstraktion auf Protokollebene gemacht; EIP-86 und EIP-2938 sind einige der am häufigsten zitierten Vorschläge. Es gab jedoch viel Widerstand aufgrund der wahrgenommenen Komplexität, die dieser Entwurf mit sich bringt, und der mehrheitlichen Meinung, dass Ethereum für eine solche Komplexität nicht bereit sei.

Nach Vitaliks Wiederbelebung des Themas nach The Merge wurde ERC-4337 als Opt-in-Version des Smart-Account-Standards vorgeschlagen, ähnlich der PBS-Infrastruktur (Proposer-Builder Separation) für MEV (Maximal Extractable Value). Benutzer, die die Vorteile von Smart Accounts nutzen möchten, können daher einfach die ERC-4337-Pipeline verwenden, um die Logik und die Gültigkeitsregeln ihrer Konten in Strukturen neu zu definieren, die als UserOperation (oder kurz UserOps ) bezeichnet werden.

ERC 4337 bringt die Vorteile von Smart Accounts in das heutige Ethereum, ohne die Komplexität zu verankern, indem es als Out-of-Protocol-Alternative zu verankerten Smart Accounts fungiert. Dies bedeutet jedoch nicht, dass die Infrastruktur in ihrem aktuellen Zustand optimal ist, da ihre eigene Komplexität immer noch eine erhebliche Schwachstelle darstellt.

Um dieser Komplexität zu begegnen, wurde RIP 7560 als verankerte Version der ERC 4337-Infrastruktur für Ethereum und seine L2s entworfen, sodass es die Sybil-Resistenzschemata des Netzwerks übernimmt, anstatt einen neuen Regelsatz definieren zu müssen (wie es ERC 4337 mit ERC 7562 tut).

In diesem Bericht konzentrieren wir uns auf die Erforschung der EOA-Programmierbarkeit, bewerten die verschiedenen EIPs, die Lösungen in dieser Richtung beschreiben, und diskutieren ihre Vorzüge und Nachteile. In Teil 2 und 3 dieser Reihe werden wir die verbleibenden zwei Klassen von Ansätzen zur Kontoabstraktion behandeln, die in Ethereum erforscht werden.

Eine Einführung in Ethereum-Konten und -Transaktionen

Um herauszufinden, was abstrahiert werden kann, benötigen wir ein (mehr oder weniger) vollständiges Bild des aktuellen Kontodesigns. Dieser Abschnitt dient hauptsächlich als eine Art Wiederholung dessen, was Konten bei Ethereum eigentlich sind und wie ihre Transaktionen validiert und ausgeführt werden.

Ethereum-Konten sind Einheiten mit einem Ether-Guthaben (ETH) und der Fähigkeit, Transaktionen über die Ethereum-Blockchain zu senden. Sie werden als 42-stellige hexadezimale „Adresse“ dargestellt, die als eindeutiger Zeiger auf die Bestände und Transaktionen des Kontos dient.

Eine Adresse fungiert als Schlüssel zum Status-Trie der Blockchain. Die Blattknoten dieses Tries sind Kontodatenstrukturen, die in vier Felder zerlegt werden können:

1. nonce : Ein linearer Zähler, der die Anzahl der ausgehenden Transaktionen angibt, die von einem Konto initiiert wurden. Er ist auch wichtig, um Replay-Angriffe zu verhindern.
2. balance : Der in Wei angegeben Betrag an Ether (ETH), der einem Konto gehört.
3. codeHash : Ein Hash des in einem Konto enthaltenen EVM-ausführbaren Codes. Die EVM (Ethereum Virtual Machine) ist Ethereums maßgeschneiderte Ausführungsumgebung, die für die Handhabung komplexer Zustandsübergänge über einfache „Sende“-Transaktionen hinaus verantwortlich ist. Der Codeinhalt eines Kontos ist unveränderlich programmiert, um über die EVM bestimmte Formen von Zustandsübergängen in der Ethereum-Blockchain auszuführen.
4. storageHash : Ein Hash des Speicherstamms eines Kontos, der verwendet wird, um den Speicherinhalt eines Kontos als 256-Bit-Hash des Stammknotens eines Merkle-Patricia-Tries darzustellen. Einfach ausgedrückt handelt es sich um einen Hash der Statusvariablendaten, die sich auf den Codeinhalt eines Kontos beziehen.

Der Inhalt dieser vier Felder wird verwendet, um den Typ eines Kontos zu definieren und bestimmt letztlich den Umfang seiner Funktionalitäten. Somit gibt es zwei Arten von Ethereum-Konten:

1. Extern verwaltete Konten (EOAs) , die als kryptografisches Schlüsselpaar initialisiert werden:

• Ein privater Schlüssel , der ein verschlüsselbares und nachweislich zufälliges 64-stelliges Hexadezimalzeichen ist, und sein komplementäres Gegenstück;
• Ein öffentlicher Schlüssel , der mithilfe des ECDSA (Elliptic Curve Digital Signature Algorithm) aus dem privaten Schlüssel abgeleitet wird.

EOAs haben leere CodeHash- und StorageHash-Felder und können nur von jemandem kontrolliert werden, der die privaten Schlüssel besitzt. Ihre Adressen können aus dem entsprechenden öffentlichen Schlüssel erhalten werden, indem den letzten zwanzig Zeichen des Keccak-256-Hashes des öffentlichen Schlüssels des Kontos „0x“ vorangestellt wird.

2. Vertragskonten (CAs), die nur von einem bereits vorhandenen EOA erstellt werden können. Sie werden initialisiert, indem ein EOA ausführbaren Codeinhalt auf dem EVM bereitstellt. Dieser Codeinhalt (gespeichert als CodeHash) ist im EVM verankert und ist für die Steuerung des Kontos verantwortlich, indem er dessen Logik und Interaktionen definiert.

Transaktionen von Vertragskonten sind vollständig Pull-basiert und basieren auf der Logik ihres bereitgestellten Codes. Da diese Konten nur über ihren Codeinhalt gesteuert werden können, benötigen sie keinen privaten Schlüssel und haben nur einen öffentlichen Schlüssel. Somit kann jeder Agent, der den Codeinhalt eines Vertragskontos aktualisieren/ändern kann, auf dessen Kontostand zugreifen. Die Adresse eines Vertragskontos wird bis zum Zeitpunkt der Bereitstellung des Vertrags aus der Adresse seines Erstellers und seinem Nonce abgeleitet.

Transaktionen

Wir haben Konten kürzlich als Entitäten beschrieben, die Transaktionen über Ethereum senden können. Wir können daher verstehen, dass der Hauptzweck eines Kontos darin besteht, Transaktionen zu senden und zu empfangen, während die Blockchain als Hauptbuch fungiert, in dem der Transaktionsverlauf aufgezeichnet wird und das beschreibt, wie Transaktionen Kontofelder basierend auf den in der Blockchain-Protokollspezifikation beschriebenen Regeln ändern.

Was sind also diese „Transaktionen“?

Transaktionen sind von einem Konto gesendete Vorgänge, die eine Änderung des „Zustands“ des Netzwerks bewirken. Es handelt sich dabei um kryptografisch signierte Anweisungen von Konten, die bei Ausführung zu einer netzwerkweiten Statusaktualisierung führen.

Erlaubnislosigkeit bringt den Preis perverser Anreize mit sich. Um diese zu bewältigen, müssen strenge Richtlinien (oder Gültigkeitsregeln) für Interaktionen in solchen Umgebungen definiert werden. In diesem Zusammenhang müssen Transaktionen bestimmten Gültigkeitsregeln folgen, um als gültig angesehen und ausgeführt zu werden. Die meisten dieser Gültigkeitsregeln werden über Einschränkungen implementiert, die dem Konto auferlegt werden, das die Transaktion sendet, und variieren je nach Art des Kontos.

Konten und Transaktionsgültigkeit

Auf Ethereum sind EOAs auf Benutzerfreundlichkeit optimiert, da sie sich direkt an den Endbenutzer richten. Sie können Transaktionen auf eine bestimmte Weise senden und vollkommen autonom arbeiten. Sie können auch lokal erstellt werden, wobei die gängigere Methode die Verwendung von Wallet-Anbietern wie MetaMask, Rainbow, Rabby usw. ist.

Vertragskonten hingegen können nur Transaktionen senden, die ihre Logik zulässt, wenn sie „ aufgerufen “ werden. Außerdem können sie nur von einem EOA erstellt werden, dessen Guthaben ausreicht, um die Speicherung seines Status zu bezahlen.

Eine detailliertere Beschreibung wäre, dass EOAs nur einen Saldo halten können, während CAs sowohl einen Saldo als auch eine Logik halten können, die vorgibt, wie dieser Saldo ausgegeben werden kann. Diese Eigenschaften sind auf die folgenden Logikparameter zurückzuführen, die die Regeln definieren, denen die Transaktionen eines Kontos entsprechen müssen:

1. Authentifizierungslogik – Wird verwendet, um zu definieren, wie ein Konto seine Identität gegenüber dem Netzwerk nachweist, während sein Guthaben und/oder seine Logik geändert wird.
2. Autorisierungslogik – Wird verwendet, um die Zugriffsrichtlinie eines Kontos zu definieren, d. h. wer auf den Kontostand und/oder die Logik des Kontos zugreifen und Änderungen daran vornehmen kann.
3. Nonce-Logik – definiert die Reihenfolge, in der Transaktionen von einem Konto ausgeführt werden sollen.
4. Gaszahlungslogik – Wird verwendet, um die Partei zu definieren, die für die Begleichung der Gasgebühr einer Transaktion verantwortlich ist.
5. Ausführungslogik – Wird verwendet, um zu definieren, welche Arten von Transaktionen ein Konto senden kann oder wie eine Transaktion ausgeführt werden soll.

Diese Parameter sind für EOAs starr ausgelegt, daher gilt:

• Die Authentifizierung und Autorisierung erfolgt über einen ECDSA-basierten privaten Schlüssel. Das heißt, ein Benutzer, der eine Transaktion von seinem EOA senden möchte, muss seinen privaten Schlüssel verwenden, um auf das Konto zuzugreifen und so nachzuweisen, dass er berechtigt ist, Änderungen an dessen Kontostand vorzunehmen.
• Die Nonce-Logik implementiert ein sequentielles Zählerschema, das die sequentielle Ausführung nur einer Transaktion pro eindeutigem Nonce pro Konto zulässt.
• Die Gaszahlungslogik gibt vor, dass die Gasgebühr für Transaktionen vom Absender/Ursprungskonto beglichen werden muss.
• Die Ausführungslogik gibt an, dass EOAs nur die folgenden Transaktionsformen senden können:

1. Regelmäßige Überweisungen zwischen zwei EOAs.
2. Vertragsbereitstellung.
3. Vertragsaufrufe, die auf die Logik eines bereitgestellten Vertragskontos abzielen.

Allgemeiner gesagt beschränkt die Ausführungslogik von EOAs diese auf eine Transaktion pro gültiger Signatur.

Andererseits haben Zertifizierungsstellen mehr Flexibilität hinsichtlich dieser Parameter:

• Eine Authentifizierung ist nicht erforderlich, da ihre Transaktionen ihrem Wesen nach konsequential/Pull-basiert sind.
• Die Autorisierung für CAs kann auf zwei Arten erfolgen:

1. Möglichkeit, den Inhaltscode der CAs „ aufzurufen “ (oder ihren Smart Contract auszuführen), was von der Logik des Smart Contracts des Kontos und seinen Invarianten abhängt.
2. Möglichkeit, Änderungen am Inhaltscode der CAs vorzunehmen, was hauptsächlich davon abhängt, ob der Inhaltscode aktualisierbar ist oder nicht.

In den meisten praktischen Fällen handelt es sich bei der verwendeten Logik um ein Mehrfachsignaturschema, das vorschreibt, dass von bestimmten Konten (üblicherweise EOAs) eine Anzahl von M von N gültigen Signaturen (wobei M < N) erforderlich ist, damit eine Änderung der CA-Logik gültig ist.

• Ihre Transaktionsreihenfolge basiert lose auf Nonce. Die CA selbst kann so viele Transaktionen wie möglich an so viele verschiedene Anrufer wie möglich senden, jedoch ist jeder Anrufer aufgrund seiner eigenen Fähigkeiten eingeschränkt.
• Die Gaszahlung wird normalerweise vom Anrufer der CA-Logik abgewickelt.
• Die Ausführungslogik von CAs ist vielfältiger, um UX-Verbesserungen wie Multicall-Transaktionen und atomare Transaktionen zu ermöglichen.

Bei der Bewertung dieser Funktionen stellen wir fest, dass jeder Kontotyp so konzipiert ist, dass er einen Kompromiss zwischen Autonomie und Programmierbarkeit darstellt.

EOAs sind vollständig autonom, aber nur begrenzt programmierbar. Sie können Transaktionen jederzeit autorisieren und senden, aber diese Transaktionen müssen einem starren Format folgen, um als gültig zu gelten. Vertragskonten sind vollständig programmierbar (nur durch das Design des EVM begrenzt), aber nur begrenzt autonom: Ihre Transaktionen müssen keinem starren Format folgen, sondern können nur gesendet werden, wenn ihre Logik zuerst aufgerufen wird.

Im folgenden Unterabschnitt werden wir nun die Auswirkungen dieser Designentscheidungen untersuchen, um den Vorschlag jedes in dieser Reihe besprochenen EIP vollständig zu verstehen.

Das Konto-Dilemma von Ethereum

Da wir nun ein einigermaßen prägnantes Wissen über die Funktionen der verschiedenen Konten haben, können wir ihre Verkaufsargumente sowie die Probleme, die sie sowohl für Benutzer als auch für Entwickler auf Ethereum mit sich bringen, leicht identifizieren. Wie bereits erwähnt, sind EOAs als erstklassige Konten konzipiert, die sich an Endbenutzer richten. Anwendungen sind so konzipiert, dass sie leicht mit ihnen interagieren können, sie sind fast nicht komplex und natürlich entstehen für ihre Erstellung keine Kosten. Ihre Einfachheit geht jedoch mit einem erheblichen Verlust an Neuheit einher, da sie streng deterministisch konzipiert sind.

Einige der damit verbundenen Bedenken sind:

1. Anfälligkeit für Quantenangriffe – Das von ihrem Schlüsselpaar verwendete ECDSA-Signaturschema ist nicht quantenresistent. Angesichts eines optimistischen Zeitrahmens von 5 bis 10 Jahren, in dem industrielle Quantensysteme erreicht werden, stellt dies eine erhebliche Bedrohung für Ethereum und seine Anwendungen dar, die in hohem Maße auf das ECDSA-Schema für kryptografische Beweise und Sicherheit angewiesen sind.
2. Mangelnde Ausdrucksfähigkeit – Das starre Format der Gültigkeitsregeln von EOAs verhindert, dass Benutzer ihre Transaktionen über Funktionen wie Transaktionsatomarität und -stapelverarbeitung sowie Transaktionsdelegation prägnanter ausdrücken können.
3. Selbsterhaltung – Jeder hat schon genug „Mir ist das Gas ausgegangen“-Momente mitten in einer Transaktion erlebt. Das liegt an der Anforderung, dass EOAs das Gas für ihre Transaktionen selbst abrechnen müssen, was keine große Herausforderung wäre, wenn Ether (ETH) nicht die einzige akzeptable Gaswährung wäre. Während dies ein allgemeines Problem bei kontobasierten Zustandsmaschinen (und sogar bei UTXO-basierten) ist, war bei Ethereum schon immer eine andere Vorgehensweise vorgesehen.

Nicht jeder möchte (oder könnte) immer ETH halten (sehen Sie sich nur die Preisentwicklung an). Daher wären praktikable Lösungen, entweder mehrere Gaswährungen zuzulassen (zu schwierig, verletzt zu viele Invarianten, wie hier im Abschnitt „Währung“ beschrieben) oder die Abwicklung von Gaszahlungen über ein anderes Konto zuzulassen, das nicht der Ursprungskonto der Transaktion ist.

Am anderen Ende des Kontospektrums richten sich CAs an Entwickler und eine technisch versiertere Benutzerbasis. Sie dienen als Vehikel für Smart Contracts (d. h. wir betrachten Smart Contracts als deren enthaltenen Logik- oder Codeinhalt) und können so neuartige Transaktionsformate implementieren, wie sie durch das EVM ermöglicht werden.

Trotz all dieser Funktionen handelt es sich jedoch um glorifizierte Konten zweiter Klasse, da sie keine Autonomie haben. Einige ihrer Nachteile sind die folgenden:

1. Völliger Mangel an Autonomie – CAs können keine Transaktionen beginnen, sie können nur Transaktionen versenden, wenn sie auf eine ganz bestimmte Art und Weise aufgerufen werden.
2. Anfälligkeit für menschliche Fehler in ihrer Logik – Der Mangel an Starrheit führt oft zu einer falschen Definition von Invarianten und anderer Logik, was zu Milliardenverlusten aufgrund von Smart-Contract-Exploits und Hacks geführt hat. Dies ist jedoch fast ein völlig anderes Thema, das hier über unseren Rahmen hinausgeht.

Nachdem wir die Designentscheidungen überprüft haben, die zu den in diesem Unterabschnitt definierten Problemen geführt haben, können wir nun mit der Bewertung der vorgeschlagenen Lösungen fortfahren.

Eine Zeitleiste der Kontoabstraktion

Um herauszufinden, was abstrahiert werden kann, benötigen wir ein (mehr oder weniger) vollständiges Bild des aktuellen Kontodesigns. Dieser Abschnitt dient hauptsächlich als eine Art Wiederholung dessen, was Konten bei Ethereum eigentlich sind und wie ihre Transaktionen validiert und ausgeführt werden.

Das Konzept der Kontoabstraktion (zumindest über Smart Accounts) war schon immer ein wesentlicher Bestandteil der Roadmap von Ethereum. Es wird erzählt, dass die Komplexität der Implementierung den Start von Ethereum weiter verzögern könnte, und so wurde es zugunsten des aktuellen Designs verworfen, bei dem verschiedene Konten unterschiedliche Funktionalitäten bieten. Es wurde erneut verzögert, weil Ethereum sich auf The Merge konzentrierte, und taucht nun als Hauptbestandteil des nächsten großen Upgrades des Netzwerks – Pectra – wieder auf. Seine Komplexität wird jedoch immer noch als erheblicher Nachteil angesehen, der seine Verankerung verhindert, insbesondere da Ethereum auf eine Rollup-zentrierte Roadmap umgestiegen ist.

Die Anforderungen sind nun zweifach:

1. Kontostandards müssen ausdrucksstärker werden, ohne jedoch an Autonomie einzubüßen. Ein neuer Standard, der die Kluft zwischen den EOA- und CA-Standards schließt.
2. Der neue Standard muss die Lücke zwischen EOAs und CAs schließen und gleichzeitig mit Ethereum und seinen L2-Ökosystemen vollständig kompatibel bleiben.

Intuitiv spielt dieses Konzept im Kontext von Kettenabstraktion und Interoperabilität eine größere Rolle. Unser Umfang in diesem Bericht beschränkt sich jedoch auf die technischen Initiativen, die zur Erreichung der Kontoabstraktion selbst ergriffen wurden.

Die Kontoabstraktion zielt darauf ab, die besten Funktionen von EOAs und CAs in einem neuen Kontostandard zu kombinieren – Smart Accounts , die eine vollständige oder teilweise Trennung der Gültigkeitsregeln eines Kontos in eine Validierungslogik und eine Ausführungslogik ermöglichen. So können Konten – wie vom EVM gestattet – genau wie Vertragskonten ihre eigenen Gültigkeitsregeln definieren, bleiben dabei aber genau wie extern verwaltete Konten völlig autonom.

Es herrscht häufig Verwirrung hinsichtlich der Unterschiede zwischen Smart Accounts und Smart Contract Wallets. Lassen Sie uns daher im Folgenden genauer beschreiben, worin diese Unterschiede bestehen:

• Smart Accounts sind Ethereum-Konten, die so konzipiert sind, dass sie Programmierbarkeit und Autonomie gleichermaßen bieten. Die Idee ist, dass sowohl EOAs als auch CAs zu Smart Accounts werden können, indem sie einfach einen Mechanismus (z. B. ERC 4337) verwenden, der es ihnen ermöglicht, ihre vom Netzwerk auferlegten Gültigkeitsregeln nach Belieben durch maßgeschneiderte Gültigkeitsregeln zu ersetzen.
• Smart-Contract-Wallets hingegen sind lediglich Wallet-Anbieter, die als Schnittstellen zu Vertragskonten dienen (ja, ein Wallet ist kein Konto).

Die Kommerzialisierung von Smart Contract Wallets erleichterte die Akzeptanz von CAs auf einem breiteren Markt und ermöglichte es weniger technisch versierten Benutzern, die von ihnen angebotenen Funktionen zu nutzen. Allerdings sind sie immer noch mit den mit CAs verbundenen Fallstricken konfrontiert.

Zurück zum Gespräch; wir hatten zuvor die Parameter besprochen, die verwendet werden, um die Gültigkeitsregeln von Kontotransaktionen zu definieren:

• Authentifizierung
• Genehmigung
• Nonce-Logik
• Zahlungslogik für Gas
• Ausführungslogik

Die Werte der ersten vier Parameter können zusammen als Validierungslogik eines Kontos bezeichnet werden. Dabei handelt es sich um Prüfungen, die vor Beginn der Ausführung einer Transaktion durchgeführt werden. Der letzte Parameter definiert, wie die Ausführung der Transaktion erfolgen soll.

In der Einleitung haben wir einen umfassenden Überblick über die aktuelle AA-Landschaft in Form einer Art Klassifizierung der verschiedenen vorgeschlagenen Designs gegeben. Wir werden uns nun auf die erste Lösungsklasse für das Kontodilemma von Ethereum konzentrieren – die EOA-Programmierbarkeit.

Programmierbare EOAs

Der größte Reiz von Ethereum liegt in seinem jungen, aber dynamischen DeFi-Ökosystem, das eine Vielzahl dezentraler Anwendungen umfasst, die seine primären Liquiditätssenken sind. Die meisten dieser DApps sind für die Bedienung von EOAs optimiert und lassen sich daher nur schwer mit Vertragskonten und schließlich auch mit Smart Accounts verbinden. Smart Contract Wallets helfen Vertragskonten in diesem Fall zwar, bringen aber ihre eigenen Einschränkungen und eine völlig andere UX mit sich.

Eine Zwischenlösung, die untersucht wird, während sich sowohl DApps als auch Wallet-Anbieter an den Smart-Account-Standard gewöhnen, besteht darin, EOAs vorübergehend zu verbessern, damit sie die meisten der ihnen auferlegten Einschränkungen überwinden können, sei es ihre Validierungs- oder Ausführungslogik. Im Folgenden gehen wir auf die Spezifikationen von drei wichtigen EIPs ein, die umsetzbare Wege zur EOA-Programmierbarkeit bieten; vom weniger bekannten EIP 5806 über das ehrgeizige EIP 3074 bis hin zum siegreichen EIP 7702 .

Programmierbarkeit über EIP-5806

Dieser Vorschlag soll dem EOA-Standard mehr Funktionalität verleihen, indem er delegierte Aufrufe an die Logik eines Vertragskontos (seinen Smart Contract) ermöglicht. Dies führt effektiv dazu, dass der Smart Contract im Kontext des aufrufenden EOA ausgeführt wird, d. h. der EOA behält die Kontrolle über seine Validierungslogik, während seine Ausführungslogik von der Logik des entsprechenden Vertragskontos gehandhabt wird.

Bevor wir fortfahren, lassen Sie uns eine Reise in die Vergangenheit der Ethereum-Evolution zu EIP-7 unternehmen. EIP-7 schlug die Erstellung des Opcodes 0xf4/DELEGATECALL vor, der verwendet wird, um Nachrichtenaufrufe an ein primäres Konto mit der Logik eines sekundären Kontos zu senden, während die Werte der Felder [sender] und [value] des primären Kontos beibehalten werden. Mit anderen Worten: Das primäre Konto „erbt“ (oder leiht sich, wenn Sie das bevorzugen) die Logik des sekundären Kontos für eine im Nachrichtenaufruf angegebene Dauer, sodass die Logik des letzteren im Kontext des ersteren ausgeführt wird.

Dieser Opcode ermöglichte es Dapp-Entwicklern, die Logik ihrer Anwendung in mehrere Smart Contracts aufzuteilen und dabei die gegenseitige Abhängigkeit beizubehalten, sodass sie Codegrößen- und Gasbarrieren problemlos umgehen konnten. EIP-5806 findet eine neue Verwendung für den DELEGATECALL-Opcode, die über die Möglichkeit der gegenseitigen Abhängigkeit von Vertragskonten hinausgeht. Insbesondere verwendet EIP-5806 EIP-7 als Inspiration, um die Erweiterung der Delegate-Call-Funktionalität auch auf EOAs vorzuschlagen; d. h., lassen wir zu, dass EOAs auch von Vertragskonten abhängig sind, denn warum nicht.

EIP-5806-Spezifikationen

EIP 5806 führt einen neuen EIP-2718-kompatiblen Transaktionstyp ein, der wie folgt verpackt ist:

 rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Diese Transaktionen sind so konzipiert, dass das Feld [An] – das die Adresse des Empfängers darstellt – nur Adressen als 20-Byte-Eingaben akzeptieren kann, wodurch der Absender den Opcode CREATE nicht verwenden kann.

Die Motivation hinter den einzelnen Komponenten des RLP-Programms ist wie folgt:

• chainID : Die EIP-115-konforme Kennung der aktuellen Kette, aufgefüllt auf 32 Bytes. Dieser Wert bietet Schutz vor Replay-Angriffen, sodass Transaktionen auf der ursprünglichen Kette nicht einfach auf alternative EVM-Ketten mit ähnlicher Historie und geringerer wirtschaftlicher Sicherheit repliziert werden.
• Nonce : Eine eindeutige Kennung für jede Transaktion, die auch Schutz vor Replay-Angriffen bietet.
• max_priority_fee_per_gas und max_fee_per_gas : Die Werte der Gasgebühr, die eine EIP-5806-Transaktion für die Bestellung bzw. Aufnahme zahlen muss.
• gas_limit : Die maximale Gasmenge, die eine einzelne Transaktion vom Typ 5806 verbrauchen kann.
• Ziel : Der Empfänger der Transaktion
• data : Der ausführbare Codeinhalt
• access_list : Agenten, die bedingt zur Ausführung von EIP-5806-Transaktionen autorisiert sind.
• signature_y_parity, signature_r und signature_s : drei Werte, die zusammen eine secp256k1-Signatur über der Nachricht darstellen – keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Während das Verpacken von EIP-5806-Transaktionen in EIP-2718-Umschlägen eine hohe Abwärtskompatibilität ermöglicht, sind EOAs nicht mit Vertragskonten gleichzusetzen. Daher müssen bestimmte Einschränkungen in der Art und Weise definiert werden, wie ein EOA Delegate-Aufrufe verwendet, um Invariantenbrüche zu verhindern.

Diese Einschränkungen betreffen die folgenden Opcodes:

• SSTORE/0x55 : Mit diesem Opcode kann ein Konto einen Wert im Speicher ablegen. Er ist in EIP-5806-Transaktionen eingeschränkt, um zu verhindern, dass EOAs den Speicher mithilfe von Delegate-Aufrufen einrichten/auf ihn zugreifen. Dadurch werden potenzielle Probleme vermieden, die in Zukunft aufgrund einer Kontomigration auftreten können.
• CREATE/0xF0 , CREATE2/0xF5 und SELFDESTRUCT/0xFF : Diese Opcodes ermöglichen dem Anrufer weitgehend, ein neues Konto zu erstellen. Der Zugriff auf diese ist beschränkt, um eine Änderung des Nonce eines EOA in einem anderen Ausführungsrahmen (in diesem Fall Vertragserstellung/-zerstörung) zu verhindern, während eine EIP-5806-Transaktion ausgeführt wird, um zu verhindern, dass die Erwartung, dass Transaktionen aufeinanderfolgende Nonces enthalten, ungültig wird.

Mögliche Anwendungen von EIP-5806

Die primäre Anwendbarkeit von EIP-5806 ist die Ausführungsabstraktion für EOAs. Indem EOAs über einfache Aufrufe ihrer Logik hinaus vertrauenslos mit Smart Contracts interagieren können, erhalten sie Funktionen wie:

• Bedingte Ausführung von Transaktionen
• Stapelverarbeitung von Transaktionen
• Multicall-Transaktionen (zB genehmigen und anrufen)

Kritik an EIP-5806

Die von EIP-5806 vorgeschlagenen Änderungen ermöglichen zwar die erforderlichen Funktionen, sind aber nicht besonders neuartig. Ihre Existenz basiert größtenteils auf einem bereits funktionsfähigen EIP-7. Dadurch können viele potenzielle Akzeptanzhürden umgangen werden.

Eine der größten Bedenken, die in den Anfangstagen geäußert wurden, war das potenzielle Risiko, EOAs Zugriff auf den Speicher und dessen Änderung zu gewähren, so wie es CAs derzeit tun. Dies verletzt viele im Netzwerk verankerte Invarianten hinsichtlich der Art und Weise, wie EOAs Transaktionen durchführen sollen, und wurde daher durch die Einführung der im vorherigen Unterabschnitt erwähnten Einschränkungen behoben.

Ein zweiter Kritikpunkt (der ein zweischneidiges Schwert ist) ist die Einfachheit von EIP-5806; es gibt die Meinung, dass die Vorteile, die man durch die Akzeptanz von EIP-5806 erhält, die Kosten nicht wert sein könnten, da es nur die Ausführungsabstraktion und nicht viel mehr ermöglicht. Alle anderen Gültigkeitsbeschränkungen bleiben für EOAs, die sich für EIP-5806 entscheiden, netzwerkdefiniert, im Gegensatz zu anderen, etwas ähnlichen EIPs, die wir in den folgenden Unterabschnitten besprechen.

Programmierbarkeit über EIP-3074

EIP-3074 schlägt vor, EOAs zu erlauben, den Großteil ihrer Validierungslogik an spezialisierte Vertragskonten, sogenannte Invoker, zu delegieren, indem die Autorisierungslogik der letzteren für bestimmte Transaktionsarten über ihre eigene gelegt wird. Dies wird erreicht, indem ihre Zugriffsrichtlinie an einen Invoker-Vertrag übergeben wird, der dann für die Definition der Zugriffsrichtlinie der EOA verantwortlich ist.

Dieses EIP schlägt die Hinzufügung von zwei neuen Opcodes zum EVM vor:

• [AUTH] legt ein kontextvariables [autorisiertes] Konto fest, das im Namen eines zweiten [Autoritäts-]Kontos handelt, basierend auf der ECDSA-Signatur des letzteren.
• [AUTHCALL] das Anrufe für das [Autoritäts]-Konto vom/als [Autorisiertes]-Konto sendet/implementiert.

Diese beiden Opcodes ermöglichen es einem EOA, die Kontrolle an eine vorab festgelegte Zertifizierungsstelle zu delegieren und somit über diese als solche zu agieren, ohne einen Vertrag bereitstellen und die damit verbundenen Kosten und externen Effekte tragen zu müssen.

EIP-3074-Spezifikationen

EIP-3074 erlaubt Transaktionen die Verwendung eines [MAGIC] -Signaturformats, um Kollisionen mit anderen Transaktionssignaturformaten zu vermeiden. Das aktive Konto, an das [AUTHCALL] -Anweisungen übergeben werden, wird als Kontextvariablenfeld mit dem Namen [authorized] definiert, das nur für eine einzige Transaktion bestehen bleibt und für jeden neuen [AUTHCALL] neu definiert werden muss.

Bevor wir auf die Komplexität der einzelnen Operationscodes eingehen, sind dies die an einer EIP-3074-Transaktion beteiligten Entitäten:

• [Autorität] : Das primäre Signaturkonto (ein EOA), das den Zugriff/die Kontrolle an ein zweites Konto delegiert, bei dem es sich normalerweise um ein Vertragskonto handelt.
• [authorized] : Das Konto, an das [AUTHCALL] -Anweisungen zur Ausführung weitergeleitet werden sollen. Mit anderen Worten, es ist das Konto, in dem die Logik eines [AUTHCALL] im Namen der [Behörde] unter Verwendung von von einem [Aufrufer] definierten Einschränkungen ausgeführt wird.
• [invoker] : Ein Nebenvertrag, der die Interaktionen zwischen dem [autorisierten] Konto und der Logik des [AUTHCALL] verwalten soll, insbesondere in Fällen, in denen die primäre Logik des Vertragscodes des letzteren das Gas-Sponsoring ist.

Invoker-Verträge empfangen [AUTH] -Nachrichten mit einem [COMMIT]-Wert von [authority]; dieser Wert definiert die Beschränkungen, die das Konto der Ausführung von [AUTHCALL] -Anweisungen durch [authorized] auferlegen möchte. Daher sind Invoker dafür verantwortlich, sicherzustellen, dass der in einem [authorized]-Konto definierte [ contract_code ] nicht bösartig ist und die Invarianten erfüllen kann, die vom primären Signaturkonto in einem [COMMIT]-Wert festgelegt wurden.

Der [AUTH] -Opcode hat drei Stackelement-Eingänge; oder einfacher gesagt: er wird durch drei Eingänge definiert, die einen einzigen Ausgang berechnen. Diese Eingänge sind:

1. Behörde : Dies ist die Adresse der EOA, die die Signatur generiert
2. Versatz
3. Länge

Die letzten beiden Eingaben werden verwendet, um einen Bereich des veränderbaren Speichers von 0 bis 97 zu beschreiben, wobei:

1. [memory(offset : offset+1)] – [yParity]
2. [memory(offset+1 : offset+33] – [r]
3. [memory(offset+33 : offset+65)] – [s]
4. [memory(offset+65 : offset+97)] – [COMMIT]

Die Variablen [yParity], [r] und [s] werden gemeinsam als ECDSA-Signatur [magic] auf der secp256k1-Kurve über der Nachricht interpretiert:

[keccak256 (MAGIC || chainID || nonce || invoker address || COMMIT)]

Wo:

• [MAGIC] ist eine ECDSA-Signatur, die sich aus der Kombination der Variablen ergibt:
• [chainID] ist die EIP 115-kompatible Kennung der aktuellen Kette, die zum Schutz vor Replay-Angriffen auf alternative EVM-Ketten mit ähnlicher Historie und geringerer wirtschaftlicher Sicherheit verwendet wird.
• [nonce] ist der aktuelle Nonce der Adresse des Transaktionsunterzeichners, links auf 32 Bytes aufgefüllt.
• [invokerAddress] ist die Adresse des Vertrags, der die Logik für die Ausführung von [AUTH] enthält.
• [COMMIT] ist ein 32-Byte-Wert, der verwendet wird, um zusätzliche Gültigkeitsbedingungen für Transaktionen in der Vorverarbeitungslogik des Aufrufers anzugeben.

Wenn die berechnete Signatur gültig ist und die Adresse des Unterzeichners mit [authority] übereinstimmt, wird das Feld [authorized] auf den von [authority] bereitgestellten Wert aktualisiert. Wenn eine dieser Anforderungen nicht erfüllt ist, bleibt das Feld [authorized] unverändert in seinem vorherigen Zustand oder als nicht festgelegter Wert.

Die Gaskosten für diesen Operationscode errechnen sich aus der Summe folgender Werte:

1. Eine feste Gebühr für die [ecrecover]-Vorkompilierung und zusätzlich für einen Keccak256-Hash und einige zusätzliche Logik im Wert von 3100 Einheiten

2. Eine Speichererweiterungsgebühr, die ähnlich wie der Opcode [RETURN] berechnet wird und angewendet wird, wenn der Speicher über den angegebenen Bereich der aktuellen Zuweisung (97 Einheiten) hinaus erweitert wird.

3. Es fallen Fixkosten von 100 Einheiten für eine warme [Autorität] und 2600 Einheiten für eine kalte [Autorität] an, um Angriffe aufgrund einer falschen Preisgestaltung bei den Opcodes für den Statuszugriff zu verhindern.

   
   

   ( AUTH ist so implementiert, dass der Speicher nicht geändert wird, und verwendet den Wert von [authority] als Argument, sodass dessen Wert ganz einfach anhand der bereitgestellten Signatur überprüft werden kann.)

Der Opcode [AUTHCALL] hat sieben Stapelelement-Eingänge, die zur Berechnung eines einzelnen Stapelelement-Ausgangs verwendet werden.

Es hat dieselbe Logik wie der Opcode [CALL] , d. h. es wird verwendet, um Nachrichtenanrufe an ein Konto zu senden und eine bestimmte Logik in seinen Verträgen auszulösen. Die einzige Abweichung in ihrer Logik besteht darin, dass [AUTHCALL] so konzipiert ist, dass der Wert von [CALLER] festgelegt wird, bevor mit der Ausführung fortgefahren wird.

Daher wird [AUTHCALL] von der [Autorität] verwendet, um kontextspezifisches Verhalten in [Autorisiert] auszulösen, wobei die logischen Prüfungen wie folgt ablaufen:

1. Überprüfen Sie den Wert von [authorized]. Wenn dieser nicht gesetzt ist, wird die Ausführung als ungültig angesehen und der Frame wird sofort verlassen. Dies hilft, unfaire Gebühren aufgrund beispielloser Fehler zu vermeiden.
2. Überprüft die Gaskosten des beabsichtigten Verhaltens von [autorisiert].
3. Überprüft den EIP-150-kompatiblen Wert des [Gas]-Operanden.
4. Überprüft die Verfügbarkeit der gesamten Gaskosten –[Wert]– im Guthaben von [Behörde].
5. Die Ausführung erfolgt nach Abzug von [Wert] vom Kontostand von [Behörde]. Wenn [Wert] höher ist als der Kontostand, ist die Ausführung ungültig.

Die Gaskosten für [AUTHCALL] berechnen sich als Summe aus:

• Feste Kosten für den Aufruf von [warm_storage_read]
• Speichererweiterungskosten [memory_expansion_fee] , die ähnlich wie die Gaskosten für den Opcode [CALL] berechnet werden
• Dynamische Kosten [dynamic_gas]
• Die Ausführungskosten des Subcalls [subcall_gas]

Der Zugriff auf die von einem [AUTHCALL] zurückgegebenen Daten erfolgt über:

• [RETURNDATASIZE] – schiebt die Größe des Rückgabedatenpuffers auf den Ausgabestapel
• [RETURNDATACOPY] – kopiert die Daten aus dem Rückgabedatenpuffer in den Speicher.

Um das Ganze mit weniger Fachjargon zusammenzufassen: Bei Ethereum-Transaktionen werden normalerweise zwei Werte angegeben:

1. tx.origin – erteilt die Autorisierung für die Transaktion.
2. msg.sender – in dem die Transaktion tatsächlich stattfindet.

Bei EOAs ist, wie bereits erwähnt, die Autorisierung eng mit der Ausführung verknüpft, d. h. ( tx.origin == msg.sender ). Diese einfache Invariante führt zu den meisten Problemen, die wir im Unterabschnitt „Konten und Transaktionsgültigkeit“ dieses Berichts erläutert haben.

[AUTH] -Nachrichten von [authority] ermöglichen es, die tx.origin-Funktion auf [authorized] zu verschieben, während der msg.sender erhalten bleibt. Es ermöglicht auch, Einschränkungen dieses Privilegs mithilfe eines [COMMIT]-Werts zu definieren. [AUTHCALL] ermöglicht es [authorized] dann, auf die Logik eines Vertrags zuzugreifen, wobei ein [invoker] als Vermittler verwendet wird, um sicherzustellen, dass der Vertrag, auf den es zugreifen möchte, harmlos ist. Das heißt, für jeden [AUTHCALL] muss [authorized] einen bestimmten [invoker] für sein [COMMIT] angeben.

Mögliche Anwendungen von EIP-3074

EIP 3074 ist in erster Linie dafür verantwortlich, dass EOAs ihre Autorisierungslogik an ein anderes Konto delegieren können. Sein offenes Design ermöglicht jedoch in verschiedenen Kontexten noch viel mehr. Die gesamte Validierungslogik eines EOA kann abstrahiert werden, indem bei Bedarf verschiedene Einschränkungen/Innovationen auf den Aufrufer angewendet werden. Einige der möglichen Designs basierend auf ihrer Ziellogik umfassen:

• Nonce-Logik : EIP-3074 ermöglicht, dass der Nonce der EOAs nach dem Senden einer [AUTH] -Nachricht unberührt bleibt, während sein Nonce für jeden [AUTHCALL] davon abhängt, mit welchem Aufrufer er interagiert. Auf diese Weise ermöglicht es Nonce-Parallelität für EOAs, sodass sie nach Belieben mehrere nicht überlappende [AUTHCALL] s senden können.
• Gaszahlungslogik : Wie im EIP angegeben , können Aufrufer so gestaltet werden, dass sie Gassponsoring ermöglichen. So könnten die Gasgebühren für das [COMMIT] eines Benutzers vom Ursprung der Transaktion oder von jedem unterstützenden Konto abgezogen werden, sei es ein persönliches oder ein servicebasiertes Relay (Gassponsoring-Dienste). Auch die Ausführungslogik ist intuitiv abstrahiert; schließlich ist der Aufrufer (der eine CA ist) nun für die Ausführung von Transaktionsanforderungen im Namen der EOA verantwortlich.

Kritik an EIP-3074

Invoker-Zentralisierung

Zitat eines der Autoren: „ Ich würde nicht erwarten, dass Wallets die Möglichkeit bieten, beliebige Aufrufer zu signieren … “. Das vielleicht größte Problem der 3074-Initiative ist, dass Innovationen auf dieser Grundlage sehr leicht zu genehmigten und proprietären Geschäftsabläufen führen werden; genau wie die aktuellen Iterationen der MEV- (Maximum Extractable Value) und PBS-Märkte (Proposer-Builder Separation) von Ethereum.

Standardmäßig müssen Invoker-Verträge umfassend geprüft werden, um noch schlimmere Angriffe als derzeit möglich zu verhindern. Dies wird unweigerlich zu einem Ökosystem führen, in dem nur eine Handvoll von einflussreichen Persönlichkeiten entwickelter Invoker-Verträge als Standard für Wallet-Entwickler übernommen werden. Es läuft also auf einen Kompromiss zwischen folgenden Punkten hinaus:

• Den harten dezentralen Weg der ständigen Prüfung und Unterstützung von Invoker-Verträgen auf Kosten der Sicherheit der Benutzer einschlagen
• Übernahme von Invoker-Verträgen aus etablierten und seriösen Quellen mit besseren Garantien für die Benutzersicherheit und weniger Überwachung der Vertragssicherheit.

Ein weiterer Aspekt dieses Punktes sind die Kosten, die mit dem Entwerfen, Prüfen und Vermarkten eines funktionalen und sicheren Invokers verbunden sind. Kleinere Teams werden fast immer von größeren Organisationen übertroffen – insbesondere im Marketing –, die bereits einen gewissen Ruf haben, selbst wenn ihr Produkt besser ist.

Probleme mit der Vorwärtskompatibilität

EIP-3074 verankert das ECDSA-Signaturschema, da es immer noch als gültiger gilt als das über den Aufrufer eingeführte Autorisierungsschema. Obwohl es Argumente dafür gibt, dass Quantenresistenz derzeit kein definitives Problem darstellt (und dass in einer Zukunft, in der ECDSA korrumpierbar ist, viel Schlimmeres auf dem Spiel steht), besteht Ethereums eher unausgesprochenes Ziel darin, solchen Problemen immer einen Schritt voraus zu sein. Die Quanten- und Zensurresistenz möglicherweise für geringfügige Verbesserungen der UX zu opfern, ist in naher Zukunft möglicherweise nicht die beste Wahl.

Ein weiterer Punkt zum Argument der Vorwärtskompatibilität ist, dass die Vorteile von 3074 zwar noch bewertet wurden, es aber für ERC-4337 (das keine Protokolländerungen erfordert) mittlerweile einen großen Markt gibt, sodass Sie auch mit diesem kompatibel sein müssen, um eine Abschottung der Ökosysteme zu vermeiden. Selbst mit der Roadmap für die native Kontoabstraktion würden die Opcodes [AUTH] und [AUTHCALL] im EVM irgendwann obsolet werden, was eine Menge technischer Schulden für Ethereum bedeuten würde, um eine marginale UX-Verbesserung zu erzielen.

Unwiderruflichkeit des ECDSA-Programms

Nach dem Senden einer [AUTH] -Nachricht und der Delegierung der Kontrolle wird erwartet, dass der EOA das übliche Autorisierungsschema für private Schlüssel vermeidet, da das Senden einer „normalen“ Transaktion dazu führt, dass die Autorisierung, die er an jeden Aufrufer delegiert hat, widerrufen wird. Somit bleibt das ECDSA-Schema jedem anderen Autorisierungsschema, das die zugehörigen Verträge ermöglichen können, streng überlegen, was bedeutet, dass ein Verlust privater Schlüssel zu einem vollständigen Verlust der Vermögenswerte des Kontos führen würde.

Programmierbarkeit über EIP-7702

Dieser Vorschlag war ursprünglich als etwas minimalistische Variante von EIP 3074 gedacht und sollte sogar eine Aktualisierung davon sein. Er wurde ins Leben gerufen, um die angeblichen Ineffizienzen von EIP 3074 zu beheben, insbesondere die Bedenken hinsichtlich seiner Inkompatibilität mit dem bereits florierenden 4337-Ökosystem und dem nativen Kontoabstraktionsvorschlag – RIP 7560.

Sein Ansatz besteht in der Hinzufügung eines neuen EIP 2718-kompatiblen Transaktionstyps – [SET_CODE_TX_TYPE] –, der es einem EOA ermöglicht, sich für bestimmte Transaktionen wie ein Smart Account zu verhalten. Dieses Design ermöglicht dieselben Funktionen wie EIP 5806 und einige mehr, bleibt aber mit der nativen Account-Abstraktions-Roadmap und bestehenden Initiativen kompatibel.

EIP-7702-Spezifikationen

EIP-7702 ermöglicht es einem EOA, den Codeinhalt eines Vertrags durch eine [SET_CODE_TX_TYPE] 2718-kompatible Transaktion im folgenden Format zu „importieren“:

 rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Diese Nutzlast ist der von EIP 5806 völlig ähnlich, außer dass sie eine „Autorisierungsliste“ einführt. Diese Liste ist eine geordnete Folge von Werten im Format:

[[chain_id, address, nonce, y_parity, r, s], ...]

wobei jedes Tupel den Wert von [Adresse] definiert.

Bevor Sie fortfahren, sind die an einem SET_CODE_TX_TYPE beteiligten Parteien:

• [authority] : das ist das EOA/primäre Signaturkonto
• [Adresse] : Dies ist die Adresse eines Kontos, das delegierbaren Code enthält.

Wenn [Behörde] einen SET_CODE_TX_TYPE unter Angabe von [Adresse] signiert, wird ein Delegationsdesignator erstellt. Dies ist ein „Zeigerprogramm“, das alle Codeabrufanforderungen aufgrund der Aktionen von [Behörde] zu jedem beliebigen Zeitpunkt an den beobachtbaren Code von [Adresse] weiterleitet.

Für jedes Tupel [chain_id, address, nonce, y_parity, r, s] ist der logische Ablauf einer Transaktion vom Typ 7702 wie folgt:

1. Überprüfung der Signatur von [authority] anhand des bereitgestellten Hashs mithilfe von: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Verhinderung von Cross-Chain-Replay-Angriffen und anderen Angriffsvektoren durch Überprüfung der Chain-ID.
3. Überprüfen, ob [Behörde] bereits Codeinhalte hat.
4. Nonce-Prüfung, um sicherzustellen, dass der Nonce von [authority] mit dem im Tupel enthaltenen Nonce übereinstimmt.
5. Wenn es sich bei der Transaktion um die erste SET_CODE_TX_TYPE -Transaktion von [authority] handelt, wird eine Gebühr von PER_EMPTY_ACCOUNT_COST erhoben. Falls der Saldo geringer als der Wert dieser Gebühr ist, wird der Vorgang abgebrochen.
6. Es erfolgt eine Delegationsbenennung, wobei der Code der [Behörde] auf einen Zeiger der [Adresse] gesetzt wird.
7. Der Nonce des Unterzeichners –[authority]– wird um eins erhöht.
8. [Autorität] wird zu einer Liste mit aufgerufenen Adressen hinzugefügt. Dabei handelt es sich (vereinfacht) um eine Reihe von Adressen, die so angelegt sind, dass die Rücknahme eines Transaktionsumfangs dazu führt, dass sie (die Adresse) auf ihren vorherigen Zustand zurückgesetzt werden, bevor der zurückgenommene Umfang eingegeben wurde. Dies ist in EIP-2929 definiert, um das Zwischenspeichern wiederverwendbarer Werte zu ermöglichen und unnötige Gebühren zu vermeiden.

Puh! Um das Ganze noch einmal zusammenzufassen: Dieses EIP ermöglicht es EOAs, Transaktionen zu senden, die einen Zeiger auf den Code eines Vertrags setzen, sodass sie diese Logik in nachfolgenden Transaktionen als ihre eigene implementieren können. In dieser Hinsicht ist es streng stärker als EIP 5806, da es EOAs ermöglicht, tatsächlich so lange Codeinhalte zu haben, wie sie möchten (im Gegensatz zu EIP 5806, das EOAs lediglich das Senden von Delegiertenaufrufen ermöglicht).

Mögliche Anwendungen von EIP-7702

Ausführungsabstraktion

Man könnte zwar argumentieren, dass es sich nicht mehr um eine Abstraktion handelt, da der EOA die Logik, die er ausführen möchte, aktiv aufnimmt, aber er ist immer noch nicht der „primäre Eigentümer“ dieser Logik. Außerdem enthält er nicht direkt die Logik, sondern gibt lediglich einen Zeiger auf die Logik an (um die Rechenkomplexität zu reduzieren). Wir entscheiden uns also für die Ausführungsabstraktion!

Gas-Sponsoring

Obwohl die Invariante require(msg.sender == tx.origin) gebrochen ist, um Selbstsponsoring zu ermöglichen, erlaubt das EIP weiterhin die Integration gesponserter Transaktions-Relayer. Allerdings besteht die Einschränkung darin, dass solche Relayer ein auf Reputation oder Einsatz basierendes System benötigen, um Griefing-Angriffe zu verhindern.

Richtlinien für bedingten Zugriff

EOAs können nur auf einen bestimmten Teil des Kontocodes verweisen, sodass in ihrem Kontext nur die Logik dieses Teils ausführbar ist.

Dies ermöglicht auch die Existenz von Unterschlüsseln , die eine „Privilegien-Deeskalation“ ermöglichen, sodass bestimmte Dapps nur unter bestimmten Bedingungen Zugriff auf den Kontostand haben. Man könnte sich beispielsweise eine Berechtigung vorstellen, ERC-20-Token, aber nicht ETH, auszugeben, bis zu 1 % des Gesamtguthabens pro Tag auszugeben oder nur mit bestimmten Anwendungen zu interagieren.

Cross-Chain-Bereitstellung von Smart Contracts

Aufgrund seiner nicht restriktiven Natur könnte eine EIP-7702-Transaktion einem Benutzer den Zugriff auf den CREATE2-Opcode ermöglichen und ihn verwenden, um Bytecode an eine Adresse ohne andere restriktive Parameter wie Gebührenmarktlogik bereitzustellen (z. B. EIP-1559 und EIP-4844). Dadurch kann die Adresse wiederhergestellt und über mehrere Zustandsmaschinen hinweg mit demselben Bytecode verwendet werden, wobei sein Konto in jeder Kette dann für die Definition der anderen kontextvariablen Parameter verantwortlich ist.

Kritik an EIP-7702

Fehlende Abwärtskompatibilität

Obwohl EIP-7702 noch sehr neu ist, wurden bereits viele Prototypen erstellt und auf Abhängigkeiten und potenzielle Nachteile getestet. Das minimalistische Modell garantiert jedoch viel Flexibilität und damit Nutzen in verschiedenen Kontexten. Allerdings bricht es viel zu viele Invarianten und ist nicht sofort abwärtskompatibel. Einige der Logiken von EIP-7702 umfassen:

1. Änderung des EOA-Nonce während einer Transaktion: EIP-7702 begrenzt keine Opcodes, um Konsistenz zu gewährleisten. Dies bedeutet, dass ein EOA Opcodes wie CREATE , CREATE2 und SSTORE implementieren kann, während eine EIP-7702-Transaktion ausgeführt wird, wodurch sein Nonce in einem anderen Kontext erhöht werden kann.
2. Konten mit einem codeHash Wert ungleich Null als Transaktionsinitiatoren zulassen: EIP-3607 wurde implementiert, um die möglichen Folgen einer „Adresskollision“ zwischen EOAs und CAs zu verringern. Eine Adresskollision tritt auf, wenn der 160-Bit-Wert der Adresse eines EOA vollständig mit dem der Adresse einer CA übereinstimmt.

Die meisten Benutzer kennen den tatsächlichen Inhalt eines Kontos nicht (oder wissen nicht einmal, was der Unterschied zwischen einem Konto und einer Adresse ist!), sodass Adresskollisionen dazu führen, dass sich ein EOA als Vertragskonto tarnen und auf umständliche Weise Benutzergelder anlocken könnte, um schließlich alles zu stehlen. EIP-3607 ging dieses Problem an, indem festgelegt wurde, dass Konten, die Code enthalten, ihr Guthaben nicht mithilfe ihrer eigenen Autorisierungslogik ausgeben können sollten. EIP 7702 bricht diese Invariante jedoch, um es EOAs zu ermöglichen, auch nach Erlangung einer gewissen Programmierbarkeit autonom zu bleiben.

Ähnlichkeit mit EIP-3074

Das Überschreiben der Adresse eines Kontos anstelle seines Codeinhalts ist im Grunde dasselbe wie das Schema von 3074 mit Aufrufern. Es bietet keine strengen Garantien hinsichtlich der Konsistenz des Codeinhalts über verschiedene Ketten hinweg, da eine Adresse auf verschiedenen Ketten einen unterschiedlichen Codeinhalt annehmen könnte. Dies bedeutet, dass eine Adresse, deren Codeinhalt auf einer Kette dieselbe Logik enthält, auf einer anderen Kette räuberisch oder geradezu böswillig sein könnte, und dies könnte zum Verlust von Benutzergeldern führen.

Abschluss

EOAs in ihrer aktuellen Form sind stark eingeschränkt, da sie es Benutzern nicht ermöglichen, die Programmierfunktionen des EVM zu nutzen. Obwohl es verschiedene Möglichkeiten gibt, Konten zu aktualisieren, wie wir zu Beginn dieses Berichts dargelegt haben, muss die gewählte Lösung die Grundsätze der sicheren Selbstverwahrung einhalten. Darüber hinaus können EOA-Upgrades sowohl die Benutzererfahrung als auch die Anwendungsentwickler erheblich beeinträchtigen, sodass die Stimmen aller Beteiligten berücksichtigt werden müssen.

Wenn EOAs Code auf beliebige Weise ausführen dürfen, wird die Funktionalität von Konten enorm erweitert, aber diese neue Ausdrucksmöglichkeit bringt erhebliche Risiken und mögliche Blindseiten mit sich. Die Lösung dieser Kompromisse ist entscheidend, um ein Upgrade mit unbestrittenen UX-Vorteilen für Ethereum-Benutzer bereitzustellen.

Ethereums Kultur der offenen Diskussion macht es zu einem großartigen Testgelände für solche Innovationen, da fast jede Implikation jedes Designs von Fachexperten gründlich dekonstruiert wird. Diese umfassende Betrachtung sollte dazu beitragen, das Risiko von Amtsmissbrauch durch Gegner zu verringern.

EIP-7702 ist derzeit das Paradebeispiel für Mechanismen, die EVM-Programmierbarkeit in EOAs bringen wollen, da es als Ersatz für den Steckplatz von EIP 3074 im Pectra-Upgrade vorgesehen ist. Es übernimmt das offene Design des 3074-Mechanismus und verringert gleichzeitig die Angriffsfläche/Risiken erheblich. Es ermöglicht außerdem viel mehr, indem es die Beschränkungen von 3074 auf bestimmte Opcode-Klassen umgeht.

Obwohl noch an der Ausgestaltung des Vorschlags gearbeitet wird, hat er bereits viel Wohlwollen und Unterstützung von Entwicklern erhalten, insbesondere da Vitalik ihn direkt unterstützt. Innerhalb der Community gibt es Behauptungen, dass dieser Ansatz zur Kontoabstraktion sogar besser sein könnte als Smart Accounts. Dieser Kommentar betont, dass dieser Weg weniger Änderungen erfordert und nicht so komplex ist und dass EOAs bereits verankert sind.

Wir müssen jedoch den zukünftigen Sicherheitsmeilenstein der Quantenresistenz auf jeder Ebene des Ethereum-Netzwerks im Auge behalten. Diese Quantensicherheit ist mit dem aktuellen Kontomodellkern aufgrund der Verwendung von ECDSA-basierten Signaturschemata für die EOA-Autorisierung nicht umsetzbar.

Daher ist die EOA-Programmierbarkeit als ein Schritt auf dem Weg zu Smart Accounts zu sehen und nicht als das Ziel. Sie lädt EOAs auf und ermöglicht eine bessere Benutzer- und Entwicklererfahrung, während sie gleichzeitig mit dem ultimativen Kontoabstraktionsziel von Smart Accounts kompatibel bleibt.

In unserem nächsten Bericht werden wir uns eingehender mit EOA-Migrationsschemata befassen, um zu sehen, wie gut sie in die Roadmap zur Kontoabstraktion passen. Bleiben Sie dran!