Modulare Smart-Contract-Kontoarchitektur und Herausforderungen

Einführung

Der Übergang von Externally Owned Accounts (EOA) zu Smart Contract Accounts (SCA) gewinnt an Dynamik und wurde von vielen Enthusiasten, darunter auch Vitalik selbst, begrüßt. Trotz der Aufregung ist die Einführung von SCA nicht so weit verbreitet wie EOAs. Die wichtigsten davon sind die Herausforderungen, die Bärenmärkte mit sich bringen, die Sorge um die Migration, Probleme bei der Beschilderung, Gasgemeinkosten und vor allem technische Schwierigkeiten.

Der wichtigste Vorteil von Account Abstractions (AA) ist die Möglichkeit, Code zum Anpassen der Funktionalität zu verwenden. Eine große technische Herausforderung ist jedoch die mangelnde Interoperabilität der AA-Funktionalitäten, und die Fragmentierung behindert die Integration und öffnet die Tür zur Anbieterbindung. Darüber hinaus kann die Gewährleistung der Sicherheit bei gleichzeitiger Aktualisierung und Erstellung von Funktionen kompliziert sein.

Betreten Sie Modular Account Abstraction als Teilmenge der umfassenderen AA-Bewegung. Dieser innovative Ansatz kann Smart Accounts von ihren benutzerdefinierten Funktionen trennen. Ziel ist es, eine modulare Struktur zu schaffen, um sichere, nahtlos integrierte Wallets mit vielfältigen Funktionalitäten zu entwickeln. In Zukunft kann ein kostenloser „App Store“ für Smart-Contract-Konten realisiert werden, der Wallets und dApps von der Erstellung von Funktionen befreit, sich aber auf das Benutzererlebnis konzentriert.

Nach der Lektüre dieses Artikels erhalten die Leser Einblicke in Folgendes:

1. Was ist modulare Kontoabstraktion?
2. Wie interagiert das Konto mit Modulen?
3. Wie ist die Reihenfolge beim Aufrufen von Modulen?
4. So finden und verifizieren Sie Module auf offene Weise

Ein kurzer Rückblick auf AA

SCA-Landschaft

Das traditionelle EOA bringt viele Herausforderungen mit sich, wie z. B. Seed-Phrase, Gas, Cross-Chain und mehrere Transaktionen. Wir hatten nie die Absicht, Komplexität einzuführen, aber tatsächlich ist Blockchain kein einfaches Spiel für die Massen.

Account Abstraction nutzt das Smart-Contract-Konto und ermöglicht eine programmierbare Validierung und Ausführung, bei der der Benutzer eine Reihe von Transaktionen auf einmal genehmigen kann, anstatt jede einzelne zu signieren und zu übertragen, und viele weitere Funktionen zu implementieren. Es bietet Vorteile für die Benutzererfahrung (z. B. Gasentnahme und Sitzungsschlüssel), Kosten (z. B. Batch-Transaktion) und Sicherheit (z. B. soziale Erholung, Multi-Sig). Derzeit gibt es zwei Möglichkeiten, eine Kontoabstraktion zu erreichen:

1. Protokollschicht: Einige Protokolle selbst bieten native Unterstützung für die Kontoabstraktion. ZKsync- Transaktionen folgen demselben Ablauf, unabhängig davon, ob sie von EOA oder SCA stammen, das einen einzelnen Mempool und Transaktionsfluss zur Unterstützung von AA verwendet. Starknet hat EOA entfernt und alle Konten sind SCA, und das haben sie auch native Smart-Contract-Wallets wie Argent.
2. Vertragsschicht: Für Ethereum und seine entsprechenden L2s führt ERC4337 einen separaten Einstiegspunkt für Transaktionen ein, um AA zu unterstützen, ohne die Konsensschicht zu ändern. Projekte wie Stackup, Alchemy, Etherspot, Biconomy, Candide und Plimico bauen eine Bundler-Infrastruktur auf, und viele weitere wie Safe, Zerodev, Etherspot und Biconomy bauen Stack und SDK auf.

