Zum Inhalt springen

Account Abstraction: Vergangenheit, Gegenwart, Zukunft

Erfahre mehr über Account Abstraction in Ethereum – was es bedeutet und warum es wichtig ist.

15 Min. Lesezeit
Account Abstraction: Vergangenheit, Gegenwart, Zukunft

Auch wenn ein Bärenmarkt tobt, zweifeln nur wenige daran, dass Krypto gekommen ist, um zu bleiben – Wallets wie MetaMask verzeichnen bereits Millionen von Nutzern. Dennoch bleibt die Frage bestehen: „Wie bringen wir die nächste Milliarde Nutzer ins Web3?"

Je nachdem, wen man fragt, fallen die Antworten unterschiedlich aus. Doch alle sind sich in einigen Punkten einig – insbesondere was die Notwendigkeit betrifft, die Nutzererfahrung bei der Interaktion mit Blockchain-Anwendungen zu verbessern. Ohne eine benutzerfreundlichere Gestaltung von Web3 haben Menschen kaum einen Anreiz, von den Web2-Apps, die sie täglich nutzen, zu wechseln.

„Account Abstraction" ist ein Vorschlag zur Verbesserung der Nutzerinteraktionen mit Ethereum – ein Thema, das in der Krypto-Community zunehmend diskutiert wird. Vielleicht fragst du dich jedoch: „Was genau ist Account Abstraction und warum sollte mich das interessieren?"

Dieser Artikel soll dir helfen, Account Abstraction besser zu verstehen, indem Vergangenheit, Gegenwart und Zukunft in einen Kontext gesetzt werden. Wir beantworten alle Fragen, die du zu diesem Thema haben könntest – konkret: Wer, Was, Warum, Wie und Wann bei Account Abstraction.

