Ursprünglicher Autor: Yuxing, SevenX Ventures
Originalquelle: Foresight News
Zusammenfassung:
Das zukünftige Wallet-Modell dürfte eher einem B2B2C-Modell ähneln. Während das Wallet als C-End-Produkt existiert, ist es wichtiger, eine ausgereifte SDK-Lösung für andere Anwendungen bereitzustellen, die in In-App-Wallets integriert und dann auf C-End-Benutzer ausgerichtet werden. Unter ihnen wurden Packer und Aggregatoren in der Anfangszeit hauptsächlich zentralisiert aufgebaut. Da dieser Teil jedoch den Kern der Werterfassung darstellt, müssen Wallets, die von anderen erstellt wurden, aufgegeben werden durch das Spiel der wirtschaftlichen Vorteile.
Mit der kontinuierlichen Erweiterung und Erweiterung der Ethereum-Anwendungsszenarien werden nach und nach die Nachteile der Externally Owned Accounts (EOA)-Lösung der traditionellen Ethereum-Wallet deutlich. Ihre Funktionen sind einfach und ihre Leistung ist durchschnittlich. Sie unterstützt keine gleichzeitigen Transaktionen und weist wichtige Verwaltungsprobleme auf . Problem. Smart Contract Wallets nutzen Vertragskonten (CA) als Wallet-Adressen. Es handelt sich um eine relativ neue Ethereum-Wallet-Lösung, die die Mängel von EOA-Wallets beheben und leistungsfähigere Funktionen bieten kann. In Zukunft können Sie sich dafür entscheiden, Ihre privaten Schlüssel nicht sorgfältig zu schützen und fast das gleiche Maß an Sicherheit zu genießen. Sie können auch den Komfort aktueller zentralisierter Börsen in dezentralen Börsen genießen, aber gleichzeitig sind die Mittel immer vorhanden in Ihren eigenen Händen, sodass Sie sich keine Sorgen über mögliche Gewitter an der Börse machen müssen ...
In der vor einiger Zeit veröffentlichten neuen Version der Ethereum-Roadmap wurde die Kontoabstraktions-Smart-Contract-Spezifikation ERC-4337 als Schlüsselelement für die Umstellung von EOA-Wallets auf Smart-Contract-Wallets in The Splurge geschrieben. Was genau ist also ein Smart Contract Wallet und welche Beziehung besteht zwischen Kontoabstraktion und Smart Contract Wallets, wie werden sie implementiert, wie sieht ihre zukünftige Entwicklungsform aus und was sind die Chancen und Herausforderungen?
Arten von Ethereum-Konten
Ethereum verfügt über zwei Arten von Konten: Externally Owned Accounts (EOA) und Contract Accounts (CA). Das externe Konto ist die Wallet-Kontoadresse, die von Ethereum verwendet wird, um Benutzersalden nativ aufzuzeichnen. Das Vertragskonto war ursprünglich nicht für die Aufzeichnung von Benutzer-Wallet-Adresssalden konzipiert.
externes Konto
EOA ist ein einzigartiges Konzept für Ethereum und andere EVM-kompatible Ketten (oder EVM-ähnliche Ketten). Streng genommen verfügen Mainstream-Nicht-EVM-Ketten, einschließlich BTC, nicht über diese Einstellung. Metamask Wallet verwendet externe Konten. Diese Art von Wallet wird auch „EOA Wallet“ genannt und wird durch den privaten Schlüssel des Benutzers gesteuert.
Privater Schlüssel → Öffentlicher Schlüssel → Keccak256-Hash → Letzte 20 Bytes → Hex-String (EOA-Adresse)
Diese Generierungsregel ist vollständig aus der mathematischen Transformation abgeleitet und diese Adresse entspricht keinem Smart Contract. Bei Verwendung dieses Adresstyps für Transaktionen gelten folgende Regeln zur Knotenüberprüfung:
Transaktionssignatur → ec_recover → Öffentlicher Schlüssel → (mit den oben genannten Regeln generiert) Adresse → Vergleichen Sie die zu bedienende Adresse
Wenn die Verifizierung erfolgreich ist, fahren Sie mit dem Folgeprozess fort, andernfalls wird die Transaktion abgelehnt. Die Kerneinstellung von EOA in Ethereum besteht darin, als Initiator der Transaktion zu fungieren und Gas zu zahlen, d Es muss ausreichend Benzin bezahlt werden. Der Transaktionsprozess einer EOA-Adresse ist in der folgenden Abbildung dargestellt.
Vereinfachter EOA-Transaktionsmechanismus Quelle: Nethermind
Probleme mit externen Konten
Derzeit sind EOA-Konten der absolut gängige Wallet-Typ, der von Benutzern verwendet wird. Die Ethereum-Community hat einige Bedenken hinsichtlich EOA geäußert, darunter:
Schlüsselverwaltung: Die einzige Möglichkeit, Geld zu erhalten, besteht darin, den privaten Schlüssel zu kennen. Das größte Problem ist der Single Point of Failure. Für Benutzer ist der private Schlüssel der Vermögenswert. Für Benutzer bedeutet der Verlust oder Diebstahl des privaten Schlüssels einen Verlust von Vermögenswerten.
Verlassen Sie sich auf ECDSA-Signaturen: Einfachere und quantenresistente Signaturen für Steuerbeträge sind eine deutliche Verbesserung gegenüber dem aktuellen ECDSA.
Transaktionen sind eins zu eins mit Vorgängen: Wenn nicht mehrere Vorgänge gleichzeitig ausgeführt werden können, entstehen unnötige Kosten und eine schlechte Benutzererfahrung.
Mit der kontinuierlichen Erweiterung der Blockchain-Anwendungsszenarien verwalten Benutzer nicht nur ihre eigenen On-Chain-Assets auf der Blockchain, sondern auch On-Chain-Identitäten, soziale Beziehungen und sogar On-Chain-Credits usw. Derzeit werden die meisten dieser Inhalte einfach über Wallets pseudo-anonymen Personen zugeordnet. Nicht nur haben Benutzer Probleme mit der mnemonikbasierten EOA-Wallet-Lösung zur Verwaltung privater Schlüssel, sondern auch die Anwendungen sind aufgrund der Einfachheit von EOA-Wallets in vielen Anwendungen vorhanden. Die Szene ist eingeschränkt.
Es gibt viele Wallet-Lösungen, die versuchen, diese Probleme zu lösen:
Um Single Points of Failure herum bieten MPC-Wallets mithilfe des Threshold Signature Scheme (TSS) eine bessere Lösung für die Verwaltung privater Schlüssel, während Smart Contract Wallets dieses Problem durch Social Recovery, Multi-Signatur und andere Lösungen lösen können.
Eine bessere Benutzererfahrung, leistungsfähigere Funktionen und Skalierbarkeit, wie z. B. Batch-Transaktionen, benutzerdefinierte Verifizierungslogik usw., werden hauptsächlich durch Smart Contract Wallets erreicht.
MPC-Wallets und Smart-Contract-Wallets sind keine völlig unabhängigen Lösungen. Auch Smart-Contract-Wallets können die MPC+TSS-Technologie zur Verwaltung von Smart-Contract-Wallets nutzen.
Hinweis: MPC-Wallet bezieht sich auf eine Wallet, die sichere Mehrparteien-Computing-Technologie verwendet. Dies entspricht der Einstellung von M-Verwaltern für Ihren Vermögenstresor. Jeder Verwalter kann den Tresor nicht unabhängig öffnen, und die Verwendung des Threshold Signature Scheme (TSS) entspricht einer Spende Ihr Tresor ist mit einem Schloss ausgestattet, für dessen Öffnung N Schlüssel erforderlich sind. Dann entspricht die MPC + TSS-Wallet-Lösung der Bereitstellung einer Tresorverwaltungslösung mit mehreren Rollen, bei der M-Verwalter gleichzeitig die von ihnen verwalteten Schlüssel bereitstellen müssen Zeit. Möglichkeit, Tresore zu öffnen.
Vertragskonto
CA ist ein Ethereum-Konto mit interner Logik, die entweder Geschäftslogik (Token-Vertrag wird für die Buchhaltung verwendet, Pfandvertrag wird für Kreditvergabe und Liquidation verwendet) oder Kontologik (wie die Multisignaturlogik von Gnosis Safe) und Letzteres sein kann Es handelt sich um das Smart Contract Wallet/Account (SCW). Das Argent-Wallet verwendet ein Smart-Contract-Wallet, das den Weg für das Social-Recovery-Modell ebnete. Der Vertrag wird durch internen Logikcode gesteuert und seine Generierungsregeln umfassen CREATE und CREATE2, die hier nicht besprochen werden.
Im Gegensatz zu EOA gibt es keine notwendige Korrespondenz zwischen CA und öffentlichem Schlüssel. Beispielsweise kann die von Gnosis Safe erstellte Zertifizierungsstelle eine beliebige Anzahl öffentlicher Schlüssel festlegen, um die ihrer Adresse entsprechenden Assets zu entsperren. Natürlich kann die Zertifizierungsstelle auch keine Schlüssel festlegen, aber die Logik anderer Zertifizierungsstellen bestimmt, ob sie entsperrt werden kann. Wie zum Beispiel DeFi können Sie mit einem Kreditvertrag die verpfändeten Vermögenswerte zurückerhalten, solange Sie das Geld zurückzahlen.
Alle Vermögenswerte auf Ethereum mit Ausnahme der ETH werden von CA verwaltet und Geschäftslogiken wie DeFi werden vollständig von CA implementiert. Allerdings schränkt die Tatsache, dass CA nicht aktiv Gas betreiben und bezahlen kann, seine Möglichkeiten ein. Bereits 2016 gab es einen Vorschlag, CA die Möglichkeit zu geben, Gas selbst zu bezahlen.
Quelle der Smart-Contract-Wallet-Transaktion: Nethermind
Da Transaktionen nur von EOA aus gestartet werden können, stellen Smart Contract Wallets zur Verbesserung der Benutzererfahrung normalerweise Relay-Dienste bereit, um signierte Nachrichten von Benutzern zu erhalten und die EOA vom Dienstanbieter an die Kette zu übermitteln. Ihr benutzerdefinierter Gebührenmechanismus kann die ETH an den Benutzer zurückgeben EOA-Wallet erhebt keine Benzingebühr.
Derzeit gibt es keinen Betriebsstandard für Smart Contract Wallets (EIP-4337 wird voraussichtlich zum Standard), daher muss jedes Projekt eine Meta-Transaktionslösung wie das Ethereum Gas Station Network (GSN) verwenden oder darauf hinarbeiten, eine solche zu erstellen und zu verwalten besitzen Relay-Dienste, verwalten Gebührenmechanismen und prüfen ihre komplexen Smart Contracts.
Smart-Contract-Wallet
Wie der Name schon sagt, handelt es sich bei Smart Contract Wallet/Account (SCW) um eine Wallet-Lösung, die CA als Adresse verwendet. Sie zeichnet sich durch interne Logik aus und kann viele Funktionen implementieren, die EOA nicht erfüllen kann, wie z. B. Gaszahlung und Batch-Transaktionen , mehrere Signaturen, Rechteverwaltung, Offline-Autorisierung, soziale Wiederherstellung und mehr.
Ein Vertragskonto ist ein intelligenter Vertrag, der vom Unterzeichner (Autorisierer) getrennt ist und über eine eigene Signatur- und Wiederherstellungslogik verfügen kann. Das heißt, wenn Sie den Zugriff auf Signer verlieren, bedeutet das nicht unbedingt, dass Sie auch den Zugriff auf Ihr Konto verlieren. Auch hier kommt der Name Account Abstraction her. Konten werden von den Unterzeichnern getrennt.
Kontoabstraktion
Der aktuelle Status von Ethereum ist, dass die überwiegende Mehrheit der Menschen EOA-Wallets verwendet, da derzeit alle Transaktionen in Ethereum mit EOA beginnen müssen und EOA über etwas ETH verfügen muss, um für Gas zu bezahlen, was es neuen Benutzern unmöglich macht, schnell einzusteigen. Wir benötigen eine Lösung, die es Benutzern ermöglicht, intelligente Vertrags-Wallets zu verwenden, die eine beliebige Verifizierungslogik enthalten. Diese Lösung heißt Account Abstract (AA). Vereinfacht ausgedrückt ist das Ergebnis der Kontoabstraktion:
In der Vergangenheit haben Sie Geld in der Ethereum-EOA-Wallet-Adresse gespeichert, obwohl Sie verschiedenen EOA-Adressbeschränkungen unterlagen, aber Sie haben auch die Einfachheit und Bequemlichkeit genossen, Vermögenswerte mit dem privaten Schlüssel zu besitzen;
Da Sie nun Geld auf einer Ethereum-Smart-Contract-Adresse speichern, können Sie Ihr Wallet-Vermögen kontrollieren, indem Sie keine privaten Schlüssel verwalten. Durch die Trennung des Unterzeichners und des Kontos selbst können Sie Transaktionsvorgänge auf einem niedrigeren Sicherheitsniveau durchführen auf einem höheren Sicherheitsniveau.
Das Ziel der „Kontoabstraktion“ besteht darin, die Anzahl der Kontotypen von 2 (EOA und Vertrag) auf 1 (nur Vertrag) zu reduzieren und Funktionen wie Signaturüberprüfung, Gaszahlung und Replay-Angriffsschutz vom Kernprotokoll auf das zu verlagern EVM. Die Implementierung der Kontoabstraktion war schon immer das Bestreben vieler Ethereum-Entwickler, wie aus der Geschichte von EIP hervorgeht.
EIP-Geschichte
Das Konzept der Kontoabstraktion wurde erstmals 2016 von Vitalik vorgeschlagen und er initiierte den ersten Vorschlag im Jahr 2017. Im Laufe der Jahre gab es viele Vorschläge zur Kontoabstraktion, die wichtigsten davon sind EIP-3074 und EIP-4337. EIP-3074 wurde ein Jahr früher als EIP-4337 vorgeschlagen, EIP-4337 wurde jedoch in die neue Version der Ethereum-Roadmap aufgenommen. Der Hauptgrund besteht darin, dass die Implementierung von EIP-4337 einfacher sein muss und keine Änderungen erforderlich sind der Kern des Ethereum-Protokolls, und es gibt keine Sicherheitsrisiken wie EIP-3074. Die Benutzermigrationsprobleme, übermäßige Gasprobleme und potenzielle Smart-Contract-Sicherheitsprobleme in EIP-4337 sind häufige Probleme für Smart-Contract-Wallets. Vitalik ist davon überzeugt, dass der beste realistische Weg zur Kontoabstraktion darin besteht, kurzfristig mit der energischen Unterstützung von ERC-4337 zu beginnen. und dann wurde das EIP im Laufe der Zeit hinzugefügt, um seine Schwächen auszugleichen.
Kontozusammenfassung EIP-Verlauf
EIP-86: Im Jahr 2017 schlug Vitalik EIP-86 vor und versuchte damit, eine Smart-Contract-Wallet einzuführen, die als „Weiterleitungsvertrag“ betrachtet werden kann. Diese Weiterleitungsverträge akzeptieren nur Transaktionen von der „Einstiegspunkt“-Adresse, von der aus jeder Transaktionen senden kann, solange sie einem bestimmten Format folgen.
EIP-1014: Diese Weiterleitungsverträge würden basierend auf ihrem Code an eine bestimmte Adresse bereitgestellt. Dies führte zu einer Idee, die sich später zu EIP-1014 entwickelte und den CREATE2-Opcode vorschlug. Da EIP-86 erhebliche Änderungen am Protokoll erforderte, wurde es letztendlich nicht zusammengeführt, während EIP-1014 im Jahr 2018 zusammengeführt wurde.
EIP-2938: Im September 2020 schlugen Vitalik Buterin, Ansgar Dietrichs und Matt Garnett EIP-2938 vor, das vorschreibt, dass spezielle Smart Contracts, die als Smart Contract Wallets identifiziert werden, nur abstrakte Kontotransaktionen akzeptieren. Diese neue Art von Transaktion wird von EIP-2938 unterstützt. 2718 eingeführt. Sie werden programmgesteuert das maximale Gas für Transaktionen festlegen und willkürliche Verifizierungsmethoden implementieren. EIP-2938 Zwei neue Opcodes müssen zum EVM hinzugefügt werden, um Transaktionen möglich zu machen. Diese Opcodes verändern das Kernprotokoll erheblich und der Prozess der Einarbeitung solcher Änderungen kann langwierig sein.
EIP-3074: Im Oktober 2020 schlugen Ansgar Dietrichs, Matt Garnett und andere EIP-3074 vor, das zwei neue Opcodes einführte: AUTH und AUTHCALL. Wenn sie zusammen verwendet werden, ermöglichen sie Smart Contracts, Transaktionen im Namen von EOA zu senden, was beispielsweise Mehrfachsignaturen, gestapelte und gesponserte Transaktionen, Schlüsselwiederherstellung und leichter zugängliche CeFi-Börseneinlagen ermöglicht. Dieses EIP birgt jedoch einige Sicherheitsrisiken und wird kritisiert. Der neue Opcode würde auch das Kernprotokoll ändern. Die Forscher begannen, über eine bessere Lösung nachzudenken, die schließlich als EIP-4337 vorgeschlagen wurde.
Quelle des EIP-3074-Transaktionsprozesses: Nethermind
Layer2: Da L2 nicht über die technischen Schulden von Ethereum L1 verfügt, kann die Kontoabstraktion sofort eingeführt werden. Sowohl Optimism als auch Starknet verfügen über ihre eigenen Kontoabstraktionsimplementierungen auf Starknet, die von EIP-4337 inspiriert sind Eine benutzerdefinierte Kontoabstraktionsimplementierung. Ein aktuelles Beispiel ist Visa Crypto Auto Payments auf StarkNet. Die automatisierte Zahlungslösung Ethereum nutzt das Kontoabstraktionskonzept und erstellt eine neue Art von Kontovertrag – ein delegiertes Konto. Die Hauptidee besteht darin, die programmierbaren Gültigkeitsregeln von Transaktionen auf Includes zu erweitern vorab genehmigte Zulassungslisten. Einfach ausgedrückt kann die Kontoabstraktion automatisierte Zahlungsvorgänge, die von Benutzerkonten initiiert werden, an vorab genehmigte intelligente Verträge für automatisierte Zahlungen delegieren. Das Kontomodell von StarkNet ist das, was Visa derzeit als Kontoabstraktion bezeichnet. Seine Implementierung ist von ERC-4337 inspiriert und das abstrakte Konto prüft, ob die Transaktion von einer bestimmten Adresse stammt.
Visa implementiert die Kontoabstraktion auf StarkNet
EIP-4337: Im September 2021 haben Vitalik Buterin und Ethereum-Forscher von OpenGSN und Nethermind aus den Lehren früherer Bemühungen gezogen und EIP-4337 vorgeschlagen. EIP-4337 fügt einen neuen UserOperation-Mempool hinzu, in der Hoffnung, den aktuellen Transaktions-Mempool vollständig zu ersetzen und so eine Kontoabstraktion zu ermöglichen. Benutzer senden UserOperation-Objekte an Ethereum-Knoten und packen anstelle von Transaktionen einen Satz dieser Objekte in eine Transaktion, die in der Ethereum-Kette enthalten ist. Diese verpackte Transaktion wird als „Einstiegspunkt“-Smart-Vertrag bezeichnet, der das UserOperation-Objekt verarbeitet und die Smart-Contract-Wallet dafür bereitstellt.
Quelle des ERC-4337-Transaktionsprozesses: Nethermind
EIP-5003: Im März 2022 schlugen Dan Finlay und Sam Wilson EIP-5003 vor, um die Migration von ECDSA durch die Bereitstellung von Code anstelle externer Konten zu ermöglichen. Diese EIP führt einen neuen Opcode ein, der Code an der EIP-3074-Autorisierungsadresse AUTHUSURP bereitstellt. Für Externally Owned Accounts (EOA) werden dadurch zusammen mit EIP-3607 effektiv die Berechtigungen des ursprünglichen Signaturschlüssels widerrufen. Dies gilt zusätzlich zu EIP-3074, das nur zusätzliche Teilnehmerberechtigungen erteilen, diese jedoch nicht widerrufen kann.
EIP-5792: Im Oktober 2022 schlug Moody Salem EIP-5792 vor, das eine JSON-RPC-Methode zum Senden mehrerer Funktionsaufrufe aus der Benutzer-Wallet und zur Überprüfung ihres Status hinzufügt. Der neue Ansatz ist in Bezug auf die zugrunde liegenden Transaktionen abstrakter als die bestehende API zum Senden von Transaktionen, um Unterschiede zwischen Wallet-Implementierungen zu berücksichtigen, wie z. B. Smart-Contract-Wallets mit EIP-4337 oder EOA-Wallets, die gebündelte Transaktionen über EIP-3074 unterstützen. Dapps können diese abstraktere Schnittstelle verwenden, um verschiedene Arten von Wallets ohne zusätzlichen Aufwand zu unterstützen und eine bessere Benutzererfahrung beim Senden von Funktionsaufrufpaketen zu bieten (z. B. EIP-20#approvegefolgt von einem Vertragsaufruf).
EIP-4337 ausführliche Erklärung
In EIP-4337 gibt es insgesamt 6 Komponenten: EntryPoint-Vertrag, Paymaster-Vertrag, UserOperation, Bundler, Sender-Vertrag und Aggregator (Aggregator).
EntryPoint: Der Entry-Point-Vertrag übernimmt die Ausführung und Überprüfung der an ihn übergebenen Transaktionsvorgänge. Der globale Einstiegspunktvertrag empfängt gepackte Transaktionen von verschiedenen Bundlern und führt Validierungs- und Ausführungsschleifen durch alle UserOperations aus.
Paymaster: Dies ist ein optionaler Vertrag, der im Namen des Benutzers Benzin für Transaktionen bezahlen kann. Anstatt sich auf ihr Portemonnaie zu verlassen, erhalten Benutzer vom Kassierer gesponserte Transaktionsgebühren.
UserOperations: Hierbei handelt es sich um Transaktionsobjekte, die erstellt werden, um Transaktionen im Namen von Benutzern durchzuführen. Die Ausführung erfolgt nach Bestätigung des Absendervertrags. Diese Aktionen werden von Dapps generiert.
Bundler: Bundler ruft UserOperations aus dem Speicherpool ab und bündelt sie, um sie zur Ausführung an den EntryPoint-Vertrag zu senden.
Absendervertrag: Hierbei handelt es sich um Benutzer-Wallet-Konten in Form von Smart Contracts.
Aggregator: Der Aggregator ist ein Hilfsvertrag, dem das Wallet vertraut und der zur Überprüfung aggregierter Signaturen verwendet wird.
Die laufende Logik des gesamten ERC-4337-Standards besteht aus zwei Schleifen: der Verifizierungsschleife und der Ausführungsschleife, die kombiniert werden, um die Logik der Kontoabstraktion zu vervollständigen.
Validierungsschleife: Der Einstiegspunktvertrag durchläuft jede UserOperation und ruft die „Prüffunktion“ im Sendervertrag auf. Der Absendervertrag führt diese Funktion aus, um die Signatur der UserOperation zu überprüfen und den Bunder zu entschädigen, der diese Transaktionen verpackt hat.
Ausführungsschleife: Senden Sie die Anrufdaten in jeder UserOperation an den Sendervertrag. Das Wallet führt den Ausführungsvorgang aus, um die in dem Vorgang angegebenen Transaktionen auszuführen. Der Sender-Vertrag gibt dann das verbleibende Gas zurück, nachdem die Operation ausgeführt wurde.
Validierungsschleife und Ausführungsschleife Quelle: EIP-4337
Die eingeführte Teller-Rolle ermöglicht es App-Entwicklern, die Gebühren für ihre Nutzer zu subventionieren. Wenn paymaster nicht mit der Nulladresse übereinstimmt, führt der Einstiegspunkt einen anderen Prozess aus:
Einführung der Validierungsschleife und Ausführungsschleife für Kassierer Quelle: EIP-4337
Im Verifizierungszyklus muss der Einstiegspunktvertrag zusätzlich zum Aufruf der „Prüffunktion“ auch prüfen, ob der Zahlmeister verpfändet ist und im Einstiegspunktvertrag genügend ETH gespeichert ist, um die Betriebsgebühr zu bezahlen, und dann den „Scheck“ aufrufen Funktion“ auf dem Zahlmeister, um zu prüfen, ob der Zahlmeister zahlungsbereit ist.
In der Ausführungsschleife muss der Einstiegspunktvertrag nach dem Hauptausführungsaufruf den Post-Op auf Paymaster aufrufen. Es muss die Ausführung des Post-Op-Vorgangs gewährleisten, indem es die Hauptausführung in der inneren Aufrufumgebung durchführt. Wenn die innere Aufrufumgebung zurückgesetzt wird, versuchen Sie, den Post-Op erneut in der äußeren Aufrufumgebung aufzurufen (auch wenn dies der Fall ist, sollte Gas bezahlt werden). der Benutzervorgang führt zu einem Rollback der Kosten).
Vitalik kam zu dem Schluss, dass ERC-4337 als rein freiwilliger ERC viel bewirken kann. Allerdings ist es in einigen Schlüsselbereichen schwächer als eine echte protokollinterne Lösung:
Problem bei der Benutzermigration: Bestehende Benutzer können kein Upgrade durchführen, ohne alle ihre Vermögenswerte und Aktivitäten auf neue Konten zu verschieben.
Zusätzlicher Gas-Overhead (~42.000 für eine einfache UserOperation und ~21.000 für eine einfache Transaktion);
Sicherheitsprobleme bei intelligenten Verträgen, die weniger von protokollinternen zensurresistenten Techniken (wie crLists) profitieren, die auf Transaktionen abzielen und Benutzeroperationen ignorieren
Ein realistischer Weg, um optimale Ergebnisse zu erzielen, besteht darin, ERC-4337 kurzfristig stark zu unterstützen und dann im Laufe der Zeit EIPs hinzuzufügen, um seine Schwächen zu beheben. Dies erfordert nicht unbedingt eine besondere Verpflichtung zur Einhaltung von ERC-4337. Stattdessen könnte die protokollinterne Unterstützung allgemeiner gestaltet werden und ERC-4337 sowie seine Alternativen und Verbesserungen unterstützen. Zu den aktuellen ERC-4337-Implementierungslösungen gehören Biconomy, Soul Wallet und eth-infinitiism. Sie haben alle ihre eigenen Einstiegspunktvertrags-Implementierungslösungen geschrieben, und der Einstiegspunktvertrag ist der Kern der intelligenten Vertragssicherheit gemäß diesem Standard.
Vitalik schlug eine mögliche Roadmap für die Kontoabstraktion vor.
Mögliche Roadmap
kurzfristig
ERC-4337 wird in volle Produktion gebracht. Idealerweise könnte dies mithilfe von Signaturaggregationsfunktionen erweitert werden, um Rollup-Freundlichkeit zu erreichen.
Es sollte benutzerfreundliche Browser-Wallets geben, die mit ERC-4337 verbunden sind.
Erwägen Sie die Implementierung von Signaturaggregation und -komprimierung, um ERC-4337 L2-freundlicher zu machen.
Führen Sie das ERC-4337-Ökosystem im L2-Protokoll, wo die Probleme mit den Gaskosten geringer sind.
mittelfristig
Implementieren Sie den Verkle-Baum und fügen Sie EIP hinzu, um die Gaskosten zu senken.
Fügen Sie optionale EOA-zu-ERC-4337-Konvertierung hinzu;
Fügen Sie crList-Logik gleichzeitig oder kurz nach dem Start von Proposer/Builder Separation (PBS) hinzu;
lang
Erwägen Sie das Erzwingen von Übergängen, die Durchführung unregelmäßiger Zustandsübergänge und die Bereitstellung von Bytecode für jedes Konto, bei dem es sich möglicherweise um EOA handelt. Die Nachteile dieses Ansatzes bestehen jedoch in der Notwendigkeit, das Kernprotokoll zu ändern, und in den hohen Kosten für Miner/Validatoren.
Projektscan
SevenX hat einfach die Smart Contract Wallets auf dem Markt gescannt und einige der gängigsten Smart Contract Wallet-Projekte auf dem Markt zusammengestellt. Die Gesamtsituation ist wie folgt:
Wir haben zwei Projekte zur Falleinführung ausgewählt und ihre Funktionen und entsprechenden Implementierungsprinzipien analysiert. Unter ihnen ist Unipass ein typischer Vertreter traditioneller Smart-Contract-Wallets, während Candide Wallet ein typischer Vertreter von Wallets ist, die den ERC-4337-Standard verwenden. Sie verfügen über umfangreiche öffentliche Dokumente, die die Implementierung ihrer Produktfunktionen detailliert erläutern.
Implementierungsfall – Unipass
UniPass Wallet ist eine intelligente Vertrags-Wallet-Lösung, die die Wiederherstellung von E-Mails in sozialen Netzwerken unterstützt. Durch UniPass Wallet können Entwickler ein reibungsloses Benutzererlebnis ohne private Schlüssel und Gase innerhalb des Produkts bereitstellen und so schnell eine große Anzahl von Web2-Benutzern anziehen. Zu seinen Merkmalen gehören: Private-Key-frei, zensurresistent, gasfrei, E-Mail-Wiederherstellung, Schutz der Privatsphäre, Unterstützung für mehrere Plattformen und mehrere Ketten.
Die Funktionen der privaten Schlüsselfreiheit, der Zensurresistenz, der E-Mail-Wiederherstellung und des Datenschutzes werden hauptsächlich durch die Schlüsselverwaltungslösung von Unipass bereitgestellt. Das Vertragskonto von UniPass Wallet unterstützt Benutzer beim Festlegen mehrerer Schlüsseltypen. Zu den bereits unterstützten Schlüsseltypen gehören:
Wir verwenden häufig externe Adressen für Vertragskonten, die das EIP-1271-Protokoll (eine Standardmethode zur Signaturüberprüfung für Verträge) unterstützen.
UniPass-Benutzer können auch ihre E-Mail-Adresse als Schlüssel verwenden. Die intelligenten Verträge, die wir in der Kette einsetzen, können den Besitz des Benutzers an einem Internet-Postfach über DKIM (Domain Name Key Identified Mail) kryptografisch überprüfen. Während des Verifizierungsprozesses verwendet UniPass eine wissensfreie Proof-Technologie, um den Datenschutz und die Sicherheit der E-Mail-Informationen der Benutzer zu gewährleisten.
In Zukunft wird UniPass Wallet auch die Unterstützung effizienterer und einfacherer Signaturalgorithmen als secp256k1 (wie Schnorr, BLS), sicherer Post-Quantum-Signaturalgorithmen (wie Lamport, Winternitz) usw. in Betracht ziehen.
Geheime Schlüssel haben drei Hauptaufgaben:
Eigentümer ist der Eigentümer des Kontos. Der Eigentümer kontrolliert die Bereitstellung, Aktualisierung, Zerstörung und andere Kernfunktionen des Kontos und ist die höchste Kontrollinstanz für das Konto.
Der Betreiber ist der Vollstrecker des Kontovermögens. Der Betreiber ist für die Vermögensübertragung, Vertragsabwicklung, Autorisierung und andere Funktionen des Kontos verantwortlich und stellt den Schlüssel dar, den die Benutzer täglich verwenden.
Guardian ist der Hüter des Kontos. Wenn der Schlüssel im Konto beschädigt ist oder verloren geht und der Benutzer die Kontrolle über das Konto verliert, kann der Vormund zur Wiederherstellung des Kontos eingesetzt werden. Eine wichtige Funktion von UniPass ist die soziale Wiederherstellung von E-Mails in der Kette.
Im Smart Contract von UniPass Wallet verwalten Benutzer ihre Konten über eine Reihe von Schlüsseln mit Rollengewichtungen. Zusätzlich zu dem im MPC-Schema (Secure Multi-Party Computation) implementierten Hauptschlüssel können Benutzer auch viele andere Schlüsseltypen festlegen. Jeder Schlüssel hat eine entsprechende Rolle und ein entsprechendes Gewicht. Ein Benutzer kann die Autorisierung für diese Rolle nur erhalten, nachdem er Schlüssel gesammelt hat, deren Gesamtgewichtungsschwellenwert die Anforderungen überschreitet.
Einem Schlüssel können eine oder mehrere Rollen zugewiesen werden. Wenn einem Schlüssel eine Rolle zugewiesen wird, wird gleichzeitig das entsprechende Gewicht festgelegt. Wenn ein Benutzer Vorgänge im Zusammenhang mit einer bestimmten Identität ausführen möchte, muss er mit einem oder mehreren Schlüsseln mit einem Gesamtgewicht von 100 oder mehr für die Rolle signieren. Beispielsweise können Benutzer bei der erstmaligen Registrierung eines Kontos die Einrichtung eines Vormunds überspringen. Relevante Parameter können wie folgt eingestellt werden:
Die gasfreie Funktion wird über einen Relayer eines Drittanbieters implementiert. Wenn ein Benutzer eine Transaktion initiiert, wird der Relayer benötigt, um dem Benutzer bei der Initiierung der Transaktion zu helfen. In diesem Prozess kann Relayer Benutzer dabei unterstützen, jeden beliebigen Token zum Bezahlen von Benzin zu verwenden, und kann Benutzern sogar dabei helfen, in ihrem Namen Benzin zu bezahlen, um so ein gasfreies Erlebnis zu erreichen. Relayer ist ein Open-Source-Serverprogramm, das den Standard-Relayer ausführt, und auch Partner oder Dritte können Relayer ausführen.
Implementierungsfall – Candide
CANDIDE ist ein öffentliches Produkt, das gemeinsam und offen von einer Gruppe von Mitwirkenden entwickelt wurde, ohne dass eine einzelne Instanz oder Firma seine Entwicklung kontrolliert. Candide Wallet Beta ist eine selbst gehostete mobile Smart-Contract-Wallet. Es wird derzeit im Goerli-Testnetz bereitgestellt. Es ist jetzt auf Android Test und IOS Testflight verfügbar.
Die technische Basis von Candide Beta ist die ERC-4337-Implementierung des Stackup-Forks und das Open-Source-Framework von Gnosis Safe. Zu seinen Funktionen gehören keine Speicherwörter, soziale Wiederherstellung, Batch-Transaktionen, keine Gasgebühren usw.
Darunter ist die Implementierungslogik von Funktionen wie No-Note-Wörtern, Batch-Transaktionen und keiner Gasgebühr dieselbe wie die von ERC-4337 und wird mithilfe des von eth-infinitism entwickelten Einstiegspunktvertrags vervollständigt. Candide betreibt einen eigenen Packager, um UserOperation als Dienst für sein eigenes Wallet zu packen. Bei dieser Lösung liegt der größte Teil der Sicherheit im Einstiegspunktvertrag und nicht in der Konstruktion des Wallets selbst.
Darüber hinaus ist die Social-Recovery-Funktion darauf zurückzuführen, dass Candide Safe für seinen Basis-Wallet-Vertrag verwendet. Dadurch kann Candide die vertrauenswürdigsten DAO-Verträge nutzen, um digitale Token zu verwalten. Candide wird das modulare Design von Gnosis Safe nutzen, um seine Kernfunktionen, einschließlich Social Recovery, sowie zukünftige Funktionen wie Zeitsperren und Auszahlungslimits bereitzustellen. Dieses Social-Recovery-Modul hat die gleiche Logik wie Unipass, außer dass es bei Unipass hauptsächlich um die E-Mail-Recovery geht, der Hüter von Candide jedoch jeder Unterzeichner mit einer öffentlichen Adresse sein kann, wie z. B. Familienfreunde, Institutionen und Hardware-Wallets.
Gedanken zu Vertragsgeldbörsen
Frühe Smart-Contract-Wallets wurden auf der Grundlage sehr spezifischer Probleme entwickelt, wie beispielsweise der Multisignatur von Gnosis Safe und der Social-Recovery-Funktion von Argent. Diese frühen Produkte waren komplex im Design, oft nicht offen und transparent und bildeten keine einheitlichen Standards, was es schwierig machte, sie als Middleware in andere Anwendungen einzufügen. Bei dieser Art von Produkt müssen die Beurteilungskriterien stärker auf dem Nutzungsszenario basieren und darauf, ob es die Kernbedürfnisse der Benutzer erfasst. Beispielsweise erfasst die Multisignaturfunktion von Safe einen der Kernbedürfnisse der Benutzer.
Mit der Geburt von ERC-4337 ist es sehr praktisch geworden, schnell ein Wallet ohne Worte, Batch-Transaktionen und ohne Gasgebühren zu erstellen. Der einheitliche Standard macht auch das auf diesem Standard basierende Entwicklungskit zusammensetzbar und kann als Zwischenprodukt dienen Software lässt sich in verschiedene Anwendungen integrieren und bleibt interoperabel.
Daher ist es bei der Betrachtung früher Smart-Wallet-Lösungen sehr wichtig, ERC-4337-kompatibel zu sein. Da es sich bei Lösungen auf ERC-4337-Basis größtenteils um Open-Source-Technologien handelt, empfiehlt es sich, sich bei den Überlegungen auf folgende Punkte zu konzentrieren:
Technologie: Wie man Einstiegspunktverträge, Packer und Aggregatoren (falls vorhanden) erstellt und wie man Funktionen erstellt, die über die von ERC-4337 bereitgestellten Funktionen hinausgehen, z. B. Funktionen zur sozialen Wiederherstellung;
Operations: Wie man eine Community aufbaut, vermarktet und Benutzer gewinnt;
Erfahrung: Ob die Benutzererfahrung bei der Verwendung der Brieftasche gut genug ist, z. B. Glätte, Stabilität usw.;
Und die Hauptkontrolllogik einiger anderer C-Produkte.
Das zukünftige Wallet-Modell dürfte eher einem B2B2C-Modell ähneln. Während das Wallet als C-End-Produkt existiert, ist es wichtiger, eine ausgereifte SDK-Lösung für andere Anwendungen bereitzustellen, die in In-App-Wallets integriert und dann auf C-End-Benutzer ausgerichtet werden. Unter ihnen wurden Packer und Aggregatoren in der Anfangszeit hauptsächlich zentralisiert aufgebaut. Da dieser Teil jedoch den Kern der Werterfassung darstellt, müssen Wallets, die von anderen erstellt wurden, aufgegeben werden durch das Spiel der wirtschaftlichen Vorteile.
(Der obige Inhalt ist Auszug und Nachdruck mit Genehmigung des Partners MarsBit, Originaltextlink | Quelle: Foresight News)
Erklärung: Der Artikel gibt nur die persönlichen Ansichten und Meinungen des Autors wieder und gibt nicht die objektiven Ansichten und Positionen der Blockchain wieder. Alle Inhalte und Meinungen dienen nur als Referenz und stellen keine Anlageberatung dar. Anleger sollten ihre eigenen Entscheidungen und Transaktionen treffen, und der Autor und der Blockchain-Kunde haften nicht für direkte oder indirekte Verluste, die durch die Transaktionen der Anleger verursacht werden.
Dieser Artikel „Changes in Ethereum Wallets: Opportunities and Challenges of Account Abstraction and ERC-4337“ erschien erstmals auf Blockchain.