👉 Wenn Sie mit AA oder ERC4337 nicht vertraut sind, sehen Sie sich hier die früheren Forschungsergebnisse von SevenX an.

Das Dilemma der SCA-Einführung

Das Thema Account Abstraction (AA) wird seit 2015 diskutiert und wurde dieses Jahr durch ERC4337 weiter ins Rampenlicht gerückt. Allerdings ist die Anzahl der eingesetzten Smart-Contract-Konten im Vergleich zu EOAs immer noch gering.

Schauen wir uns dieses Dilemma genauer an:

1. Auswirkungen auf den Bärenmarkt:
   Auch wenn AA Vorteile wie nahtlose Anmeldung und Gasentnahme mit sich bringt, besteht der vorherrschende Bärenmarkt in erster Linie aus gebildeten EOA-Benutzern und nicht aus neuen, sodass es keinen Anreiz für dApps und Wallets gibt. Dennoch sind führende Apps immer noch auf dem Weg zur Einführung von AA, wie Cyberconnect allein durch die Einführung ihres AA-Systems und ihrer gaslosen Lösung rund 360.000 UserOps (Transaktionen von AA) pro Monat generierte.
2. Migrationshindernisse:
   Für Wallets und Anwendungen, die Benutzer angesammelt und Vermögenswerte in EOAs gespeichert haben, bleibt die sichere und bequeme Migration von Vermögenswerten eine Herausforderung. Dennoch erlauben Initiativen wie EIP-7377 EOAs, eine einmalige Migrationstransaktion zu initiieren.
3. Signaturproblem:
   Der Smart Contract selbst kann natürlich keine Nachrichten signieren, da er keinen privaten Schlüssel wie EOAs besitzt. Bemühungen wie ERC1271 machen es möglich, aber die Nachrichtensignierung funktioniert erst bei der ersten Transaktion, was eine Herausforderung für Wallets darstellt, die eine kontrafaktische Bereitstellung verwenden. Und der von Ambire vorgeschlagene ERC-6492 ist ein abwärtskompatibler Nachfolger von ERC-1271, der möglicherweise das vorherige Problem löst.
4. Gasgemeinkosten:
   Die Bereitstellung, Simulation und Ausführung von SCAs verursacht im Vergleich zu Standard-EOAs höhere Kosten. Dies wirkt sich abschreckend auf die Adoption aus. Es wurden jedoch mehrere Tests durchgeführt, wie z. B. die Entkopplung der Kontoerstellung von Benutzervorgängen, und die Eliminierung von Konto-Salt- und Existenzprüfungen wird in Betracht gezogen, um diese Kosten zu senken.
5. Technische Schwierigkeiten:
   Das ERC-4337-Team hat das eth-infinitism-Repository eingerichtet, um Entwicklern eine grundlegende Implementierung bereitzustellen. Wenn wir jedoch auf differenziertere oder spezifischere Funktionen für verschiedene Anwendungsfälle umsteigen, werden Integration und Dekodierung zu einer Herausforderung.

In diesem Artikel befassen wir uns mit Problem Nr. 5: den technischen Schwierigkeiten.

🤔️

Modulares Smart-Contract-Konto zur Lösung technischer Schwierigkeiten

Um näher auf die technischen Schwierigkeiten einzugehen:

1. Zersplitterung:
   Funktionen werden jetzt auf verschiedene Weise aktiviert, sei es nativ durch bestimmte SCAs oder durch unabhängige Plugin-Systeme. Jede folgt ihrem eigenen Standard und zwingt die Entwickler dazu, zu entscheiden, welche Plattformen sie unterstützen möchten. Dies führt zu potenziellen Plattformbindungen oder überflüssigen Anstrengungen.
2. Sicherheit:
   Die Flexibilität zwischen Konten und Funktionen bietet zwar Vorteile, kann jedoch Sicherheitsbedenken verstärken. Funktionen werden möglicherweise gemeinsam geprüft, aber das Fehlen unabhängiger Bewertungen könnte das Risiko von Kontoschwachstellen erhöhen.
3. Ausbaufähigkeit:
   Bei der Weiterentwicklung von Funktionen ist es wichtig, die Fähigkeit zum Hinzufügen, Ersetzen oder Entfernen von Funktionen beizubehalten. Die erneute Bereitstellung vorhandener Funktionen bei jedem Update führt zu Komplexitäten.

Um uns in diesen Gewässern zurechtzufinden, benötigen wir aktualisierbare Verträge, die sichere und effiziente Upgrades gewährleisten, wiederverwendbare Kerne zur Verbesserung der Gesamtentwicklungseffizienz und standardisierte Schnittstellen, um sicherzustellen, dass Vertragskonten reibungslos zwischen verschiedenen Frontends wechseln können.

Diese Begriffe vereinen sich zu einem einzigen Konzept: Aufbau einer modularen Account-Abstraktions-Architektur (Modular AA).

Modular AA ist eine Nische innerhalb der breiteren AA-Bewegung, die die Modularisierung intelligenter Konten vorsieht, um sie für Benutzer anzupassen und Entwicklern die Möglichkeit zu geben, Funktionen mit minimalen Einschränkungen nahtlos zu erweitern.

Dennoch ist die Einführung und Förderung eines neuen Standards in jeder Branche eine große Herausforderung. In den Anfangsphasen kann es viele verschiedene Lösungen geben, bevor sich alle für die Hauptlösung entscheiden. Es ist jedoch ermutigend zu sehen, dass diejenigen, die an der Kontoabstraktion arbeiten, sei es das 4337 SDK, Wallet-Entwickler, Infrastrukturteams oder Protokolldesigner, alle zusammenkommen, um den Prozess zu beschleunigen.

Modularer Aufbau: Hauptkonto und Module

Wie ruft das Konto Module auf, um Funktionen zu realisieren?

Call- und Proxy-Vertrag delegieren

Externer Anruf und Delegiertenanruf:

Über DelegateCall

Delegatecall ähnelt zwar call, führt den Zielvertrag jedoch nicht in seinem eigenen Kontext aus, sondern im Kontext des aktuellen Status des aufrufenden Vertrags. Dies bedeutet, dass alle vom Zielvertrag vorgenommenen Statusänderungen im Speicher des aufrufenden Vertrags vorgenommen werden.

Proxy-Vertrag und DelegateCall

Um die zusammensetzbare und aktualisierbare Struktur zu realisieren, ist ein grundlegendes Wissen namens „Proxy-Vertrag“ erforderlich.

1. Proxy-Vertrag: Ein normaler Vertrag speichert seine Logik und Zustände, die nach der Bereitstellung nicht aktualisiert werden können. Ein Proxy-Vertrag, der einen Delegatecall für einen anderen Vertrag verwendet. Durch Verweis auf die Implementierungsfunktion wird diese im aktuellen Status des Proxy-Vertrags ausgeführt.
2. Anwendungsfälle: Während der Proxy-Vertrag unveränderlich bleibt, können Sie eine neue Implementierung hinter dem Proxy bereitstellen. Proxy-Verträge dienen der Aktualisierbarkeit und sind kostengünstiger in der Bereitstellung und Wartung auf öffentlichen Blockchains.

Sichere Architektur

Sichere Architektur

Was ist sicher:

Safe ist eine führende modulare Smart-Account-Infrastruktur, die praxiserprobte Sicherheit und Flexibilität bietet und es Entwicklern ermöglicht, vielfältige Anwendungen und Wallets zu erstellen. Bemerkenswert ist, dass viele Teams auf Safe aufbauen oder sich davon inspirieren lassen. Biconomy startete sein Konto durch die Erweiterung von Safe mit nativen 4337- und 1/1-Mehrfachsignaturen. Mit der Bereitstellung von über 164.000 Verträgen und der Sicherung eines Wertes von über 30,7 Milliarden ist Safe zweifellos die Nummer eins im Weltraum.

Was ist die Struktur von Safe?

1. Safe-Account-Vertrag: Haupt-Proxy-Vertrag (Stateful)
   Ein sicheres Konto ist ein Proxy-Vertrag, da es einen Singleton-Vertrag delegiert. Das sichere Konto enthält Eigentümer, Schwellenwert und Implementierungsadressen, die alle als Variablen des Proxys festgelegt sind und somit seinen Status definieren.
2. Singleton-Vertrag: Integration Hub (Stateless)
   Singleton bedient das Safe-Konto und integriert und definiert verschiedene Integrationen, einschließlich Plugin, Hook, Funktionshandler und Signaturvalidator.
3. Modulvertrag: Benutzerdefinierte Logik und Funktionen:
   Module sind leistungsstark. Plugins als modularer Typ können verschiedene Funktionen wie Zahlungsstreaming, Wiederherstellungsmechanismen und Sitzungsschlüssel definieren und durch den Abruf von Off-Chain-Daten als Brücke zwischen Web2 und Web3 dienen. Andere Module wie Hook als Schutzvorrichtung und Function Handler reagieren auf alle Anweisungen.

Was passiert, wenn wir Safe einführen:

1. Aufrüstbare Verträge:
   Die Bereitstellung eines neuen Singletons ist immer dann erforderlich, wenn neue Plugins eingeführt werden. Benutzer behalten die Autonomie, ihren Safe entsprechend ihren Vorlieben und Anforderungen auf die gewünschte Singleton-Version zu aktualisieren.
2. Zusammensetzbare und wiederverwendbare Module:
   Der modulare Charakter von Plugins ermöglicht es Entwicklern, Funktionalitäten unabhängig voneinander zu erstellen. Sie können diese Plugins dann je nach Anwendungsfall frei auswählen und kombinieren und so einen hochgradig anpassbaren Ansatz fördern.

ERC-2535 Diamond Proxys

ERC2535 Diamantarchitektur

Über ERC2535, Diamond Proxies:

Der ERC2535 standardisiert Diamonds, ein modulares Smart-Contract-System, das nach der Bereitstellung aktualisiert/erweitert werden kann und praktisch keine Größenbeschränkung hat. Bisher haben sich viele Teams davon inspirieren lassen, beispielsweise Zerodevs Kernel und Soul Wallets Experiment.

Was ist die Diamantstruktur:

1. Diamond-Vertrag: Haupt-Proxy-Vertrag (Stateful) Ein Diamond ist ein Proxy-Vertrag, der mithilfe von Delegatecall Funktionen aus seinen Implementierungen aufruft.
2. Modul-/Plugin-/Facettenvertrag: Benutzerdefinierte Logik und Funktionen (zustandslos) Ein Modul oder ein sogenannter Facettenvertrag ist ein zustandsloser Vertrag, der seine Funktionen für einen oder mehrere Diamanten bereitstellen kann. Dabei handelt es sich um separate, unabhängige Verträge, die interne Funktionen, Bibliotheken und Zustandsvariablen gemeinsam nutzen können.

Was passiert, wenn wir Diamond übernehmen:

1. Aktualisierbare Verträge: Diamond bietet eine systematische Möglichkeit, verschiedene Plugins zu isolieren und miteinander zu verbinden und Daten zwischen ihnen auszutauschen, außerdem fügt/ersetzt/entfernt jedes Plugin direkt mithilfe der DiamondCut-Funktion hinzu. Es gibt keine Begrenzung für die Anzahl der Plugins, die im Laufe der Zeit zu Diamonds hinzugefügt werden können.
2. Modulares und wiederverwendbares Plugin: Ein bereitgestelltes Plugin kann von einer beliebigen Anzahl von Diamanten verwendet werden, um die Bereitstellungskosten enorm zu senken.

Unterschied zwischen Safe Smart Account und Diamond-Ansatz:

Zwischen den Safe- und Diamond-Architekturen gibt es zahlreiche Ähnlichkeiten, da beide im Kern auf Proxy-Verträgen basieren und auf Logikverträge verweisen, um Aktualisierbarkeit und Modularität zu erreichen.

Der Hauptunterschied liegt jedoch in der Handhabung von Logikverträgen. Hier ist ein genauerer Blick:

1. Flexibilität:
   Im Zusammenhang mit der Aktivierung neuer Plugins erfordert Safe die erneute Bereitstellung seines Singleton-Vertrags, um die Änderung in seinem Proxy umzusetzen. Im Gegensatz dazu erreicht Diamond dies direkt durch die DiamondCut-Funktion in seinem Proxy. Diese unterschiedliche Herangehensweise führt dazu, dass Safe ein höheres Maß an Kontrolle behält, während Diamond eine verbesserte Flexibilität und Modularität einführt.
2. Sicherheit:
   Der derzeit in beiden Strukturen verwendete Delegatecall kann es externem Code ermöglichen, die Speicherung des Hauptvertrags zu manipulieren. In der Safe-Architektur verweist „delegatecall“ auf einen einzelnen Logikvertrag, während Diamond „delegatecall“ über mehrere Modulverträge hinweg – Plugins – verwendet. Folglich birgt ein bösartiges Plugin das Potenzial, ein anderes Plugin zu überschreiben, wodurch das Risiko von Speicherkollisionen entsteht, die die Integrität des Proxys gefährden könnten.
3. Kosten:
   Die dem Diamond-Ansatz innewohnende Flexibilität geht mit verstärkten Sicherheitsbedenken einher. Dadurch erhöht sich der Kostenfaktor, sodass bei jeder Hinzufügung eines neuen Plugins umfassende Prüfungen erforderlich werden. Der Schlüssel besteht darin, sicherzustellen, dass diese Plugins sich nicht gegenseitig in ihren Funktionen beeinträchtigen, was insbesondere für kleine und mittlere Unternehmen, die strenge Sicherheitsstandards einhalten möchten, eine Herausforderung darstellt.

Als Beispiele für unterschiedliche Strukturen mit Proxys und Modulen dienen der „Safe Smart Account-Ansatz“ und der „Diamond-Ansatz“. Es ist von entscheidender Bedeutung, Flexibilität und Sicherheit in Einklang zu bringen, und diese beiden Methoden könnten sich in Zukunft möglicherweise ergänzen.

Reihenfolge der Module: Validator, Executor und Hook

Wie ist die Reihenfolge beim Aufrufen von Modulen?

Lassen Sie uns unsere Diskussion erweitern, indem wir ERC6900 vorstellen, einen vom Alchemy- Team vorgeschlagenen Standard, der von Diamond inspiriert und speziell auf ERC-4337 zugeschnitten ist. Es begegnet der Herausforderung der Modularität bei Smart Accounts, indem es gemeinsame Schnittstellen bereitstellt und die Bemühungen zwischen Plugin- und Wallet-Entwicklern koordiniert.

Wenn es um den Transaktionsprozess von AA geht, gibt es drei Hauptprozesse: Validierung, Ausführung und Hook. Diese Schritte können alle verwaltet werden, indem das Proxy-Konto zum Aufrufen von Modulen verwendet wird, wie wir bereits besprochen haben. Auch wenn verschiedene Projekte unterschiedliche Namen verwenden, ist es wichtig, die ähnliche zugrunde liegende Logik zu verstehen.

Funktionsnamen in unterschiedlichem Design

1. Validierung: Stellt die Authentizität und Autorität des Anrufers gegenüber dem Konto sicher.
2. Ausführung: Führt jede benutzerdefinierte Logik aus, die das Konto zulässt.
3. Hook: Fungiert als Modul, das vor oder nach einer anderen Funktion ausgeführt wird. Es kann den Status ändern oder dazu führen, dass der gesamte Anruf rückgängig gemacht wird.

ERC6900

Es ist wichtig, Module nach einer anderen Logik zu trennen. Ein standardisierter Ansatz sollte vorschreiben, wie Validierungs-, Ausführungs- und Hook-Funktionen für Smart-Contract-Konten geschrieben werden sollen. Unabhängig davon, ob es sich um Safe oder ERC6900 handelt, trägt die Standardisierung dazu bei, die Notwendigkeit einzigartiger Entwicklungsaufwände für bestimmte Implementierungen oder Ökosysteme zu reduzieren und eine Anbieterbindung zu verhindern.

Module Discovery und Security

So finden und verifizieren Sie Module auf offene Weise

Eine Lösung, die immer mehr an Bedeutung gewinnt, besteht in der Schaffung eines Ortes, der es Benutzern ermöglicht, überprüfbare Module zu entdecken, den wir „Registrierung“ nennen können. Diese Registrierung ähnelt einem „App Store“ und soll einen vereinfachten, aber florierenden modularen Marktplatz fördern.

Sicheres{Core} -Protokoll

Sicheres{Core} -Protokoll

Safe{Core} Protocol ist ein interoperables Open-Source-Protokoll für Smart-Contract-Konten, das die Zugänglichkeit für verschiedene Anbieter und Entwickler verbessern und gleichzeitig durch klar definierte Standards und Regeln robuste Sicherheit gewährleisten soll.

1. Konto: Im Safe{Core} Protocol ist das Konzept eines Kontos flexibel und nicht an eine bestimmte Implementierung gebunden. Dies ermöglicht die Teilnahme diverser Kontodienstleister.
2. Manager: Der Manager fungiert als Koordinator zwischen Konten, Registern und Modulen. Als Berechtigungsschicht ist sie auch für die Sicherheit verantwortlich.
3. Registrierungen: Registrierungen definieren Sicherheitsattribute und setzen Standards wie ERC6900 für Module durch, mit dem Ziel, eine offene „App Store“-Umgebung für Auffindbarkeit und Sicherheit zu schaffen.
4. Module: Module handhaben Funktionalitäten und sind in verschiedenen Anfangstypen erhältlich, darunter Plugins, Hooks, Signaturvalidatoren und Funktionshandler. Diese stehen Entwicklern zur Mitarbeit offen, sofern sie die festgelegten Standards erfüllen.

Strass-Design

Strass-Design

Der Prozess läuft wie folgt ab:

1. Erstellen einer Schemadefinition: Ein Schema dient als vordefinierte Datenstruktur, die für die Attestierung erforderlich ist. Es kann von Unternehmen an ihre spezifischen Anwendungsfälle angepasst werden.
2. Erstellen von Modulen basierend auf einem Schema: Intelligente Verträge werden als Module registriert, erhalten Bytecode und wählen eine Schema-ID. Diese Daten werden dann in der Registrierung gespeichert.
3. Einholen einer Bescheinigung für ein Modul: Attestierer/Auditoren können Bescheinigungen für Module auf Schemabasis bereitstellen. Diese Attestierungen können eine eindeutige Kennung (UID) und Verweise auf andere Attestierungen zur Verkettung enthalten. Sie können sich über Ketten hinweg verbreiten und überprüfen, ob bestimmte Schwellenwerte in Zielketten erreicht werden.
4. Komplexe Logik mit Resolvern implementieren: Resolver, optional im Schema festgelegt, kommen ins Spiel. Sie können während der Modulerstellung, der Zertifizierungserstellung und des Widerrufs aufgerufen werden. Diese Resolver ermöglichen es Entwicklern, komplexe und vielfältige Logik zu integrieren und gleichzeitig Attestierungsstrukturen beizubehalten.
5. Benutzerfreundlicher Abfragezugriff: Abfragen bieten Benutzern die Möglichkeit, vom Front-End aus auf Sicherheitsinformationen zuzugreifen. Diese EIP finden Sie hier.

Obwohl sich dieses Schema noch in einem frühen Stadium befindet, birgt es das Potenzial, einen Standard auf dezentrale und kollaborative Weise zu etablieren. Ihre Registrierung ermöglicht es Entwicklern, ihre Module zu registrieren, Prüfern, um ihre Sicherheit zu überprüfen, und Wallets, die sie integrieren können, und ermöglicht es Benutzern, Module mühelos zu finden und ihre Attestierungsinformationen zu überprüfen. Zukünftige Verwendungsmöglichkeiten könnten sein:

