TL; Dr

• Die Standard-Krypto-UX besteht heute darin, dass Benutzer immer wissen, mit welchem Netzwerk sie interagieren. Internetnutzer müssen jedoch nicht wissen, mit welchem Cloud-Anbieter sie interagieren. Diesen Ansatz auf Blockchains zu übertragen, nennen wir Chain-Abstraktion.
• Dieser Artikel stellt das CAKE Framework vor, dh Chain Abstraction Key Elements. Es besteht aus vier Schichten: Anwendungen, Berechtigungen, Lösung und Abrechnung, die zusammen nahtlose Cross-Chain-Operationen für Benutzer ermöglichen.
• Das Erreichen der Kettenabstraktion erfordert den Einsatz eines komplexen Satzes von Technologien, um eine zuverlässige, kosteneffiziente, sichere, schnelle und private Ausführung zu ermöglichen.
• Wir definieren den Cross-Chain Tradeoff-Raum in der Kettenabstraktion als Trilema und schlagen sechs Designs vor, die jeweils einzigartige Vorteile bieten.
• Um den Sprung in die Zukunft der Kettenabstraktion erfolgreich zu schaffen, ist es Order unerlässlich, dass wir als Branche einen gemeinsamen Standard für das Messaging zwischen den Schichten der CAKE definieren und übernehmen. Ein toller Standard ist das i-Tüpfelchen. 🎂

Einführung

Im Jahr 2020 wurde das Ethereum Netzwerk auf eine Rollup-zentrierte Roadmap für die Skalierung umgestellt. Vier Jahre nach dieser Entscheidung sind bereits mehr als 50 Rollups (L2s) in Produktion. Während Rollups die dringend benötigte horizontale Skalierung für den EVM Blockspace bieten, hat es die Benutzererfahrung völlig ruiniert.

Benutzer sollten sich weder darum kümmern noch wissen, mit welchem Rollup sie interagieren. Wenn Krypto-Benutzer wissen, mit welchem Rollup (Optimism oder Base) sie interagieren, ist dies gleichbedeutend mit Web2-Benutzern, die wissen, mit welchem Cloud-Anbieter (AWS oder GCP) sie interagieren. Kettenabstraktion ist eine Vision, bei der Ketteninformationen vom Benutzer abstrahiert werden. Der Benutzer verbindet nur seine Wallet mit einer dApp und signiert für den beabsichtigten Vorgang, die Details der Sicherstellung, dass der Benutzer das richtige Guthaben auf der Zielkette hat, und dann erfolgt die Ausführung der beabsichtigten Operation hinter den Kulissen.

Im Laufe dieses Artikels werden wir feststellen, dass die Kettenabstraktion ein wirklich multidisziplinäres Problem ist. Interaktionen mit der Anwendungs-Schicht, der Berechtigungsschicht, der Solver-Ebene und der Abrechnung. Wir stellen das Chain Abstraction Key Elements (CAKE 🎂) Framework vor und tauchen dann tiefer in die Design-Kompromisse von Kettenabstraktionssystemen ein.

Einführung in das CAKE Framework

In einer kettenabstrahierten Welt geht ein Benutzer auf eine dApps-Website, verbindet seine Wallet, signiert die beabsichtigte Operation und wartet auf eine eventuelle Abrechnung. Die gesamte Komplexität des Erwerbs der erforderlichen Vermögenswerte für die Zielkette und die endgültige Abrechnung wird vom Benutzer abstrahiert und geschieht in Infrastrukturschichten des CAKE. Es gibt drei Infrastrukturebenen des CAKE:

1. Berechtigungsebene: Der Benutzer verbindet seine Wallet mit einer dApp und fordert das Angebot für eine Benutzerabsicht an. Ein Intent ist das, was der Benutzer am Ende einer Transaktion erwartet (d. h. die Ausgabe) und nicht den letztendlichen Pfad, den die Transaktion nimmt. Es kann USDT an eine Tron-Adresse übertragen oder USDC in eine renditegenerierende Strategie auf Arbitrum einzahlen. Die Wallet sollte in der Lage sein, sowohl die Vermögenswerte des Benutzers zu kennen (d. h. den Lesestatus) als auch Transaktionen (d. h. den Status zu aktualisieren) auf Zielketten auszuführen.
2. Solver-Layer: Der Solver-Layer schätzt die Gebühren und die Ausführungsgeschwindigkeit basierend auf dem anfänglichen Guthaben und der Absicht des Benutzers. Dieser Prozess, der als Lösen bezeichnet wird, ist entscheidend in einer Cross-Chain-Umgebung, in der Transaktionen asynchron werden und Teiltransaktionen während der Ausführung fehlschlagen können. Die Einführung von Asynchronität schafft ein Cross-Chain Trilemma mit Gebühren, Ausführungsgeschwindigkeit und Ausführungsgarantie.
3. Abrechnung: Nachdem der Benutzer die Transaktion mit seinem privaten Schlüssel genehmigt hat, stellt die Abrechnungsebene die Ausführung sicher. Es umfasst zwei Schritte: das Überbrücken der Vermögenswerte des Benutzers in die Zielkette und das anschließende Ausführen der Transaktion. Wenn das Protokoll ausgeklügelte Solver für bestimmte Operationen verwendet, können sie ihre eigene Liquidität mitbringen und die Operation im Namen des Benutzers ausführen, ohne dass eine Überbrückung erforderlich ist.

