CAKE-Framework (Deep Parsing Chain Abstraction Key Elements).

Originalautor: Favorite Mirror Reads Archive

Originalzusammenstellung: Shechao TechFlow

Zusammenfassung der wichtigsten Punkte

• Die aktuelle Standardbenutzererfahrung bei der Verschlüsselung besteht darin, dass Benutzer immer wissen, mit welchem ​​Netzwerk sie interagieren. Allerdings müssen Internetnutzer nicht wissen, mit welchem ​​Cloud-Anbieter sie interagieren. Diesen Ansatz auf die Blockchain zu übertragen, nennen wir Chain Abstraction.

• In diesem Artikel wird das Chain Abstraction Key Elements (CAKE)-Framework vorgestellt. Das Framework besteht aus vier Teilen: Anwendungsschicht, Berechtigungsschicht, Lösungsschicht und Abrechnungsschicht, mit dem Ziel, Benutzern ein nahtloses kettenübergreifendes Betriebserlebnis zu bieten.

• Die Implementierung der Kettenabstraktion erfordert eine Reihe komplexer Technologien, um Zuverlässigkeit, Kosteneffizienz, Sicherheit, Geschwindigkeit und Datenschutz des Ausführungsprozesses sicherzustellen.

• Wir definieren die kettenübergreifenden Kompromisse in der Kettenabstraktion als Trilemma und schlagen sechs Designalternativen vor, jede mit ihren einzigartigen Vorteilen.

• Um den Sprung in eine Zukunft der verketteten Abstraktion erfolgreich zu schaffen, müssen wir als Branche einen gemeinsamen Standard für die Weitergabe von Informationen zwischen den Ebenen von CAKE definieren und übernehmen. Ein guter Standard ist das Tüpfelchen auf dem i.

Einführung

Im Jahr 2020 wurde das Ethereum-Netzwerk auf eine Rollup-zentrierte Skalierungs-Roadmap umgestellt. Vier Jahre später sind mehr als 50 Rollup-Lagen (L2) im Einsatz. Während die Rollup-Ebene die erforderliche horizontale Skalierung bereitstellt, beeinträchtigt sie das Benutzererlebnis völlig.

Benutzern sollte es egal sein oder sie verstehen, mit welchem ​​Rollup sie interagieren. Krypto-Benutzer wissen, welches Rollup sie verwenden (Optimism oder Base), gleichbedeutend mit Web2-Benutzern, die wissen, welchen Cloud-Anbieter sie verwenden (AWS oder GCP). Die Vision von Chain Abstraction besteht darin, Ketteninformationen aus dem Sichtfeld des Benutzers zu abstrahieren. Der Benutzer verbindet einfach das Wallet mit der dApp und signiert die beabsichtigten Aktionen. Die Details, um sicherzustellen, dass der Benutzer das richtige Gleichgewicht in der Zielkette hat und die beabsichtigten Aktionen ausführt, werden alle hinter den Kulissen erledigt.

In diesem Artikel werden wir untersuchen, wie die Kettenabstraktion ein wirklich multidisziplinäres Problem ist, das das Zusammenspiel der Anwendungsschicht, Berechtigungsschicht, Lösungsschicht und Abrechnungsschicht umfasst. Wir stellen das Key Elements of Chain Abstraction (CAKE)-Framework vor und befassen uns mit den Design-Kompromissen von Kettenabstraktionssystemen.

Vorstellung des CAKE-Frameworks

In der Welt der Kettenabstraktion besuchen Benutzer die dApp-Website, stellen eine Verbindung zu ihrer Wallet her, unterzeichnen Vorgänge und warten auf die endgültige Abrechnung. Alle komplexen Vorgänge werden in der Infrastrukturschicht von CAKE ausgeführt. Zu den drei Infrastrukturschichten von CAKE gehören:

• Berechtigungsebene: Benutzer verbinden ihre Wallets mit dApps und fordern Angebote für Benutzerabsichten an. Absicht bezieht sich auf das Ergebnis, das der Benutzer am Ende der Transaktion erwartet, nicht auf den Transaktionspfad. Überweisen Sie beispielsweise USDT an eine Tron-Adresse oder zahlen Sie USDC in eine ertragsgenerierende Strategie auf Arbitrum ein. Das Wallet sollte in der Lage sein, Benutzerressourcen zu lesen (d. h. Status lesen) und Transaktionen auf der Zielkette durchzuführen (d. h. Status aktualisieren).