1. Attestierer: Vertrauenswürdige Unternehmen wie Safe könnten mit Rhinestone als Attestierer für interne Module zusammenarbeiten. Gleichzeitig könnten unabhängige Attestierer hinzukommen.
2. Modulentwickler: Da sich ein offener Markt herausbildet, könnten Modulentwickler ihre Arbeit möglicherweise über die Registrierung monetarisieren.
3. Benutzer: Über benutzerfreundliche Schnittstellen wie Wallets oder dApps können Benutzer Modulinformationen prüfen und Vertrauen an verschiedene Attestierer delegieren.

Das Konzept der „Module Registry“ eröffnet Plugin- und Modulentwicklern Möglichkeiten zur Monetarisierung. Es könnte den Weg für einen „Modul-Marktplatz“ weiter ebnen. Einige Aspekte könnten vom Safe-Team überwacht werden, während andere sich in dezentralen Marktplätzen manifestieren könnten, die zu Beiträgen einladen und transparente Prüfaufzeichnungen für alle bieten. Indem wir dies integrieren, können wir eine Anbieterbindung vermeiden und die Erweiterung des EVM unterstützen, indem wir ein verbessertes Benutzererlebnis hinzufügen, das ein breiteres Publikum anzieht.

Während diese Ansätze die Sicherheit eines einzelnen Moduls garantieren, ist die umfassendere Sicherheit intelligenter Vertragskonten nicht narrensicher. Die Kombination legitimer Module und der Nachweis, dass sie keine Speicherkollisionen aufweisen, kann eine Herausforderung sein, was die Bedeutung der Wallet- oder AA-Infrastruktur für die Bewältigung solcher Probleme unterstreicht.

Abschließende Gedanken

Durch die Verwendung eines modularen Smart-Contract-Kontostapels können Wallet-Anbieter und dApps von der Komplexität der technischen Wartung befreit werden. Mittlerweile haben externe Modulentwickler die Möglichkeit, auf individuelle Bedürfnisse zugeschnittene Spezialdienstleistungen anzubieten. Zu den Herausforderungen, die es zu bewältigen gilt, gehört jedoch, ein Gleichgewicht zwischen Flexibilität und Sicherheit zu finden, modulare Standards voranzutreiben und standardisierte Schnittstellen zu implementieren, die es Benutzern ermöglichen, ihre Smart Accounts einfach zu aktualisieren und zu ändern.

Dennoch sind modulare Smart Contract Accounts (SCA) nur ein Teil des Akzeptanzpuzzles. Um das Potenzial von SCA voll auszuschöpfen, ist zusätzliche Unterstützung auf Protokollebene durch Layer-2-Lösungen erforderlich, z. B. eine robuste Bundler-Infrastruktur und ein Peer-to-Peer-Mempool, ein kostengünstigerer und praktikablerer SCA-Signaturmechanismus sowie eine kettenübergreifende SCA-Synchronisierung und -Verwaltung und entwickeln benutzerfreundliche Schnittstellen.

Mit Blick auf die Zukunft stellen wir uns eine Zukunft vor, in der die Beteiligung weit verbreitet ist und interessante Fragen aufwirft: Sobald der SCA-Auftragsfluss ausreichend profitabel ist, wie werden dann traditionelle MEV-Mechanismen (Miner Extractable Value) Einzug halten, um Bündeler aufzubauen und Werte zu erfassen? Wie können Kontoabstraktionen (AA) als Grundlage für „absichtsbasierte“ Transaktionen dienen, wenn die Infrastruktur ausgereift ist? Bleiben Sie dran; Die Landschaft entwickelt sich von Minute zu Minute weiter.

Wichtige Stücke

1. Sicheres Whitepaper: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Strass-Dokument: https://docs.rhinestone.wtf/
3. Biconomy-Dokument: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

Haftungsausschluss:

1. Dieser Artikel ist ein Nachdruck von [SevenX Ventures ]. Alle Urheberrechte liegen beim ursprünglichen Autor [SevenX Ventures]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.