Das Erreichen von Chain-Abstraktion bedeutet, die oben genannten drei Infrastrukturebenen zu einem einheitlichen Produkt zu kombinieren. Eine wichtige Erkenntnis bei der Kombination dieser Ebenen ist der Unterschied zwischen der Übertragung von Informationen und der Übertragung von Werten. Die Übertragung von Informationen zwischen Ketten sollte verlustfrei erfolgen und erfordert daher das Vertrauen in die sichersten Pfade. Angenommen, ein Benutzer versucht, bei einer Governance-Abstimmung von einer Kette zur anderen mit Ja abzustimmen, möchte er nicht, dass seine Stimme in ein "Vielleicht" umgewandelt wird. Auf der anderen Seite kann die Übertragung von Werten je nach Benutzerpräferenz verlustbehaftet sein. Ein ausgeklügelter Drittanbieter kann genutzt werden, um dem Benutzer einen schnelleren, billigeren oder garantierten Werttransfer zu ermöglichen. Beachten Sie, dass 95% des Ethereum-Blockspace (gewichtet nach den an die Prüfer gezahlten Gebühren) für die Übertragung von Werten verbraucht wird.

Key Design Decisions

Die oben genannten drei Ebenen stellen wichtige Designentscheidungen vor, die von einem CAF getroffen werden müssen. Sie beziehen sich darauf, wer die Macht über die Ausführung der Absicht kontrolliert, welche Informationen den Solvern offengelegt werden sollten und welche Abwicklungswege den Solvern zur Verfügung stehen. Schauen wir uns jeden von ihnen im Detail an.

Berechtigungsschicht

Die Berechtigungsschicht enthält den privaten Schlüssel für den Benutzer und signiert Nachrichten in seinem Namen, die dann on-chain als Transaktionen ausgeführt werden. Eine CAF muss Signaturschemata und Transaktionsnutzlasten für alle Zielketten Unterstützung, die sie Unterstützung möchte. Zum Beispiel wird eine Wallet, die das ECDSA Signing Scheme und den EVM Transaktionsstandard unterstützt, auf Ethereum, seine L2s und seine Sidechains (z. B. Metamask Wallet) beschränkt sein. Auf der anderen Seite kann eine Wallet, die sowohl EVM als auch SVM (Solana VM) unterstützt, beide Ökosysteme Unterstützung (z. B. Phantom-Wallet). Es ist wichtig zu beachten, dass dieselbe Eselsbrücke verwendet werden kann, um Wallets sowohl auf EVM als auch auf SVM-Chains zu generieren.

Eine einzelne Multi-Chain-Transaktion besteht aus mehreren Teiltransaktionen, die in der richtigen Order ausgeführt werden müssen. Diese Teiltransaktionen müssen auf mehreren Ketten ausgeführt werden, jede mit ihren eigenen zeitvariablen Gebühren und Nonce. Die Art und Weise, wie die Koordination und Abrechnung dieser Teiltransaktionen erfolgt, ist eine entscheidende Entwurfsentscheidung für die Berechtigungsschicht.

1. EOA-Wallets sind Wallet-Software, die auf den Computern der Benutzer ausgeführt wird und deren private Schlüssel enthält. Dabei kann es sich um browserbasierte Erweiterungen (wie Metamask und Phantom), mobile Apps (wie Coinbase Wallet) oder dedizierte Hardware (wie Ledger) handeln. EOA-Wallets erfordern, dass der Benutzer jede Teiltransaktion einzeln signiert, was derzeit mehrere Klicks erfordert. Sie verlangen auch, dass der Benutzer Gebührenguthaben auf der Zielkette hält, was zu erheblichen Reibungsverlusten führt. Die Reibung durch mehrere Klicks kann jedoch vom Benutzer abstrahiert werden, indem er mehrere Untertransaktionen mit einem einzigen Klick signieren kann.
2. In Account Abstraction (AA)-Wallets hat der Benutzer weiterhin Zugriff auf seinen privaten Schlüssel, aber sie trennen den Unterzeichner der Transaktionsnutzlast vom Executor der Transaktion. Ermöglicht es versierten Parteien, Benutzertransaktionen atomar zu bündeln und auszuführen (Avocado, Pimlico). AA-Wallets verlangen immer noch, dass der Benutzer jede Untertransaktion einzeln signiert (derzeit über mehrere Klicks), erfordert jedoch keine Gebührenguthaben auf jeder Chain.
3. Richtlinienbasierte Agenten halten den privaten Schlüssel des Benutzers in einer separaten Ausführungsumgebung und generieren signierte Nachrichten in seinem Namen auf der Grundlage von Benutzerrichtlinien. Telegram-Bots, Near-Account-Aggregator oder SUAVE-TEEs sind richtlinienbasierte Wallets, während Entropy oder Capsule richtlinienbasierte Wallet-Erweiterungen sind. Der Benutzer muss nur eine einzige Genehmigung unterschreiben, und die anschließende Unterzeichnung von Untertransaktionen und die Gebührenverwaltung können von diesen Agenten während der Fahrt durchgeführt werden.

Solver-Layer

Sobald ein Benutzer seine Absicht gepostet hat, werden in der Lösungsebene eine Gebühr und eine Bestätigungszeit an den Benutzer zurückgegeben. Dieses Problem steht in engem Zusammenhang mit dem Entwerfen einer Order Flow Auction und wurde ausführlich beschrieben hier. Ein CAF kann entweder In-Protokoll-Pfade nutzen, um die Absicht eines Benutzers auszuführen, oder ausgeklügelte Drittanbieter, auch bekannt als Solver, nutzen, um dem Benutzer eine verbesserte UX zu bieten, indem einige Sicherheitsgarantien beeinträchtigt werden. Die nächsten beiden Entwurfsentscheidungen ergeben sich, wenn wir Solver in ein CAF-Framework einbinden, und beziehen sich auf Informationen.

Ein Intent besteht aus zwei Arten von extrahierbaren Werten (EV): EV_ordering und EV_signal. EV_ordering ist ein Blockchain-spezifischer Wert, der in der Regel von Entitäten extrahiert wird, die Benutzeraufträge ausführen, wie Blockbuilder oder Prüfer. Auf der anderen Seite stellt EV_signal den Wert dar, der jeder Entität zugänglich ist, die die Order beachtet, bevor sie offiziell in der Blockchain aufgezeichnet wird.

Unterschiedliche Nutzerabsichten haben unterschiedliche Verteilungen zwischen EV_ordering und EV_signal. Zum Beispiel hat die Absicht, Münzen auf einem DEX zu tauschen, in der Regel eine hohe EV_ordering, aber eine niedrige EV_signal. Umgekehrt hat eine eingehende Hack-Transaktion eine höhere Komponente von EV_signal, da sie beim Front-Running deutlich mehr Wert zurückgibt als bei der Ausführung. Es ist wichtig zu beachten, dass EV_signal manchmal negativ sein kann, z. B. im Fall von Trades von Market Makern, bei denen Unternehmen, die diese Aufträge ausführen, Verluste erleiden können, da ein Market Maker die zukünftigen Marktbedingungen besser versteht.

Wenn jemand die Möglichkeit hat, die Absicht eines Benutzers im Voraus zu beobachten, kann er sich auf Front-Running einlassen, was zu Wertverlusten führt. Darüber hinaus schafft das Potenzial, dass EV_signal negativ sind, ein Wettbewerbsumfeld unter den Solvern, was dazu führt, dass sie niedrigere Gebote abgeben und zu weiteren Wertverlusten (auch bekannt als adverse selection) führen. Letztendlich wirken sich Leckagen auf den Benutzer aus, indem sie entweder die Gebühren erhöhen oder ungünstigere Preise anbieten. Beachten Sie, dass niedrige Gebühren oder Preisverbesserungen zwei Seiten derselben Coin sind und im Rest des Artikels austauschbar verwendet werden.

Informationsaustausch

Es gibt 3 Methoden, um Informationen mit Solvern zu teilen:

1. Öffentlicher Mempool: Die Absicht des Benutzers wird öffentlich übertragen, entweder in einen öffentlichen Mempool oder eine DA-Schicht. Der erste Solver, der die Anforderung erfüllen kann, führt den Order aus und wird zum Gewinner. Dieses System ist hochgradig extraktiv, da die Benutzer sowohl die EV_ordering als auch die EV_signal ihrer Order offenlegen. Beispiele für diese Art von Auktion sind der öffentliche Mempool von Ethereum und verschiedene Blockchain-Bridges. Im Falle von Bridges müssen die Nutzer ihre Assets als Vorsichtsmaßnahme gegen Trauerattacken auf ein Treuhandkonto legen, bevor sie sie in die Zielkette übertragen. Dieser Prozess entlarvt jedoch unbeabsichtigt ihre Absichten in der Öffentlichkeit.
2. Teilweise Teilung: Ein CAF kann sich dafür entscheiden, die Höhe des Werts, den es den Bietern offenlegt, zu begrenzen, indem es die offengelegten Informationen begrenzt. Dieser Ansatz führt jedoch zu einem direkten Verlust der Preisoptimalität und kann zu anderen Problemen führen, wie z. B. Bid-Spamming.
3. Private mempool: Die jüngsten Entwicklungen bei MPC und TEEs eröffnen die Möglichkeit, vollständig private Mempools zu realisieren. Es werden keine Informationen außerhalb der Ausführungsumgebung durchgesickert, sodass die Solver ihre Einstellungen kodieren, die mit jeder Absicht abgeglichen werden. Obwohl private mempool EV_ordering erfasst, kann sie den Wert in EV_signal nicht vollständig erfassen. Stellen Sie sich vor, was passiert, wenn eine Hack-Transaktion an den Mempool gesendet wird. Die erste Person, die diese Order sieht, kann den potenziellen Verkauf vorziehen und EV_signal erfassen. In einem privaten mempool werden die Informationen erst freigegeben, nachdem eine Sperre bestätigt wurde, und daher kann jeder, der die Transaktion sehen kann, die EV_signal erfassen. Man kann sich vorstellen, dass Löser Beglaubigung Knoten hochdrehen, um EV_signal aus frischen Blöcken zu fangen, die von einem TEE geprägt wurden, und EV_signal Eroberung in ein Latenzzeit Rennen verwandeln.

Solver-Liste

Die CAF muss auch entscheiden, wie viele und welche Bieter an der Auktion teilnehmen dürfen. Im Großen und Ganzen gibt es folgende Optionen:

• Open Access: Die Eintrittsbarrieren für die Möglichkeit zur Teilnahme sind so niedrig wie möglich. Dies ähnelt einer öffentlichen mempool und leakt sowohl EV_signal als auch EV_ordering.
• Gated Access: Es gibt ein gewisses Gatekeeping für die Möglichkeit, eine Order auszuführen, entweder durch eine Whitelist, ein Reputationssystem, eine Gebühr oder eine Sitzauktion. Der Gatekeeping-Mechanismus muss sicherstellen, dass Solver im System keine EV_signal erfassen. Beispiele sind 1inch Auction, Cowswap Auctions und Uniswap X Auctions. Der Wettbewerb um den Gewinn von Aufträgen erfasst EV_ordering für den Benutzer, während der Gating-Mechanismus die EV_signal für den Order Generator (Wallet, dApps) erfassen kann.
• Exklusiver Zugriff: Der exklusive Zugriff ist ein Sonderfall der sitzenden Solver-Auktion, bei der pro Zeitraum nur ein Solver ausgewählt wird. Da keine Informationen an andere Solver weitergegeben werden, gibt es keine nachteilige Selektion und keinen Front-Running-Rabatt. Der Orderflow-Originator erfasst den Erwartungswert von EV_signal und EV_ordering, da es keinen Wettbewerb gibt, kann der Benutzer nur die Ausführung und keine Preisverbesserung erhalten. Einige Beispiele für diese Auktionen sind die Robinhood- und DFlow-Auktionen.

Abrechnung Schicht

Sobald eine Wallet eine Reihe von Transaktionen signiert hat, müssen diese auf der Blockchain ausgeführt werden. Cross-Chain-Transaktionen wandeln den Abwicklungsprozess von atomar in asynchron um. Während die ersten Transaktionen ausgeführt und bestätigt werden, kann sich der Status in der Zielkette ändern, was möglicherweise zu Transaktionsfehlern führt. In diesem Unterabschnitt werden die Kompromisse zwischen den Kosten für Sicherheit, Bestätigungszeit und Ausführungsgarantie untersucht.

Es ist wichtig zu beachten, dass die Ausführung der beabsichtigten Transaktion auf der Zielkette von der Transaktionseinschlussmechanik der Zielkette abhängt. Dazu gehören unter anderem die Möglichkeit, eine Transaktion zu zensieren, und der Gebührenmechanismus der Zielkette. Wir glauben, dass die Wahl der Zielkette eine Entscheidung für die dApp ist und werden sie über den Rahmen dieses Artikels hinaus berücksichtigen.

Cross-Chain Oracle

Zwei Blockchains mit unterschiedlichen Zuständen und Konsensmechanismen benötigen ein Mittelsmann, z. B. ein Oracle, um den Informationsaustausch zwischen ihnen zu erleichtern. Orakel dienen als Relais für Informationen zwischen Ketten. Dazu gehört die Überprüfung von Situationen, wie z. B. das Sperren von Geldern in einem Treuhandkonto Konto für ein Sperren und Mint' Bridge' oder das Bestätigen des Token-Guthabens eines Benutzers in der Ursprungskette für die Teilnahme an Governance-Abstimmungen in der Zielkette.

Orakel übertragen Informationen zwischen Ketten mit der Geschwindigkeit der langsamsten Kette. Dies ist notwendig, um das Reorg-Risiko zu managen, da das Oracle auf einen Konsens über die Ursprungskette warten muss. Betrachten wir ein Szenario, in dem ein Benutzer von der Ursprungskette zur Zielkette Bridge' USDC möchte. Zu diesem Zweck sperrt der Benutzer sein Geld in einem Treuhandkonto. Wenn das Oracle jedoch nicht auf genügend Bestätigungen wartet und mit der Mint' von Token für den Benutzer auf der Zielkette fortfährt, kann ein Problem auftreten. Wenn der Benutzer im Falle einer Neuorganisation seine Treuhandtransaktion überschreibt, hat das Oracle doppelte Ausgaben.

Es gibt zwei Arten von Orakeln:

1. Out-of-Protocol Oracle benötigt Prüfer von Drittanbietern, die von denen getrennt sind, die den Konsens ausführen, um Informationen zwischen Ketten zu übertragen. Der Bedarf an zusätzlichen Prüfern erhöht die Kosten für den Betrieb des Oracle. LayerZero, Wormhole, ChainLink und Axelar Network sind Beispiele für Out-of-Protocol-Orakel.
2. Ein In-Protocol-Oracle ist tief in den Konsensalgorithmus eines Ökosystems integriert und verwendet das Validator-Set, das den Konsens ausführt, um Informationen zu übertragen. Cosmos hat IBC für Chains, auf denen das Cosmos SDK läuft, das Polygon-Ökosystem arbeitet an AggLayer, während Optimism an der Superchain arbeitet. Jedes Orakel verwendet dedizierten Blockspace, um Informationen zwischen Ketten desselben Ökosystems zu übertragen.
3. Shared Sequencer sind Out-of-Protokoll-Entitäten, die Transaktionsreihenfolgerechte im Protokoll haben, d.h. sie können Transaktionen über Ketten hinweg bündeln. Obwohl sich Shared Sequencer noch in der Entwicklung befinden, müssen sie nicht auf bestimmte Blockbestätigungen warten, um das Reorganisationsrisiko zu verringern. Um wirklich Cross-Chain Atomizität zu bieten, müssen gemeinsam genutzte Sequenzer in der Lage sein, nachfolgende Transaktionen auszuführen, die vom Erfolg früherer Transaktionen abhängig sind und sie in eine Kette von Ketten verwandeln.

Bridging Token

In einer Multi-Chain-Welt sind die Token- und Gebührensalden der Nutzer über alle Netzwerke verteilt. Vor jeder Cross-Chain Operation muss der Benutzer eine Bridge' von der Ursprungskette zur Zielkette schlagen. Derzeit gibt es 34 aktive Bridges mit einem kombinierten TVL von 7,7 Mrd. $ und einem Überbrückungswert von Volumen von 8,6 Mrd. $ in den letzten 30 Tagen.

Das Überbrücken von Token ist ein Fall von Wertübertragung. Dies schafft die Möglichkeit, spezialisierte Dritte zu beauftragen, die sich im Kapitalmanagement auszeichnen und bereit sind, das Reorganisationsrisiko zu übernehmen, wodurch die Kosten und der Zeitaufwand für Benutzertransaktionen reduziert werden.

Es gibt 2 Arten von Brücken:

1. Lock and Mint Bridge': Ein Lock-and-Mint' Bridge' verifiziert Token-Einzahlungen auf der Ursprungskette und prägt Token auf der Zielkette. Während für den Start einer solchen Bridge' ein geringes Kapital erforderlich ist, sind erhebliche Investitionen für die sichere Übertragung von Schließinformationen zwischen Ketten erforderlich. Sicherheitslücken in diesen Brücken haben zu Verlusten in Milliardenhöhe für die Token-Inhaber geführt.
2. Liquiditätsbrücken: Liquiditätsbrücken nutzen Liquiditätspools für Ursprungs- und Zielketten sowie einen Algorithmus zur Bestimmung der Umrechnungsraten zwischen den Ursprungs- und Zieltoken. Diese Brücken haben zwar höhere Anschaffungskosten, erfordern aber geringere Sicherheitsgarantien. Im Falle einer Sicherheitsverletzung sind nur die Gelder in den Liquiditätspools gefährdet.

Bei beiden Arten von Brücken fallen Liquiditätskosten an, die vom Nutzer bezahlt werden müssen. Bei Lock- und Mint-Brücken sind die Liquiditätskosten beim Wechsel vom gewickelten Token zum gewünschten Token (USDC.e zu USDC) auf der Zielkette, während bei Liquiditätsbrücken die Liquiditätskosten beim Wechsel vom Token auf der Ursprungskette zum Token auf der Zielkette liegen.

Cross-Chain-Trilemma

Die obigen 5 Designentscheidungen geben dem cross-chain Trilemma Aufstieg. Ein CAF muss sich für 2 Eigenschaften entscheiden: Ausführungsgarantie, niedrige Gebühren und Ausführungsgeschwindigkeit.

1. In-Protokoll-Pfade sind festgelegte Pfade für die Übertragung von Informationen über Ketten hinweg. Diese Konten für die Reorganisation bergen das Risiko, die Ausführungsgeschwindigkeit zu beeinträchtigen, reduzieren jedoch die Kosten, indem sie die Notwendigkeit eines zusätzlichen Validator-Sets oder der Liquiditätskosten eliminieren.
2. Die Solver-Aggregation sammelt Angebote von mehreren Solvers, um den günstigsten und schnellsten Weg zur Erfüllung der Absicht eines Benutzers zu ermitteln. Aufgrund von ungünstiger Selektion und Front-Running kann es jedoch vorkommen, dass Solver die Absicht nicht erfüllen, was zu einer reduzierten Ausführung führt.
3. Beim Ausführungswettbewerb wird ein erfolgreicher Solver ausgewählt, indem entweder ein Wettlauf zwischen den Solvern zur Ausführung eines Intent angeordnet wird oder ein einzelner Solver exklusiv ausgewählt wird. Beide Ansätze führen zu hohen Gebühren für den Benutzer, da die Solver eher um die Ausführung als um die Preisverbesserung konkurrieren.

The Six Pieces Of CAKE

Um diesen Artikel zu schreiben, haben wir mehr als 20 verschiedene Designs von Teams untersucht, die sowohl explizit als auch implizit 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. Diese Designs haben das Potenzial, miteinander komponiert zu werden, wenn sie richtig aufgebaut sind.

Eine wichtige Erkenntnis aus dieser Übung ist, dass wir einen gemeinsamen Standard für den Ausdruck von Cross-Chain-Absichten benötigen. Jedes der Teams arbeitet an seinen eigenen Methoden und Protokollen für die Codierung von Benutzerabsichten. Die Vereinheitlichung hin zu einem Standard verbessert das Verständnis der Benutzer für die von ihnen signierte Nachricht, erleichtert es Solvern und Orakeln, diese Absichten zu verstehen, und vereinfacht die Integration mit Wallets.

Token Gesalbte Brücken

Auf das Ökosystem abgestimmte Bridge'

Solver-Preiswettbewerb

Wallet gesteuertes Messaging

Solver-Geschwindigkeitswettbewerb

Exklusive Batch-Auktionen

Zweck

Günstige Cross-Chain-Überweisungen

Cross-Chain-Nachrichtenaufruf

Günstige Cross-Chain-Swaps

Cross-Chain-Nachrichtenaufruf

Schnelle Cross-Chain-Übertragungen

Cross-Chain-Nachrichtenaufruf

Beispiele

CCTP, CCIP, xERC20

AggLayer, Superchain, IBC

Bungee, Jumper, Uniswap X

Alfred, Avocado, in der Nähe des Kontos

Quer, Orbiter

Na

Brieftasche

jegliche

jegliche

Hängt von der Implementierung ab

AA oder richtlinienbasiert

jegliche

jegliche

Weitergegebene Informationen

Öffentlich

Öffentlich

Hängt von der Implementierung ab

Hängt von der Implementierung ab

Alle oder keine

nichts

Liste "Solver"

Hängt von der Implementierung ab

Hängt von der Implementierung ab

Geschlossener Zugang

Hängt von der Implementierung ab

Hängt von der Implementierung ab

ausschließlich

Orakel

Im Protokoll

Im Protokoll

Außerhalb des Protokolls

Außerhalb des Protokolls

Außerhalb des Protokolls

Außerhalb des Protokolls

Token Bridging

Burn und Mint'

Schloss und Mint'

Abhängig vom Solver

Abhängig vom Solver

Liquidität Bridge'

Hängt von der Implementierung ab

Token Gesalbte Brücken

Es gibt einen Sonderfall von Sperre und Mint' Bridge', der die Liquiditätskosten nicht zahlt, auch als Burn und Mint' Bridge' bezeichnet (z. USDC CCTP). Das Token-Team salbt eine kanonische Token-Adresse auf jeder Kette, während die Bridge' die Befugnis hat, den Token zu Mint', d.h. den Token, den der Benutzer benötigt, zu prägen.

Wenn Sie die Augen fest genug zusammenkneifen, ist ein Burn and Mint' Bridge' vergleichbar mit einer cross-chain-Übertragung mit der Geschwindigkeit von genügend Blockbestätigungen. xERC20 ist ein solcher Standard, um kanonische Token und ihre autorisierten Bridges auf Zielketten zu salben. Eine Token-gesalbte Bridge' ist ein Beispiel für einen In-Protokoll-Pfad, dh sie geht Kompromisse bei der Geschwindigkeit für die Ausführungsgarantie und niedrige Gebühren ein, z. B. CCTP benötigt 20 Minuten, um eine Übertragung auszuführen.

Ecosystem Aligned Bridge

Eine auf das Ökosystem abgestimmte Bridge' ermöglicht die Übertragung beliebiger Nachrichten zwischen Ketten innerhalb desselben Ökosystems. Es fällt unter die Kategorie der In-Protokoll-Pfade, die der Ausführungsgarantie und niedrigen Gebühren Vorrang vor der Geschwindigkeit geben. 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 war über Ketten hinweg fragmentiert, jede Kette hatte ihren eigenen Gebühren-Token und die Verwaltung von Multi-Chain-Konten war umständlich. Das Cosmos-Ökosystem löste diese Probleme durch die Implementierung von In-Protokoll Message-Passing Bridges über IBC, was zu nahtlosen Multi-Chain-Konten und cross-chain Transfers führte.

Das Kosmos-Ökosystem besteht aus unabhängigen Ketten mit souveräner Sicherheit und schneller Endgültigkeit, wodurch der Protokoll-Pfad für Cross-Chain Messaging sehr schnell ist. Auf der anderen Seite hängt das Rollup-Ökosystem vom Ablauf des Challenge-Zeitraums ab (Optimistic Rollups) oder dem Commit von zk-proofs (Validity Rollups) für die Finalität. In-Protokoll-Pfade für die Übertragung von Nachrichten über Ökosysteme hinweg sind aufgrund dieser Finalitätseinschränkungen langsam.

Solver-Preiswettbewerb

Bei einem Solver-Preiswettbewerb werden Order Informationen mit allen Solvern geteilt. Solver zielen darauf ab, den Erwartungswert (EV), der durch die Absicht des Order generiert wird, einzubeziehen und den Benutzern zur Verfügung zu stellen. Die Auswahl des Gewinner-Solvers im System basiert auf der Maximierung der Verbesserung des Benutzerpreises. Dieses Design birgt jedoch das Risiko der Nichtausführung und erfordert zusätzliche Mechanismen, um die zuverlässige Einbeziehung von Aufträgen zu gewährleisten. Beispiele für solche Mechanismen sind Uniswap X, Bungee und Jumper.

Wallet Koordinierte Nachrichten

Wallet koordiniertes Messaging nutzen die Funktionen von AA oder richtlinienbasierten Wallets, um ein cross-chain Erlebnis zu bieten, das mit jedem Intent-Typ kompatibel ist. Es dient als ultimativer CA-Aggregator, der Benutzerabsichten zwischen verschiedenen CA-Designs umleitet, um bestimmte Absichten zu berücksichtigen. Beispiele hierfür sind Avocado Wallet, Near Account Aggregator und Metamask Portfolio.

Beachten Sie, dass das Krypto-Ökosystem in den letzten zehn Jahren gelernt hat, dass die Beziehung zwischen einem Benutzer und seiner Wallet sehr klebrig ist. Ich persönlich verspüre eine tödliche Angst, wenn ich daran denke, meine Eselsbrücke von Metamask auf eine andere Wallet zu migrieren. Dies ist auch der Grund, warum EIP-4337 auch nach 2,5 Jahren und mit Unterstützung von Vitalik Buterin selbst minimale Akzeptanz gefunden hat. Obwohl neuere Versionen von Wallet-Protokollen dem Benutzer einen besseren Preis (Kontoabstraktion) oder eine verbesserte Benutzerfreundlichkeit (richtlinienbasierte Wallets) bieten können, ist die Migration des Benutzers von seinen aktuellen Wallets eine schwierige Aufgabe.

Solver-Speed-Wettbewerb

Der Solver-Geschwindigkeitswettbewerb ermöglicht es Benutzern, ihre Absichten für bestimmte cross-chain Übergänge für hohe Ausführungsgarantien auszudrücken. Es hilft den Benutzern nicht bei der Minimierung von Gebühren, sondern bietet stattdessen einen zuverlässigen Kanal für die Einbeziehung komplexer Transaktionen. Der erste Solver, der die Absicht basierend auf den Gebühren für den Blockersteller oder der Einschlussgeschwindigkeit ausführt, gewinnt die Absicht.

Das Design zielt darauf ab, eine hohe Einschlussrate zu erreichen, indem die von Solvern erfasste EV maximiert wird. Dies geht jedoch auf Kosten der Zentralisierung, da es auf ein ausgeklügeltes Kapitalmanagement im Ethereum Mainnet oder eine Ausführung mit geringer Latenzzeit auf L2s angewiesen ist.

Exklusive Batch-Auktionen

Eine exklusive Batch-Auktion enthält eine Auktion für die exklusiven Rechte zum Ausführen des gesamten Order Flows in einem Zeitfenster für einen einzelnen Solver. Da andere Solver die Aufträge nicht sehen können, geben sie das Gebot auf der Grundlage der prognostizierten Marktvolatilität und ihrer durchschnittlichen Ausführungsqualität ab. Exklusive Batch-Auktionen hängen von einem Backstop in Order ab, um gute Benutzerpreise zu gewährleisten, und können daher nicht zur Preisverbesserung verwendet werden. Das Senden des gesamten Auftragsflusses an einen einzigen Order eliminiert Informationslecks und verbessert die Ausführungsgarantien.

Fazit

Chain Abstraction Frameworks (CAFs) versprechen eine nahtlose cross-chain Interaktion mit Benutzern. In diesem Artikel haben wir Entwürfe in der Produktion und in der Entwicklung von mehreren Teams untersucht, die explizit oder implizit versuchen, eine Lösung für die Kettenabstraktion zu finden. Wir glauben, dass dies das Jahr der CAFs sein wird und erwarten in den nächsten 6 bis 12 Monaten einen erheblichen Wettbewerb zwischen verschiedenen Designs und deren Implementierungen.

Wertübertragung

Informationsvermittlung

Pfade im Protokoll

Token-gesalbte Bridge'

Auf das Ökosystem abgestimmte Bridge'

Solver-Aggregation

Solver-Preiswettbewerb

Koordiniertes Wallet Messaging

Ausführungswettbewerb

Solver-Geschwindigkeitswettbewerb

Exklusive Batch-Auktionen

Cross-Chain-Werttransfers werden über eine Kombination aus Token-gesalbten Bridges für niedrige Gebühren und Solver-Speed- oder Preiswettbewerben für Geschwindigkeit und Ausführung geleitet. Während die Informationsübertragungen über eine Kombination aus auf das Ökosystem abgestimmten Nachrichtenbrücken geleitet werden, die darauf abzielen, die Kosten für die Benutzer zu minimieren, und über die von der Brieftasche kontrollierten Plattformen, die die Geschwindigkeit maximieren. Die endgültigen Implementierungen werden sich um diese sechs unterschiedlichen Designs gruppieren, da sie jeweils unabhängige Anforderungen erfüllen und von Effizienzsteigerungen profitieren, die in verschiedenen Ecken der Tradeoff-Matrix bestehen.

Eine wichtige Erkenntnis aus dieser Übung ist, dass wir einen gemeinsamen Standard für den Ausdruck von Cross-Chain-Absichten benötigen. Mehrere Teams arbeiten an ihren individuellen Protokollen für die Codierung von Benutzerabsichten, die zu doppelter Arbeit führen. Die Vereinheitlichung hin zu einem Standard verbessert das Verständnis der Benutzer für die Nachricht, die sie signieren, erleichtert es Solvern und Orakeln, mit Absichten zu arbeiten, und vereinfacht die Integration mit Wallets.

Haftungsausschluss:

1. Dieser Artikel wurde von [Medium] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [Favorite Mirror Reads Archive]. Wenn es Einwände gegen diesen Nachdruck gibt, 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.