• Solver-Schicht: Die Solver-Schicht schätzt Gebühren und Ausführungsgeschwindigkeit basierend auf dem anfänglichen Guthaben und der Absicht des Benutzers. In einer kettenübergreifenden Umgebung ist dieser als Lösen bezeichnete Prozess von entscheidender Bedeutung, da Transaktionen asynchron sind und Untertransaktionen während der Ausführung fehlschlagen können. Asynchronität führt ein kettenübergreifendes Trilemma ein, das Gebühren, Ausführungsgeschwindigkeit und Ausführungsgarantien umfasst.

• Abrechnungsschicht: Nachdem ein Benutzer eine Transaktion mit einem privaten Schlüssel genehmigt hat, stellt die Abrechnungsschicht deren Ausführung sicher. Es besteht aus zwei Schritten: Überbrücken von Benutzerressourcen mit der Zielkette und anschließendes Ausführen der Transaktion. Wenn Protokolle für bestimmte Operationen komplexe Löser verwenden, können sie ihre eigene Liquidität bereitstellen und Operationen im Namen der Benutzer ausführen, ohne dass Brücken erforderlich sind.

Die Implementierung der Kettenabstraktion bedeutet, die oben genannten drei Infrastrukturschichten zu einem einheitlichen Produkt zusammenzuführen. Eine wichtige Erkenntnis bei der Zusammenführung dieser Ebenen ist der Unterschied zwischen Informationsbereitstellung und Wertbereitstellung. Die Informationsübertragung zwischen Ketten sollte verlustfrei sein, also verlassen Sie sich auf den sichersten Weg. Beispielsweise möchten Benutzer, die in einer Kette mit „Ja“ für eine Governance-Abstimmung in einer anderen Kette stimmen, nicht, dass ihre Stimme zu „Vielleicht“ wird. Andererseits kann je nach Benutzerpräferenzen die Wertbereitstellung verloren gehen. Ein etablierter Dritter kann genutzt werden, um Benutzern eine schnellere, günstigere oder garantierte Wertlieferung zu bieten. Es ist wichtig zu beachten, dass 95 % des Blockraums von Ethereum für die Wertübertragung genutzt werden, gemessen an den an Validatoren gezahlten Gebühren.

wichtige Designentscheidungen

Die oben genannten drei Ebenen stellen die wichtigsten Designentscheidungen vor, die CAF treffen muss. Bei diesen Entscheidungen geht es darum, wer die Befugnis zur Ausführung der Absicht kontrolliert, welche Informationen dem Löser offengelegt werden und welche Abwicklungspfade dem Löser zur Verfügung stehen. Nachfolgend finden Sie eine detaillierte Analyse jedes Levels.

Berechtigungsstufe

Die Berechtigungsschicht speichert den privaten Schlüssel des Benutzers und signiert Nachrichten im Namen des Benutzers, die dann als Transaktionen in der Kette ausgeführt werden. CAF muss die Signaturschemata und Transaktionsnutzlasten aller Zielketten unterstützen. Beispielsweise sind Wallets, die das ECDSA-Signaturschema und den EVM-Transaktionsstandard unterstützen, auf Ethereum, sein L2 und seine Sidechains (wie das Metamask-Wallet) beschränkt. Andererseits können Wallets, die EVM und SVM (Solana VM) unterstützen, diese beiden Ökosysteme unterstützen (wie das Phantom Wallet). Es ist zu beachten, dass dieselbe mnemonische Phrase zum Generieren von Wallets sowohl in der EVM- als auch in der SVM-Kette verwendet werden kann.

Eine Multi-Chain-Transaktion besteht aus mehreren Untertransaktionen, die in der richtigen Reihenfolge ausgeführt werden müssen. Diese Untertransaktionen müssen auf mehreren Ketten ausgeführt werden, jede mit ihren eigenen zeitlich variierenden Gebühren und Nonces. Wie diese Teiltransaktionen koordiniert und abgewickelt werden, ist eine wichtige Designentscheidung für die Berechtigungsebene.

• EOA Wallet ist eine Wallet-Software, die auf dem Computer des Benutzers läuft und seinen privaten Schlüssel speichert. Dabei kann es sich um browserbasierte Erweiterungen wie Metamask und Phantom, mobile Apps wie Coinbase Wallet oder spezielle Hardware wie Ledger handeln. Bei EOA-Wallets müssen Benutzer jede Untertransaktion einzeln signieren, was derzeit mehrere Klicks erfordert. Sie erfordern außerdem, dass Benutzer Gebührensalden in der Zielkette halten, was zu erheblichen Reibungsverlusten im Prozess führt. Indem Benutzern jedoch ermöglicht wird, mehrere Untertransaktionen mit einem einzigen Klick zu signieren, kann die Reibung mehrerer Klicks vom Benutzer abstrahiert werden.

• In einem Account Abstraction (AA)-Wallet haben Benutzer weiterhin Zugriff auf ihre privaten Schlüssel, trennen jedoch den Unterzeichner der Transaktionsnutzlast vom Ausführer der Transaktion. Ermöglicht es komplexen Parteien, Benutzertransaktionen atomar zu bündeln und auszuführen (Avocado, Pimlico). AA-Wallets erfordern weiterhin, dass Benutzer jede Untertransaktion einzeln signieren (derzeit über mehrere Klicks), erfordern jedoch nicht, dass in jeder Kette ein Gebührensaldo gehalten wird.

• Richtlinienbasierte Agenten speichern den privaten Schlüssel des Benutzers in einer separaten Ausführungsumgebung und generieren signierte Nachrichten im Namen des Benutzers basierend auf der Richtlinie des Benutzers. Telegram Bot, Near Account Aggregator oder SUAVE TEE sind strategiebasierte Wallets, während Entropy oder Capsule strategiebasierte Wallet-Erweiterungen sind. Benutzer müssen lediglich ein Genehmigungsformular unterzeichnen, und die anschließende Unterzeichnung von Untertransaktionen und der Kostenverwaltung kann von diesen Agenten während des Vorgangs durchgeführt werden.

Solver-Schicht

Nachdem der Benutzer die Absicht veröffentlicht hat, umfasst die Lösungsschicht die Rückgabe der Gebühr und der Bestätigungszeit an den Benutzer. Dieses Problem steht in engem Zusammenhang mit der Gestaltung von Orderflow-Auktionen und wird hier ausführlich besprochen. CAF kann protokollinterne Pfade nutzen, um Benutzerabsichten auszuführen, oder komplexe Dritte (z. B. Solver) nutzen, um bestimmte Sicherheitsgarantien zu gefährden und Benutzern ein verbessertes Benutzererlebnis zu bieten. Die Einführung des Lösers in das CAF-Framework wird zu den nächsten beiden Entwurfsentscheidungen führen, die eng mit den Informationen verknüpft sind.

Absichten bestehen aus zwei Arten extrahierbarer Werte (EVs): EV_ordering value und EV_signal.

• EV_ordering ist ein Blockchain-spezifischer Wert, der typischerweise von der Entität extrahiert wird, die Benutzeraufträge ausführt (z. B. Blockersteller oder Validatoren).

• EV_signal stellt den Wert dar, der für jede Entität, die der Bestellung nachkommt, zugänglich ist, bevor er offiziell in der Blockchain aufgezeichnet wird.

Unterschiedliche Benutzerabsichten haben unterschiedliche Verteilungen zwischen EV_ordering und EV_signal. Beispielsweise hat die Absicht, Münzen an einem DEX zu tauschen, typischerweise einen hohen EV_ordering-Wert, aber einen niedrigen EV_signal-Wert. Umgekehrt wird die EV_signal-Komponente einer gehackten Transaktion höher sein, da das Front-Running mehr Wert gewinnt als die Ausführung der Transaktion. Es ist erwähnenswert, dass EV_signal manchmal negativ sein kann, beispielsweise im Fall des Market-Maker-Handels, bei dem das Unternehmen, das diese Aufträge ausführt, Verluste erleiden kann, da der Market-Maker die zukünftigen Marktbedingungen besser kennt.

Wenn jemand in der Lage ist, die Absicht eines Benutzers im Voraus zu beobachten, kann er einen Schritt voraus sein und zu Wertverlusten führen. Darüber hinaus führt die Möglichkeit eines negativen EV_signals zu einem Wettbewerbsumfeld zwischen den Lösungsanbietern, was dazu führt, dass sie niedrigere Gebote abgeben, was zu einem weiteren Wertverlust (auch negative Auswahl genannt) führt. Letztlich wirken sich Leaks auf die Benutzer aus, indem sie die Gebühren erhöhen oder bessere Angebote anbieten. Bitte beachten Sie, dass niedrige Gebühren oder erhöhte Preise zwei Seiten derselben Medaille sind und im weiteren Verlauf dieses Artikels synonym verwendet werden.

Informationsaustausch

Es gibt drei Möglichkeiten, Informationen mit dem Solver zu teilen:

• Öffentlicher Mempool: Benutzerabsichten werden öffentlich an den öffentlichen Mempool oder die Datenverfügbarkeitsschicht gesendet, und der erste Löser, der die Anforderung erfüllen kann, führt die Bestellung aus und wird zum Gewinner. Dieses System extrahiert in hohem Maße Benutzerinformationen, da Benutzer ihre EV_ordering und EV_signal offenlegen. Zum Beispiel der öffentliche Mempool von Ethereum und verschiedene Blockchain-Brücken. Im Falle einer Bridge müssen Benutzer Vermögenswerte treuhänderisch hinterlegen, bevor sie sie an die Zielkette übertragen, um böswillige Angriffe zu verhindern. Durch diesen Vorgang werden ihre Absichten jedoch versehentlich öffentlich gemacht.

• Teilweise Weitergabe: CAF kann den den Bietern offengelegten Wert reduzieren, indem es die offengelegten Informationen einschränkt. Dieser Ansatz führt jedoch direkt zum Verlust der Preisoptimalität und kann zu Problemen wie Gebots-Spam führen.

• Private Mempools: Jüngste Entwicklungen bei MPC und TEE ermöglichen vollständig private Mempools. Es werden keine Informationen außerhalb der Ausführungsumgebung durchgesickert, und die Löser kodieren ihre Präferenzen und passen jede Absicht an. Obwohl der private Mempool EV_ordering erfasst, kann er EV_signal nicht vollständig erfassen. Wenn beispielsweise eine gehackte Transaktion an Mempool gesendet wird, kann die erste Person, die die Bestellung sieht, der Transaktion zuvorkommen und das EV_signal erfassen. In einem privaten Mempool werden Informationen erst freigegeben, nachdem der Block bestätigt wurde, sodass jeder, der die Transaktion sieht, das EV_signal erfassen kann. Es ist denkbar, dass der Löser Authentifizierungsknoten einrichtet, um EV_Signal aus neu geprägten TEE-Blöcken zu erfassen, wodurch die EV_Signal-Erfassung zu einem verzögerten Wettbewerb wird.

Solver-Liste

CAF muss auch entscheiden, wie viele und welche Bieter an der Auktion teilnehmen dürfen. Die Hauptoptionen sind wie folgt:

• Open Access: Die geringstmögliche Eintrittsbarriere für die Teilhabefähigkeit. Dies ähnelt dem Offenlegen von Mempool, wodurch EV_signal und EV_ordering verloren gehen.

• Zugriff einschränken: Möglichkeiten zur Auftragsausführung durch Whitelisting, Reputationssysteme, Gebühren oder Sitzplatzauktionen einschränken. Der Gating-Mechanismus ist erforderlich, um sicherzustellen, dass das EV_signal nicht von den Lösern im System erfasst wird. Zum Beispiel 1inch Auction, Cowswap Auctions und Uniswap X Auction. Der auftragsgewinnende Wettbewerb erfasst EV_ordering für Benutzer, während Gating-Mechanismen EV_signal für Auftragsgeneratoren (Wallets, dApps) erfassen.

• Exklusiver Zugang: Exklusiver Zugang ist ein spezielles Auktionsformat, bei dem pro Zeitraum nur ein Löser ausgewählt wird. Da keine Informationen an andere Löser weitergegeben werden, gibt es keine negative Auswahl und keine frühen Rabatte. Der Orderflow-Initiator erfasst die erwarteten Werte von EV_signal und EV_ordering, und da es keinen Wettbewerb gibt, erhalten Benutzer nur Ausführungen, aber keine Preisverbesserungen. Beispiele für solche Auktionen sind Robinhood- und DFlow-Auktionen.

Siedlungsschicht

Sobald eine Wallet eine Reihe von Transaktionen signiert, müssen diese auf der Blockchain ausgeführt werden. Kettenübergreifende Transaktionen verwandeln den Abwicklungsprozess von einer atomaren Operation in eine asynchrone Operation. Während der ersten Transaktionsausführung und -bestätigung kann sich der Status der Zielkette ändern, was möglicherweise dazu führt, dass die Transaktion fehlschlägt. In diesem Unterabschnitt werden die Kompromisse zwischen Sicherheitskosten, Bestätigungszeit und Ausführungsgarantien untersucht.

Es ist wichtig zu beachten, dass die Ausführung der beabsichtigten Transaktion auf der Zielkette unter anderem vom Transaktionseinschlussmechanismus der Zielkette abhängt, einschließlich der Fähigkeit, Transaktionen zu überprüfen, und vom Gebührenmechanismus der Zielkette. Wir glauben, dass die Wahl der Zielkette eine dApp-Entscheidung ist und den Rahmen dieses Artikels sprengt.

Kettenübergreifendes Orakel

Zwei Blockchains mit unterschiedlichen Zuständen und Konsensmechanismen erfordern einen Vermittler, beispielsweise ein Orakel, um die Informationsübertragung zwischen ihnen zu erleichtern. Das Orakel fungiert als Relais für die Übertragung von Informationen zwischen Ketten, einschließlich der Überprüfung, ob ein Benutzer Gelder auf einem Treuhandkonto in einer Locking-and-Minting-Brücke gesperrt hat, oder der Bestätigung des Token-Guthabens eines Benutzers in der ursprünglichen Kette, um an Governance-Abstimmungen über die Blockchain teilzunehmen Zielkette.

Das Orakel überträgt Informationen mit der Geschwindigkeit der langsamsten Kette. Dies dient dazu, das Risiko einer Neuorganisation zu bewältigen, da das Orakel auf den Konsens der ursprünglichen Kette warten muss. Angenommen, ein Benutzer möchte USDC von der ursprünglichen Kette zur Zielkette überbrücken und sperrt zu diesem Zweck sein Geld auf einem Treuhandkonto. Allerdings kann es zu Problemen kommen, wenn das Oracle nicht auf genügend Bestätigungen wartet und weiterhin Token für den Benutzer in der Zielkette prägt. Wenn eine Reorganisation stattfindet und Benutzer ihre Treuhandtransaktionen überschreiben, verursacht das Orakel eine doppelte Ausgabe.

Es gibt zwei Arten von Orakeln:

• Off-Protocol-Orakel: müssen von den Validatoren Dritter getrennt sein, die den Konsens steuern, um Informationen zwischen Ketten weiterzugeben. Zusätzliche Validatoren erhöhen die Kosten für den Betrieb eines Orakels. LayerZero, Wormhole, ChainLink und Axelar Networks sind Beispiele für Orakel außerhalb des Protokolls.

• Protokollinterne Orakel: Sind tief in den Konsensalgorithmus des Ökosystems integriert und kommunizieren Informationen mithilfe der Gruppe von Validatoren, die den Konsens ausführen. Der IBC von Cosmos wird für Ketten verwendet, auf denen das Cosmos SDK läuft, das Polygon-Ökosystem entwickelt AggLayer und Optimism entwickelt Superchain. Jedes Orakel nutzt einen dedizierten Blockraum, um Informationen zwischen Ketten im selben Ökosystem weiterzugeben.

• Shared Sequencer sind Entitäten außerhalb des Protokolls, die über Transaktionsordnungsrechte innerhalb des Protokolls verfügen, das heißt, sie können Transaktionen über Ketten hinweg bündeln. Obwohl sich der Shared Sequencer noch in der Entwicklung befindet, muss er nicht auf bestimmte Blockbestätigungen warten, um das Risiko von Reorganisationen zu verringern. Um wirklich eine kettenübergreifende Atomizität zu erreichen, muss der gemeinsam genutzte Sequenzer in der Lage sein, nachfolgende Transaktionen auszuführen, wenn frühere Transaktionen erfolgreich sind, und sie dadurch in Ketten umzuwandeln.

Überbrückungstoken

In einer Multi-Chain-Welt sind die Token- und Gebührenguthaben eines Benutzers über alle Netzwerke verteilt. Vor jeder kettenübergreifenden Operation müssen Benutzer Gelder von der ursprünglichen Kette zur Zielkette überbrücken. Derzeit gibt es 34 aktive Cross-Chain-Brücken mit einem Gesamt-TVL von 7,7 Milliarden US-Dollar und einem Brückenvolumen von 8,6 Milliarden US-Dollar in den letzten 30 Tagen.

Bei Bridging-Tokens handelt es sich um eine Wertübertragung. Dies schafft Möglichkeiten, auf professionelle Dritte zurückzugreifen, die sich mit Kapitalmanagement auskennen und bereit sind, Restrukturierungsrisiken zu tragen, wodurch die Kosten und der Zeitaufwand für den Handel durch die Benutzer reduziert werden.

Es gibt zwei Arten von Cross-Chain-Brücken:

• Lock and Mint Bridge: Die Lock and Mint Bridge überprüft Token-Einzahlungen auf der Originalkette und prägt Token auf der Zielkette. Der Kapitalbedarf für den Bau einer solchen Brücke ist gering, die sichere Übertragung gesperrter Informationen erfordert jedoch erhebliche Investitionen. Sicherheitsverletzungen auf diesen Brücken führten zu Verlusten in Milliardenhöhe für Token-Inhaber.

• Liquidity Bridge: Liquidity Bridge nutzt die Liquiditätspools der Originalkette und der Zielkette und verwendet Algorithmen, um die Umrechnungsrate zwischen der Originalkette und dem Ziel-Token zu bestimmen. Obwohl diese Brücken höhere Anschaffungskosten verursachen, erfordern sie geringere Sicherheitsgarantien. Bei einem Sicherheitsverstoß sind nur die Gelder im Liquiditätspool gefährdet.

Bei beiden Cross-Chain-Brücken müssen Benutzer Liquiditätskosten zahlen. Bei einer Locking-and-Minting-Brücke fallen die Liquiditätskosten beim Umtausch vom Wrapping-Token zum gewünschten Token (USDC.e zu USDC) in der Zielkette an, während bei einer Liquiditätsbrücke die Liquiditätskosten beim Umtausch vom Original anfallen Token zu USDC Tritt auf, wenn Token in der Kette gegen Token in der Zielkette ausgetauscht werden.

Cross-Chain-Trilemma

Die oben genannten fünf Designentscheidungen werfen das Cross-Chain-Trilemma auf. CAF muss zwei Attribute auswählen: Ausführungsgarantie, niedrige Gebühren und Ausführungsgeschwindigkeit.

• Intraprotokollpfad: Dies ist der festgelegte kettenübergreifende Informationsübertragungspfad. Diese Systeme berücksichtigen das Reorganisationsrisiko, opfern zwar die Ausführungsgeschwindigkeit, senken aber die Kosten durch den Wegfall zusätzlicher Validatorsätze oder Liquiditätskosten.

• Solver-Aggregation: Sammeln Sie Angebote von mehreren Solvern, um den günstigsten und schnellsten Weg zur Umsetzung der Benutzerabsicht zu ermitteln. Aufgrund der nachteiligen Auswahl und des Front-Running kann es jedoch vorkommen, dass der Löser die Absicht nicht erfüllt, was zu einer verringerten Ausführung führt.

• Ausführungswettbewerb: Wählen Sie den siegreichen Löser aus, indem Sie die Löser so anordnen, dass sie an Ausführungsabsichten teilnehmen, oder indem Sie einen einzelnen Löser auswählen. Beide Ansätze führen zu hohen Benutzergebühren, da die Lösungsanbieter eher um die Ausführung als um Preisverbesserungen konkurrieren.

Die sechs Komponenten von CAKE

Für diesen Artikel haben wir über 20 Teamdesigns untersucht, die direkt und indirekt an der Kettenabstraktion arbeiten. In diesem Abschnitt besprechen wir sechs unabhängige CA-Implementierungen, von denen wir glauben, dass sie inhärente Effizienz und Produktmarkttauglichkeit aufweisen. Bei korrekter Bauweise können diese Designs miteinander kombiniert werden.

Eine wichtige Schlussfolgerung ist, dass wir einen einheitlichen Standard für den kettenübergreifenden Absichtsausdruck benötigen. Jedes Team arbeitet an seinen eigenen Methoden und Protokollen zur Kodierung der Benutzerabsicht. Ein einheitlicher Standard wird das Verständnis der Benutzer für ihre signierten Nachrichten verbessern, es Lösern und Orakeln leichter machen, diese Absichten zu verstehen, und die Integration mit Wallets vereinfachen.

Token-bezeichnete Brücke

Es gibt einen Sonderfall von Lock-and-Mint-Brücken, die keine Liquiditätskosten zahlen, auch Burn-and-Mint-Brücken genannt (z. B. USDC CCTP). Das Token-Team weist jeder Kette eine kanonische Token-Adresse zu, und die Bridge hat die Befugnis, die vom Benutzer benötigten Token zu prägen.

Wenn Sie genau hinsehen, werden Sie feststellen, dass die Burn-and-Mint-Bridge einem Cross-Chain-Transfer mit ausreichender Blockbestätigungsgeschwindigkeit ähnelt. xERC 20 ist ein Standard zum Spezifizieren kanonischer Token und ihrer delegierten Brücken auf einer Zielkette. Token-spezifizierte Bridges sind ein Beispiel für einen protokollinternen Pfad, der Geschwindigkeit für garantierte Ausführung und niedrige Gebühren opfert, z. B. dauert CCTP 20 Minuten, um eine Übertragung abzuschließen.

Ökosystemkoordinationsbrücke

Die Ecosystem Coordination Bridge kann beliebige Nachrichten zwischen Ketten innerhalb desselben Ökosystems übertragen. Bei solchen Brücken handelt es sich um protokollinterne Pfade, bei denen Ausführungsgarantien und niedrige Gebühren Vorrang vor Geschwindigkeit haben. Beispiele hierfür sind Cosmos IBC, Polygon AggLayer und Optimism Superchain.

Vor drei Jahren stand das Cosmos-Ökosystem vor ähnlichen Herausforderungen wie Ethereum heute. Die Liquidität ist auf verschiedene Ketten verteilt, jede Kette hat ihren eigenen Gebühren-Token und die Verwaltung von Multi-Chain-Konten ist sehr umständlich. Das Cosmos-Ökosystem löst diese Probleme durch die Implementierung einer IBC-Intraprotokoll-Messaging-Brücke, die eine nahtlose Multi-Chain-Kontoverwaltung und kettenübergreifende Übertragungen ermöglicht.

Das Cosmos-Ökosystem besteht aus unabhängigen Ketten mit souveräner Sicherheit und schneller Endgültigkeit, wodurch die kettenübergreifende Nachrichtenübermittlung innerhalb des Protokolls sehr schnell erfolgt. Das Rollup-Ökosystem ist auf das Ende des Challenge-Zeitraums (optimistische Rollups) oder die Einreichung von ZK-Beweisen (Gültigkeits-Rollups) angewiesen, um die Endgültigkeit zu erreichen. Aufgrund dieser Endgültigkeitsbeschränkungen wird die Nachrichtenübermittlung im gesamten Ökosystem langsamer sein.

Solver-Preiswettbewerb

Der Solver-Preiswettbewerb beinhaltet den Austausch von Auftragsinformationen mit allen Solvern. Der Solver ist so konzipiert, dass er den durch die Bestellabsicht generierten Erwartungswert (EV) kombiniert und dem Benutzer bereitstellt. Die Auswahl des siegreichen Lösers im System basiert auf der Maximierung der Benutzerpreisverbesserung. Allerdings birgt diese Gestaltung das Risiko der Nichtausführung und erfordert zusätzliche Mechanismen zur Gewährleistung der Auftragszuverlässigkeit. Beispiele für solche Mechanismen sind Uniswap X, Bungee und Jumper.

Nachrichten zum Wallet-Abgleich

Wallet-Koordinierungsnachrichten nutzen die von AA oder richtlinienbasierten Wallets bereitgestellten Funktionen, um ein kettenübergreifendes Erlebnis zu bieten, das mit jedem Absichtstyp kompatibel ist. Es fungiert als ultimativer CA-Aggregator und leitet Benutzerabsichten zwischen verschiedenen CA-Designs um, um bestimmte Absichten zu berücksichtigen. Beispiele hierfür sind Avocado Wallet, Near Account Aggregator und Metamask Portfolio.

Es ist wichtig anzumerken, dass das Krypto-Ökosystem im Laufe des letzten Jahrzehnts gelernt hat, dass die Beziehung zwischen Benutzern und ihren Wallets sehr eng ist. Immer wenn ich darüber nachdenke, meine mnemonische Phrase von Metamask auf eine andere Wallet zu migrieren, verspüre ich große Angst. Dies ist auch der Grund, warum EIP-4337 auch mit der Unterstützung von Vitalik Buterin selbst nach 2,5 Jahren immer noch eine niedrige Akzeptanzrate aufweist. Obwohl neuere Versionen des Wallet-Protokolls Benutzern möglicherweise bessere Preise (Kontoabstraktion) oder eine verbesserte Benutzerfreundlichkeit (richtlinienbasierte Wallets) bieten, ist die Migration von Benutzern von ihren aktuellen Wallets eine entmutigende Aufgabe.

Solver-Geschwindigkeitswettbewerb

Der Solver-Geschwindigkeitswettbewerb ermöglicht es Benutzern, Absichten für bestimmte kettenübergreifende Transformationen zu äußern, um hohe Ausführungsgarantien zu erhalten. Es hilft Benutzern nicht dabei, Gebühren zu minimieren, sondern bietet einen zuverlässigen Kanal zur Abwicklung komplexer Transaktionen. Der erste Solver, der eine Absicht basierend auf den Block-Builder-Gebühren oder der Geschwindigkeit ausführt, wird diese Absicht gewinnen.

Das Design zielt darauf ab, hohe Einschlussraten zu erreichen, indem der vom Solver erfasste EV maximiert wird. Dies geht jedoch zu Lasten der Zentralisierung, da es auf einer komplexen Kapitalverwaltung im Ethereum-Mainnet oder einer Ausführung mit geringer Latenz auf L2 beruht.

Exklusive Sammelauktion

Bei einer exklusiven Batch-Auktion handelt es sich um eine Auktion für das ausschließliche Recht, den gesamten Auftragsfluss innerhalb eines Zeitfensters auszuführen. Da andere Solver die Aufträge nicht sehen können, bieten sie auf der Grundlage der prognostizierten Marktvolatilität und der durchschnittlichen Ausführungsqualität. Exklusive Batch-Auktionen basieren auf einem Fallback-Preis, um gute Nutzerpreise zu gewährleisten, und können daher nicht für Preisverbesserungen genutzt werden. Durch die Weiterleitung des gesamten Auftragsflusses an einen einzigen Bieter werden Informationslecks vermieden und die Ausführungssicherheit verbessert.

abschließend

Das Chain Abstraction Framework (CAF) verspricht, Benutzern nahtlose kettenübergreifende Interaktionen zu ermöglichen. In diesem Artikel untersuchen wir Entwürfe in Produktion und Entwicklung durch mehrere Teams, die explizit oder implizit versuchen, das Kettenabstraktionsproblem zu lösen. Wir glauben, dass dies das Jahr des CAF sein wird und erwarten, dass es in den nächsten 6 bis 12 Monaten zu einem erheblichen Wettbewerb zwischen verschiedenen Designs und deren Implementierungen kommen wird.

Kettenübergreifende Wertübertragungen werden durch token-delegiertes Bridging für niedrige Gebühren und schnelle Ausführung durch Lösergeschwindigkeit oder Preiswettbewerbe ermöglicht. Nachrichtenübertragungen werden über Messaging-Brücken geleitet, die zum Ökosystem passen und darauf ausgelegt sind, die Benutzerkosten zu minimieren und die Geschwindigkeit über eine Wallet-gesteuerte Plattform zu maximieren. Letztendlich bilden diese sechs verschiedenen Designoptionen einen Cluster, da sie jeweils unterschiedliche Anforderungen erfüllen und Effizienzvorteile in verschiedenen Bereichen der Kompromissmatrix nutzen.

Eine wichtige Schlussfolgerung, die wir aus diesem Prozess gezogen haben, ist, dass wir einen gemeinsamen Standard für die Darstellung kettenübergreifender Absichten benötigen. Derzeit arbeiten mehrere Teams unabhängig voneinander an Protokollen zur Kodierung der Benutzerabsichten, was zu Doppelarbeit führt. Ein einheitlicher Standard wird dazu beitragen, das Verständnis der Benutzer für signierte Nachrichten zu verbessern, Lösern und Orakeln die Verarbeitung von Absichten zu erleichtern und die Integration mit Wallets zu vereinfachen.

Ursprünglicher Link