Eine kurze Zusammenfassung der wichtigsten Punkte:

  • Programmierbare, selbstverwaltete Konten („Smart Accounts") können die Hürden beim Onboarding neuer Nutzer ins Web3-Ökosystem senken. Allerdings verhindern Einschränkungen im Design von Ethereum eine breite Einführung und Nutzung von Smart Accounts.

  • Account Abstraction bringt bedeutende Änderungen mit sich, die den Weg für eine weitreichende Einführung von vertrauensfreien, zensurresistenten Smart Accounts ebnen. Verschiedene Ansätze zur Implementierung von Account Abstraction werden erwogen – jeder mit einzigartigen Vorteilen und Kompromissen.

  • MetaMask unterstützt die Einführung von Account Abstraction durch seine permissionless Innovationsplattform: MetaMask Snaps. Mit MetaMask Snaps können Entwickler MetaMask erweitern, um die Vorteile von Account Abstraction für Krypto-Nutzer weltweit zugänglich zu machen.

Was ist Account Abstraction?

Wie jedes andere neue Konzept im Web3 kann Account Abstraction schwer zu definieren sein. Dennoch können wir es besser verstehen, indem wir zunächst die verschiedenen Begriffe entschlüsseln, die für die Diskussion über Account Abstraction in Ethereum relevant sind:

  1. Abstraction (Subst.): Ein (ziemlich komplexer) Begriff aus der Informatik, der grob bedeutet, Informationen über ein System oder eine Anwendung zu verbergen, sodass es mit weniger Kenntnissen über die im Hintergrund ablaufenden Prozesse genutzt werden kann. Auch definiert als „der Prozess, die Komplexität eines Systems zu verbergen, indem eine Schnittstelle bereitgestellt wird, die seine Handhabung erleichtert."

  2. Account (Subst.): Die Repräsentation eines Nutzers auf der Blockchain, die Transaktionen senden oder empfangen und mit anderen On-Chain-Konten interagieren kann. Ethereum hat zwei Arten von Konten: Externally Owned Accounts (EOAs) und Contract Accounts (auch bekannt als „Smart Contracts").

2a. Externally Owned Accounts (EOA): Ethereum-Konten, die mithilfe von Wallet-Software (wie MetaMask) erstellt und durch ein kryptografisches Paar aus öffentlichem und privatem Schlüssel verwaltet werden. Ein EOA ist „aktiv" (es kann Transaktionen initiieren und Gasgebühren für die EVM-Ausführung bezahlen). Es ist jedoch auf grundlegende Operationen beschränkt – wie das Senden von Ether oder die Interaktion mit Contracts.

2b. Contract Accounts: Ethereum-Konten, die als Smart Contract bereitgestellt und durch im Code geschriebene Logik gesteuert werden (anstatt durch einen privaten Schlüssel). Ein Contract Account ist „passiv": Es kann Transaktionen nur als Reaktion auf eine Transaktion von einem EOA senden und kann keine Gasgebühren bezahlen. Es ist jedoch programmierbar und kann beliebige Logik ausführen, die im Code an der Adresse hinterlegt ist.

  1. Wallet (Subst.): Eine Schnittstelle zur Verwaltung der Mittel in deinem Ethereum-Konto – wie eine Wallet funktioniert, hängt davon ab, mit welchem Kontotyp sie verknüpft ist. Eine EOA-basierte Wallet wie MetaMask benötigt einen privaten Schlüssel zur Autorisierung von Transaktionen. Eine Smart Contract Wallet hingegen ist mit einem Contract Account verknüpft und kann beliebige Logik zur Autorisierung von Transaktionen verwenden (z. B. ein Multisignatur-Schema).

Nachdem diese Definitionen geklärt sind, können wir nun Account Abstraction definieren.

Account Abstraction definieren

Account Abstraction ist ein Vorschlag zur Erhöhung der Flexibilität bei der Verwaltung und dem Verhalten von Ethereum-Konten. Dies wird durch die Einführung von Account Contracts erreicht: zweckgebundene Smart Contracts, die das Ethereum-Konto eines Nutzers definieren und verwalten (jetzt Smart Account genannt).

Mit Account Abstraction kannst du programmierbaren Zugriff auf Mittel genießen, indem du eine Smart Contract Wallet verwendest, anstatt dich ausschließlich auf private Schlüssel für die Sicherheit zu verlassen. Dies ist möglich, weil dein Smart Account benutzerdefinierte Regeln für das Ausgeben von Coins und das Übertragen von Assets haben kann.

Wie passt nun „Abstraction" in all das?

Aus Netzwerkperspektive bedeutet „Account Abstraction", dass die Details der Kontotypen für das Ethereum-Protokoll unsichtbar sind. Jedes Konto (einschließlich selbstverwalteter Konten) ist einfach ein Smart Contract, und Nutzer können frei bestimmen, wie einzelne Konten verwaltet und betrieben werden.

Aus Nutzerperspektive bedeutet „Account Abstraction", dass bestimmte technische Details der Interaktion mit Ethereum-Konten hinter übergeordneten Schnittstellen verborgen werden. Dies verbessert Wallet-Designs und reduziert die Komplexität der Nutzung von Web3-Anwendungen erheblich.

Diese Klarstellung ist notwendig, weil die Verwirrung rund um Account Abstraction daher rührt, dass man nicht weiß, (a) was abstrahiert wird und (b) wo die Abstraktion stattfindet. Konten werden nicht zwingend von Nutzern abstrahiert (auch wenn sie vom Protokoll abstrahiert werden). Du hast weiterhin eine Wallet-Adresse zum Empfangen von Mitteln und einen Signing Key, der sicherstellt, dass nur du diese Mittel ausgeben kannst.

Aus deiner Perspektive ist Account Abstraction eher so, als würdest du einen Smart Account verwenden, der einige Details der Blockchain-Interaktion abstrahiert. Zum Verständnis: So sieht die Interaktion mit einer Dapp aus der Perspektive eines Erstnutzers aus:

Mit Account Abstraction können Wallet-Entwickler Systeme erstellen, die diese Prozesse im Hintergrund abwickeln und die Nutzung von Web3 vereinfachen (Kurzfassung: Wallets werden „unsichtbar"). Einige Anwendungsfälle (auf die wir später eingehen werden) umfassen: die Notwendigkeit zu eliminieren, Seed Phrases/private Schlüssel zu speichern, Gasgebühren für Transaktionen zu bezahlen oder sogar selbst ein On-Chain-Konto einzurichten.

Die Vorteile von Account Abstraction

Wie bereits erwähnt, beseitigt Account Abstraction den Großteil der Reibungspunkte bei der Nutzung von Web3-Wallets und der Interaktion mit Dapps. Dies bringt Web3 näher an das Ideal von Web2, wo alle Nutzer – sowohl Anfänger als auch Erfahrene – vom gleichen Maß an Flexibilität, Sicherheit und Benutzerfreundlichkeit profitieren können.

Insbesondere hat Account Abstraction enorme Auswirkungen auf die Zukunft der Selbstverwahrung. Mit den Funktionen, die Account Contracts bieten, wird die Nutzung einer Web3-Wallet sich anfühlen wie die Nutzung eines Bankkontos oder einer Anwendung – ohne der Bank vertrauen zu müssen.

In den folgenden Abschnitten werden wir die verschiedenen Dimensionen von Account Abstraction beleuchten und erörtern, wie sie die Nutzungserfahrung von Ethereum verbessern. Konkret sprechen wir über Signature Abstraction, Fee Abstraction und Nonce Abstraction.

Signature Abstraction

Heute müssen Transaktionen von deinem EOA eine Signatur haben, die mit dem privaten Schlüssel des Kontos unter Verwendung des Elliptic Curve Digital Signature Algorithm (ECDSA) generiert wurde, um gültig zu sein. Dies gibt den meisten EOAs ein einfaches Sicherheitsmodell: Mittel sind sicher, solange private Schlüssel im Besitz des Nutzers bleiben. Es hat jedoch auch einige Einschränkungen:

  1. EOAs sind notorisch schwer zu sichern, insbesondere da böswillige Akteure ständig neue Wege entwickeln, private Schlüssel zu kompromittieren. Bei MetaMask haben wir aus erster Hand die Herausforderungen erlebt, die Phishing, Social Engineering, Spoofing, Malware-Injektion und ähnliche Angriffe für die Nutzersicherheit im Web3 darstellen.

  2. Selbstverwahrung kann sich wie ein Extremsport anfühlen. Anders als bei einem regulären Bankkonto kannst du eine EOA-Wallet nicht „wiederherstellen", wenn die Seed Phrase/der private Schlüssel verloren geht. Dies stellt eine Herausforderung für neue Nutzer dar, die sich mit den Konsequenzen des vollständigen Verlusts von Assets in Ethereum-Konten ohne jeglichen Ausweg auseinandersetzen müssen.

Signature Abstraction löst diese Probleme, indem ECDSA-Signaturen als Standard-Autorisierungsmechanismus für nicht-verwahrte Konten abgeschafft werden. Stattdessen können Nutzer benutzerdefinierte Regeln für die Autorisierung von Wallets zur Initiierung von Transaktionen festlegen. Anders ausgedrückt: Du kannst entscheiden, was es bedeutet, dass eine Transaktion gültig ist.

Die Implementierung von Signature Abstraction eröffnet Möglichkeiten für fortschrittlichere Autorisierungsschemata. Auf diese Weise wird die Nutzung deiner Web3-Wallet sich ähnlich anfühlen wie – wenn nicht besser als – eine Web2-Banking-Anwendung. Hier sind einige Anwendungsfälle:

  1. Transaktionslimits: Eine mit deinem Smart Account verknüpfte Wallet kann eine Transaktion ablehnen (oder eine zusätzliche Autorisierung anfordern), wenn der Wert ein voreingestelltes Limit überschreitet. Klingt bekannt? Das sollte es – Banken machen das bereits, um deine Konten und Kreditkarten vor Betrug, unbefugter Nutzung und anderen sicherheitsrelevanten Gründen zu schützen.

  2. Mehrseitige Genehmigungen: Du könntest die teilweise Kontrolle über dein Konto an vertrauenswürdige Parteien, sogenannte „Guardians", delegieren. Guardians können Freunde, Familienmitglieder, Dienstleister oder sogar ein separates Gerät sein, das dir gehört (z. B. eine Hardware Wallet). So kannst du Web2-ähnliche Multi-Faktor-Authentifizierung (MFA) für deine Wallet aktivieren, indem du die Genehmigung der Guardians für Transaktionen verlangst, die Mittel von deinem Smart Account abheben.

  1. Schlüsselrotation und -widerruf: Mit Smart Accounts kannst du einen neuen Signing Key generieren, wenn der vorherige verloren gegangen oder gestohlen wurde. Für zusätzliche Sicherheit können Guardians dein Konto während des Wiederherstellungsprozesses einfrieren und die Genehmigung für Schlüsselrotations-/Widerrufsvorgänge verlangen (d. h. Social Recovery). Dies ähnelt dem Einfrieren deiner Kreditkarte, wenn sie verlegt/gestohlen wurde, ohne den Zugang zu deinem Bankkonto zu verlieren.

  2. Vertrauenswürdige Sessions: Nervt es dich, bei der Interaktion mit einer Dapp in deinem Browser jede Aktion genehmigen zu müssen? Kein Problem! Du kannst spezielle „Session Keys" mit deinem Smart Account erstellen, damit Dapps für einen bestimmten Zeitraum automatisch Transaktionen signieren. Das bedeutet, du kannst mit Dapps interagieren – zum Beispiel ein Blockchain-Spiel spielen – ohne ständig von Wallet-Pop-ups unterbrochen zu werden.

Auf hohem Niveau basieren Session Keys auf einem Smart Contract, der die Interaktionen zwischen deinem Konto und einer Dapp steuert. Du hast immer die Kontrolle über Session Keys und kannst die Signing-Berechtigung der Dapp regulieren, z. B. wie viel sie von deinem Guthaben abziehen oder welche Funktionen sie aufrufen kann.

  1. Automatische Zahlungen: Ähnlich wie bei Session Keys kannst du Dienstleister genehmigen, Mittel von deinem Smart Account „abzurufen" (vorbehaltlich vordefinierter Regeln). Dies ermöglicht es, wiederkehrende Zahlungen und Abonnements einzurichten mit deiner Web3-Wallet. Kannst du dir vorstellen, ein Netflix-Abonnement oder eine Stromrechnung mit deinem Ethereum-Konto zu bezahlen?

Fee Abstraction

Derzeit muss jede Ethereum-Transaktion eine „Gasgebühr" enthalten, die angibt, wie viel das sendende EOA für die Ausführung zu zahlen bereit ist. Gasgebühren werden in Ether, Ethereums nativer Token, denominiert. Dies schafft Probleme, insbesondere für neue Nutzer, die zunächst ETH beschaffen müssen, bevor sie ihre Transaktion senden können.

Account Abstraction eliminiert nicht die Notwendigkeit, Gasgebühren zu zahlen, abstrahiert jedoch die Details darüber, wie und wann Nutzer für Gas zahlen (Fee Abstraction). Zum Beispiel ermöglicht Account Abstraction „gesponserte Transaktionen", bei denen ein anderes Konto die Gaskosten für die Transaktion eines Nutzers übernimmt. Einige Vorteile gesponserter Transaktionen:

  1. Gasgebühren in Nicht-ETH-Token: Hast du dir jemals gewünscht, Transaktionsgebühren mit ERC-20-Token in deiner Wallet bezahlen zu können? Mit gesponserten Transaktionen kannst du einen Relayer mit ETH dazu bringen, die Kosten für deine Transaktionen vorzustrecken, und ihn in einem anderen Token wie DAI oder USDC zurückzuzahlen.

  1. Gasfreie Transaktionen: Dapp-Entwickler können Transaktionen sponsern und die Onboarding-Hürden für neue Ethereum-Nutzer minimieren. Du könntest im Wesentlichen Web3-Apps nutzen, ohne irgendetwas über „Gas" zu wissen, und die gleiche Ein-Klick-Erfahrung genießen, die Web2-Apps bieten.

  1. Social Logins: Eine Dapp könnte in deinem Namen eine Contract Wallet bereitstellen und so den Schmerzpunkt des Einrichtens einer Wallet vor dem Senden von On-Chain-Transaktionen lösen. Das Beste daran? Wallets können Authentifizierungsinfrastruktur (z. B. Web3Auth und WebAuthn) nutzen, um Nutzern die Erstellung von Web3-Konten mit bestehenden Anmeldedaten wie einer E-Mail-Adresse oder einem Facebook/Twitter-Konto zu ermöglichen.

Nonce Abstraction

Smart Accounts auf Ethereum haben eine weitere besondere Funktion: Transaction Batching. Mit gebündelten Transaktionen kannst du mehrere Operationen in einer einzigen On-Chain-Transaktion zusammenfassen und die Kosten und Komplexität der Interaktion mit Dapps reduzieren. Hier ist, warum Transaction Batching wichtig ist:

Dein EOA speichert einen Wert, der als „Nonce" bekannt ist und anzeigt, wie viele Transaktionen du gesendet hast (stell es dir wie einen Transaktionszähler vor). Eine neue Transaktion muss die Nonce strikt um 1 erhöhen, um gültig zu sein – eine Regel, die verhindert, dass jemand anderes dieselbe Transaktion „wiederabspielt", um deine Mittel zu stehlen (ja, das kann passieren).

Aber es gibt einen Haken. Nonces zwingen dich dazu, Transaktionen nach dem First-in-First-out-Prinzip (FIFO) zu verarbeiten. Stell dir vor, du hast zwei Transaktionen (A und B) mit einer Nonce von 0 bzw. 1. In diesem Fall würdest du Transaktion A senden und auf eine Bestätigung (ihrer Ausführung) warten, bevor du B sendest.

B zu senden, während A noch ausstehend ist, würde dazu führen, dass Erstere einfach abgelehnt wird, da die Nonce höher wäre als der vorgeschriebene Bereich (aktuelle Nonce des EOA + 1). Tatsächlich ist dies ein wesentlicher Grund, warum du „feststeckende Transaktionen" hast, wenn du eine Wallet verwendest.

Nonce Abstraction ermöglicht es dir, benutzerdefinierte Replay-Schutzmechanismen zu erstellen (anstatt dass das Ethereum-Protokoll eine strikte Reihenfolge bei Transaktionen erzwingt). Zum Beispiel kannst du ein Nonce-Schema haben, das die parallele Verarbeitung mehrerer Transaktionen erlaubt. Dies würde das Problem verstopfter/feststeckender Transaktionen lösen und die Interaktionen mit Dapps erheblich verbessern.

Allerdings ist Nonce Abstraction in der Praxis schwer zu implementieren und kann potenziell bestimmte Invarianten gefährden, die für Sicherheit und UX entscheidend sind, wie z. B. die Eindeutigkeit von Transaktions-Hashes. Hier kommt Transaction Batching ins Spiel:

Da Smart Accounts mehrere Transaktionen gleichzeitig verarbeiten können, entfällt weitgehend die Notwendigkeit komplexer Nonce-Abstraktionsschemata. Zurück zum vorherigen Beispiel: Wir können uns vorstellen, dass Transaktion A und B lediglich Teile einer einzigen hypothetischen Operation sind, wie dem Tauschen von Assets auf Uniswap:

  • Transaktion A: Den Uniswap-Contract genehmigen, auf deine Token zuzugreifen

  • Transaktion B: Den Token-Swap abschließen

Mit Transaction Batching kannst du den Approve-and-Swap-Workflow in eine einzige Transaktion zusammenfassen. Das Ergebnis: niedrigere Gasgebühren und kürzere Wartezeiten bei der Nutzung von Dapps. Cool, oder?

Das „Wie" von Account Abstraction

An diesem Punkt weißt du bereits, dass Account Abstraction es uns ermöglicht, benutzerdefinierte Funktionalitäten und Autorisierungsrichtlinien zu Nutzerkonten hinzuzufügen. Aber wir haben noch nicht wirklich darüber gesprochen, wie das möglich ist. Dieser Abschnitt behandelt verschiedene Ansätze zur Implementierung von Abstraction auf Ethereum (falls das nicht besonders ansprechend klingt, kannst du gerne zum nächsten Abschnitt springen).

Es gibt zwei allgemein anerkannte Wege, Account Abstraction zu erreichen: (a) EOAs EVM-Code ausführen zu lassen und (b) Smart Contracts zu erlauben, Transaktionen zu initiieren. Daher wirst du feststellen, dass viele Account-Abstraction-Vorschläge entweder wollen, dass EOAs sich wie Smart Contracts verhalten, oder dass Contract Accounts wie EOAs agieren.

Dies wirft natürlich einige Fragen auf:

  • „Wie genau unterscheiden sich diese Ansätze?"

  • „Warum ist es wichtig, welchen Ansatz wir wählen?"

Account Abstraction: Ansatz #1 (EOAs upgraden, um Code auszuführen)

Indem wir EOAs die Fähigkeit geben, Code auszuführen, können wir komplexe Funktionalitäten zu nutzerkontrollierten Konten hinzufügen. Dies verleiht EOAs Superkräfte und verwandelt sie in Smart Accounts, was die Grundlage für native Account Abstraction schafft. Wichtig ist, dass dieser Ansatz es dir ermöglicht, die Vorteile einer programmierbaren Wallet zu genießen, ohne die Kosten für die Bereitstellung eines neuen Contract Accounts zu tragen.

Einige Ansätze zum Upgrade von EOAs zu Contract Accounts beinhalten die Behandlung der Daten-Payload von EOA-Transaktionen als EVM-Bytecode. Andere beinhalten die Delegation der Kontrolle eines EOA an einen speziellen Account Contract, der Transaktionen im Namen des EOA durchführt. Im letzteren Fall kann derselbe Account Contract von verschiedenen EOAs wiederverwendet werden, was den Bedarf an unterschiedlichen Contract-Wallet-Implementierungen reduziert.

Unten ist eine Infografik, die verschiedene Account-Abstraction-Vorschläge im Lager „EOAs programmierbar machen" zeigt, einschließlich ihrer wichtigsten Merkmale und des Implementierungsstatus:

Account Abstraction: Ansatz #2 (Smart Contracts upgraden)

Bei diesem Ansatz upgraden wir Contract Accounts, damit sie Transaktionen genehmigen und Gasgebühren bezahlen können (genau wie EOAs). Dies bietet einen weiteren Weg zur Erreichung von Account Abstraction durch die Einführung von „aufgewerteten Contracts", die als EOAs agieren können (d. h. Account Contracts). Außerdem löst es ein drängendes Problem in Ethereum: fehlende Unterstützung für Contract Wallets auf Protokollebene.

Denn – einige Smart Contract Wallets existieren bereits heute und bieten viele Vorteile von Account Abstraction. Die Nutzung dieser Wallets kann jedoch unglaublich schwierig sein, weil Ethereum Smart Contracts als „Bürger zweiter Klasse" behandelt und verlangt, dass alle Transaktionen von einem EOA ausgehen.

Diese Einschränkung bedeutet auch, dass Smart Contract Wallets nicht die Vertrauensfreiheit und Selbstverwahrungsnatur von EOA-Wallets wie MetaMask besitzen. Zum Verständnis: Betrachten wir den Ablauf der Erstellung und Nutzung einer Smart Contract Wallet:

  • Einen neuen Contract Account bereitstellen

  • Transaktionen senden, um Funktionen auf deinem Wallet-Contract aufzurufen

Das Problem ist bereits offensichtlich: Du musst jetzt zwei Wallets verwalten. Warum? Ein EOA (mit ETH vorfinanziert) muss die Kosten für die Bereitstellung der Wallet und den anschließenden Aufruf notwendiger Funktionen decken.

Hier kommen Relayer ins Spiel: EOAs, die für die Transaktionen deiner Wallet gegen eine Gebühr bezahlen können. Anbieter von Smart Contract Wallets betreiben oft Relayer, um Transaktionen für Nutzer zu subventionieren. Das heißt, der Relayer zahlt ETH aus seiner Wallet, um deine Transaktionsgebühren zu decken, und holt sich die Kosten anderweitig zurück – vielleicht in Fiat oder einem anderen Token.

Dieses System funktioniert in den meisten Fällen gut: Du kannst eine Contract Wallet erstellen und nutzen, ohne dir zu viele Gedanken über die Feinheiten der Gasgebühren zu machen. Es erfordert jedoch auch, dem Relayer zu vertrauen, dass er deine Transaktionen nicht zensiert oder manipuliert.

Aber das ist Krypto, und wir mögen vertrauensfreie Systeme.

Indem Contract Accounts Transaktionen genehmigen und Gasgebühren bezahlen können, macht Account Abstraction den Prozess der Erstellung und Nutzung einer Smart Contract Wallet vertrauensfreier. Konkret ermöglicht es jedem, der einen Relayer betreibt, Transaktionen in deinem Namen auszuführen. Du musst lediglich eine Nachricht signieren, die den Relayer genehmigt, nach der Ausführung der Transaktion Mittel von deinem Wallet-Guthaben abzuziehen:

Jetzt sieht der Ablauf der Nutzung einer Smart Contract Wallet etwas anders aus:

  • Eine Wallet-Contract bereitstellen? Durch die Verwendung von Counterfactual-Deployment-Workflows kannst du Mittel an den Contract Account senden, bevor du ihn bereitstellst, und einen Relayer-EOA für die Bereitstellungskosten aus dem Guthaben deiner Wallet bezahlen.

  • Mit einem Wallet-Contract interagieren? Signiere eine Nachricht off-chain und lass einen Relayer den Aufruf an deinen Account Contract machen. Die Nachricht enthält eine Anweisung für den Account Contract, dem Relayer die Gaskosten zu erstatten.

Diese Idee, vertrauensfreie und zensurresistente Smart Accounts zu ermöglichen, liegt vielen Account-Abstraction-Vorschlägen in dieser Kategorie zugrunde. Zum Beispiel dezentralisiert ERC-4337 – der bisher populärste Account-Abstraction-Vorschlag – Relayer, indem ein alternativer Mempool eingeführt wird, in dem Nutzer Contract-Wallet-Transaktionen zur Verarbeitung einreichen können.

In diesem Fall können Relayer (genannt „Bundler") um die Ausführung von Smart-Account-Transaktionen konkurrieren, was das Risiko von Zensur oder übermäßiger Abhängigkeit von Wallet-Anbietern reduziert. Unten ist eine Infografik, die verschiedene Account-Abstraction-Vorschläge im Lager „Smart Contracts EOA-Funktionen geben" zeigt, einschließlich ihrer wichtigsten Merkmale und des Implementierungsstatus:

Zur Zukunft von Account Abstraction

Jahre nachdem Vitalik Buterin das Konzept erstmals vorstellte, gibt es immer noch Uneinigkeit über den besten Weg zur Implementierung von Account Abstraction. Zum Beispiel würde die Implementierung von EIP-3074 und EIP-5003 bestehenden EOAs (einschließlich MetaMask-Nutzern) ermöglichen, auf Smart Accounts upzugraden. Diese Vorschläge erfordern jedoch einen Hard Fork, der angesichts des Fokus der Community auf dringendere Upgrades derzeit nicht machbar erscheint.

Im Gegensatz dazu hat EIP-4337 breite Unterstützung erhalten, da es Account Abstraction implementiert, ohne umfangreiche Änderungen am Ethereum-Protokoll zu erfordern. Für Nutzer, die derzeit EOA-basierte Wallets verwenden, bedeutet dies jedoch, Assets von einem EOA auf einen neu bereitgestellten Contract Account zu verschieben – ein potenziell komplexer und kostspieliger Prozess angesichts der heute hohen Gasgebühren auf Ethereum.

Bei MetaMask glauben wir, dass Account Abstraction der Schlüssel zu einer reibungslosen Onboarding-Erfahrung für neue Web3-Nutzer ist. Wir wissen auch, dass EOAs die Massenadoption von Krypto nicht garantieren können („Die nächste Milliarde Nutzer wird keine 12 Wörter auf Papier schreiben", wie Ethereum-Foundation-Forscher Yoav Weiss es treffend formuliert.).

Daher haben wir begonnen, über Wege nachzudenken, die Vorteile von Account Abstraction zu liefern, ohne die MetaMask-Wallet zu beeinträchtigen, die Nutzer kennen und lieben. Teil dieser Bemühungen ist der Rückgriff auf MetaMask Snaps – die permissionless Innovationsplattform, die es Entwicklern ermöglicht, benutzerdefinierte Funktionen auf der bestehenden MetaMask-Infrastruktur aufzubauen.

Mit Snaps können Entwickler die Funktionalität deiner MetaMask-Wallet erweitern, um verschiedene Account-Abstraction-Anwendungsfälle zu unterstützen. Von Session Keys bis hin zu vollständigen Smart-Account-Integrationen, die mit MetaMask entwickelt wurden – alles mit Snaps gebaut – haben wir gesehen, wie Entwickler die Herausforderung angenommen haben, MetaMask zu nutzen, um den Zugang zu Account Abstraction für Nutzer zu demokratisieren.

„Das Bessere ist der Feind des Guten." — Voltaire

Der aktuelle Account-Abstraction-Vorschlag – auch wenn er leicht unvollkommen ist – ist ein riesiger Schritt in Richtung vertrauensfreier, zensurresistenter Smart Accounts auf Ethereum und verdient ausreichend Unterstützung. Um eine unserer eigenen zu zitieren, Taylor Monahan: „Eine ausgelieferte halbe Lösung ist immer noch besser als eine nicht ausgelieferte perfekte Lösung."

Deshalb wird unser nächster Artikel zum Thema Account Abstraction die Form eines tiefen Eintauchens in die Details von ERC-4337 annehmen. Wichtig ist, dass wir besprechen werden, wie Web3-Entwickler die Zukunft von Account Abstraction aufbauen und die nächste Milliarde Nutzer onboarden können – eine Codezeile nach der anderen – mit MetaMask.

Bleib dran!

Besonderer Dank gilt Patrick McCorry, Simon Brown, Mirko Garozzo, Christian Montoya, Oliver Renwick und Megan Dias für ihr Feedback zu früheren Entwürfen dieses Artikels. Mein Dank gilt auch Clarissa Watson und Francesco Andreoli, die in den frühen Phasen des Projekts Orientierung und Unterstützung geleistet haben.

KI-übersetzt. Kann Fehler enthalten. Bitte überprüfen Sie die Informationen stets.

Bewerten Sie die Übersetzung

Dieser Artikel wurde verfasst von: