Agenda

Das Problem

1. Definieren des Endzustands: Was macht Krypto-Anwendungen "benutzbar"

2. Warum „Chain-Abstraktion“ eine Lösung für ein UX-Problem ist, das aus der grundlegenden Topologie modularer Blockchains entsteht

3. Warum nutzbare Krypto-Anwendungen auf der Grundlage von Chain-Abstraktionsinfrastruktur aufgebaut werden müssen

Der Lösungsraum

1. Wie absichtsbasierte Architektur zu Kettenabstraktion führen wird

2. Verstehen, dass Absichtsmärkte am besten funktionieren, wenn das Lösernetzwerk groß und wettbewerbsfähig ist

3. Das Bootstrapping des Intent-Solver-Netzwerks erfordert die Integration weiterer Anwendungen, die Absichten erzeugen werden

Der Vorschlag

1. Warum wir einen Cross-Chain-Intents-Standard benötigen, der die „Löser-UX“ priorisiert, um den Löser- und Intents-Marktplatz in ausreichend großem Maßstab zu wachsen und Netzwerkeffekte zu erzielen

Verwendbare Kryptoanwendungen können ohne Kettenabstraktion nicht erstellt werden

Bauen unsere Besten und Klügsten überflüssige Infrastrukturen?

Viele haben sich darüber beklagt, dass die besten Krypto-Ingenieure und die meisten darauf basierenden Denker zu viel Aufmerksamkeit und Energie darauf verwenden, den Endnutzern mehr Blockspace zu bieten. Diese Kritik hat ihre Berechtigung; Es stehen zu viele L2 für Endbenutzer im Verhältnis zur Nachfrage nach ihnen zur Verfügung.

Allerdings lehne ich die Vorstellung ab, dass es keine nützlichen Krypto-Anwendungen gibt.

Dezentralisierte Finanzen bieten Einzelpersonen die Möglichkeit, digitale Vermögenswerte selbst zu verwahren, was es ihnen ermöglicht, um drakonische Dienstleister herumzuarbeiten und ihre digitalen Vermögenswerte zu nutzen, um Dinge von Wert in der realen Welt zu kaufen. Das Versprechen der selbstverwalteten Daten bietet auch eine utopische Alternative für Einzelpersonen, die zunehmend misstrauisch gegenüber FAANG-Monopolen werden, um ihre Daten sicher aufzubewahren.

Das eigentliche Problem meiner Meinung nach ist nicht der Mangel an nützlichen Krypto-Anwendungen, sondern die Reibung für Endbenutzer, die versuchen, auf sie zuzugreifen. Endbenutzer sollten folgendes erleben können, wenn sie mit Krypto-Anwendungen interagieren:

1. Geschwindigkeit: Anwendungen sollten so schnell wie Web2-Anwendungen sein.
2. Kosten: Im Gegensatz zu Web2 müssen alle Web3-Interaktionen mit Kosten verbunden sein, aber der "Kosten pro Klick" sollte vernachlässigbar sein.
3. Zensurresistenz („Berechtigungslosigkeit“): Jeder mit einer Brieftasche sollte in der Lage sein, mit der Anwendung zu interagieren, wenn er es sich leisten kann, darauf zu klicken.
4. Sicherheit: Klicks sollten das tun, was Benutzer von ihnen erwarten, und nicht zurückkehren - alle Web3-Updates sollten dauerhaft sein.

Dies sind die Eigenschaften von "verwendbaren" Krypto-Anwendungen.

Wir versuchen seit langem, eine nutzbare Kryptowährung zu entwickeln

Die heutigen modularen Blockchain-Lösungen bieten Verbrauchern all diese Eigenschaften, aber sie sind nicht alle am selben Ort verfügbar.

Im Jahr 2020 waren Blockchains monolithisch und boten den Endbenutzern zwei von drei Eigenschaften: Geschwindigkeit, Kosten oder Sicherheit. Dann haben wir uns vorgestellt, Rollup-zentrische oder modulare Zukunftdas alle drei Eigenschaften gleichzeitig entsperren würde.

Heute haben wir die Grundlage für diese rollup-zentrierte Infrastruktur geschaffen. L2s bieten günstigen und schnellen Blockspace, und die meisten von ihnen bieten blockspace ohne Genehmigung. Im Gegensatz dazu bietet L1 WW3-resistenten, sicheren Blockspace. (Sie können mehr über den Sicherheits-UX-Kompromiss, den L1s und L2s bieten, inmein kurzer Umfrageartikel). Diese L2s verbinden sich sicher mit L1 über kanonische Nachrichtenpfade und legen damit den Grundstein für ein modulares, aber dennoch interoperables Netzwerk. In den letzten vier Jahren haben wir die Glasfaser zwischen Blockchains aufgebaut, die eines Tages nützliche Kryptoanwendungen unterstützen wird. Aber warum sind modulare Blockchains so unbrauchbar?

Die Unvermeidlichkeit modularer Blockchain-Netzwerke besteht darin, dass Kapitalanlagen in den sichersten Schichten anfallen, während Benutzerklicks in den schnelleren und kostengünstigeren Schichten anfallen werden.

Modulare Blockchain-Topologie fördert sicheren Blockspace, der auf einer anderen Ebene als günstiger und schneller Blockspace angeboten wird. Benutzer werden natürlich bevorzugen, ihren Wert auf den sichersten Netzwerken zu speichern, aber sie werden am häufigsten mit den günstigen und schnellen Netzwerken interagieren wollen.Absichtlich, die kanonischen Pfade zwischen L2s und L1 sind langsam und/oder teuer. Diese Phänomene erklären, warum Benutzer diese kanonischen Pfade durchlaufen müssen, um für L2-Interaktionen mit L1-Vermögenswerten zu bezahlen. Dies führt zu einer „unbenutzbaren“ Krypto-UX.

Vitalik zu verschiedenen Arten von L2s

Das Ziel der Kettenabstraktion besteht darin, die Reibung beim Senden von Wert über diese in-Protokoll-Pfade vom Benutzer weg zu reduzieren.KettenabstraktorenIch gehe davon aus, dass Benutzer es vorziehen, ihre gewünschten Endzustände für Dapps als "Absichten" anzugeben, und es ist die Verantwortung der Dapp, ihre Absichten zu erfüllen. Benutzer sollten nicht die sichere Verwahrung ihrer Vermögenswerte gefährden müssen, um niedrige Gebühren und geringe Latenzzeiten zu nutzen.

Daher, Kettenabstraktionhängt entscheidend davon ab, dass Benutzer in der Lage sind, Werte sicher, günstig und schnell über Netzwerke zu übertragen. Ein üblicher Benutzerfluss heute ist, dass ein Benutzer mit einem USDC-Guthaben auf einer „sicheren“ Kette wie Ethereum ein NFT prägen oder gegen neue Token auf einer neueren Kette wie Blast oder Base tauschen möchte. Der Weg, dies in so wenigen Schritten wie möglich zu tun, besteht darin, eine Brücke→Tausch→Prägung-Serie von Transaktionen (oder Tausch→Brücke→Prägung) sequenziell auszuführen.

In diesem Beispiel beabsichtigt der Benutzer, seine USDC auf der sicheren Kette zu verwenden, um ein NFT auf einer anderen Kette zu prägen. Der Benutzer wird zufrieden sein, solange er das NFT erhält und sein USDC-Guthaben dort belastet wird, wo er es verwahren möchte.

Intent-Based Architecture ist der einzige Weg, um eine Kettenabstraktion aufzubauen

Kettenabstraktion basiert auf dem Transfer von Werten zwischen verschiedenen Blockchains, jedoch sind die Übertragung von Werten über herkömmliche Nachrichtenwege entweder teuer oder langsam. „Schnelle Brücken“ bieten günstige und schnelle Alternativen für Benutzer, um Werte zwischen Netzwerken zu übertragen, führen jedoch neue Vertrauensannahmen ein. Die Nachrichtenübermittlung ist der intuitivste Weg, um eine schnelle Brücke zu bauen, da sie auf der TCP/IP-Architektur basiert; sie setzt ein Brückenprotokoll voraus, das als TCP-Router fungiert, um zwei Blockchains zu verbinden.

TCP/IP-Diagramm von ResearchGate

Der Wertetransfer über die Nachrichtenübermittlung beinhaltet, dass das Bridge-Protokoll Nachrichten zwischen seinen Verträgen auf den Ursprungs- und Zielketten sendet. Diese Nachricht wird auf der Ursprungsseite durch eine Benutzertransaktion ausgelöst und wird auf die Zielseite weitergeleitet, sobald die "Gültigkeit" der Nachricht überprüft wurde.

Eine Nachricht kann erst nach Abschluss der Ursprungs-Chain-Transaktion, die die Nachricht initiiert hat, überprüft werden, was bedeutet, dass die Transaktion dauerhaft in der kanonischen Blockchain der Ursprungs-Chain enthalten ist. Diese Überprüfung kann als Gültigkeitsnachweis abgeschlossen werden, der die Konsens-Einbindung der Transaktion in der Ursprungs-Chain nachweist, als optimistischer Vorschlag oder nachdem eine Schwelle von Zeugenunterschriften erreicht ist, die ihre Einbeziehung auf der Ursprungsseite bestätigen. Sobald die Nachricht an den Brückenvertrag auf der Ziel-Chain weitergeleitet wird, werden Token an den Benutzer freigegeben.

Es gibt mehrere grundlegende Probleme mit dieser Architektur:

1. Der Überprüfungsmechanismus muss auf die volle Endgültigkeit warten, bevor die Nachricht an den Protokollvertrag der Zielketten gesendet wird. Dies kann bis zu sieben Tage dauern für L2s mit optimistischen Endgültigkeitsperioden.
2. Eine Cross-Chain-Nachricht wird pro Brückentransaktion gesendet ODER Nachrichten werden zusammengefasst, aber die Charge kann nur gesendet werden, nachdem die letzte Nachricht in der Charge abgeschlossen ist.
3. Die Brücke hat nur begrenzte Fähigkeiten, externe Liquidität zu beschaffen, um den Benutzern Preiserhöhungen zu ermöglichen, da sie den Erfüllungsweg der Benutzerintention deklarativ angeben muss.

Nachrichtenübermittlungsschnellbrücken werden je nach Verifizierungsmechanismus entweder unsicher, langsam oder teuer sein. Intent-Märkte sind eine alternative Architektur für schnelles Brücken, die aus einem Schlüsselerkenntnis entstehen:

Wert ist fungibel, und es sollte dem Empfänger nicht wichtig sein, wie der Wert übertragen wird, solange er die Mittel erhält.

Kann eine Brücke den Werttransfer an einen erfahrenen Agenten auslagern, um Geschwindigkeit und niedrigere Kosten zu erlangen? Die Liquidität ist dynamisch on- und offchain, und eine Preisverbesserung kann realisiert werden, wenn der Brückenmechanismus die Flexibilität hat, einen optimalen Ausführungspfad zum Zeitpunkt des Brückentransfers zu wählen.

Intent-Mechanismen ermöglichen es Benutzern, genaue Bedingungen oder Vereinbarungen festzulegen, unter denen ihre Wertübertragungstransaktion ausgeführt werden kann.

Ein minimal überlebensfähiger Intent ist ein Auftrag, X Token von Chain A zu zahlen, um Y Token auf Chain B zu erhalten.

Das Brückenprotokoll muss keine Nachricht zwischen Domänen pro Brückentransaktion senden, um die Absicht eines Benutzers zur Kreuzdomänen zu erfüllen. Stattdessen lagert das Protokoll den Werttransfer an einen Agenten aus, der aus einem netzwerkbasierten, berechtigungslosen Löser stammt, und der einzelne Löser wird später eine Rückzahlung vom Brückenprotokoll suchen. Im Vergleich dazu spezifizieren nachrichtenbasierte Mechanismen genau, wie ihre Transaktionen ausgeführt werden sollen, und müssen nicht auf die Verfügbarkeit eines Agenten angewiesen sein.

Absichtsabwicklung Protokolle

Intention-based Bridge-Protokolle können präziser als Intention-Abwicklung-Protokolle bezeichnet werden, die dafür verantwortlich sind, sicherzustellen, dass die Löser die vom Benutzer festgelegten Bedingungen nicht verletzen. Intention-Abwicklung-Protokolle bieten den Lösern Sicherheit, dass sie für die Erfüllung der Benutzerintentionen zurückerstattet und belohnt werden. Dazu müssen Intention-Abwicklung-Protokolle ein Orakel anrufen, um die Echtheit der Intentionserfüllung zu überprüfen. Die Sicherheit des Orakels kann beispielsweise auf einem optimistischen Herausforderungszeitraum, einer Zeugenschwelle oder einem ZK-Gültigkeitsnachweis basieren.

Intent-Siedlungsprotokolle bieten schnelle und kostengünstige Wertübertragungen, da einzelne Solver das Finalitätsrisiko übernehmen und optimale Ausführungswege identifizieren können

Nachrichtenübergangsbrücken können nur so schnell kommunizieren, wie die Endgültigkeit von der Ursprungskette erreicht wird. Die Endgültigkeitszeiten betragen heute sieben Tage bei optimistischen Rollups und eine Stunde bei ZK-Rollups. Obwohl diese Endgültigkeitszeiten aufgrund der breiteren Akzeptanz der ZK-Light-Client-Technologie und Fortschritten bei der Technologie zur gemeinsamen Sequenzierung vor der Bestätigung tendenziell abnehmen sollten, ist es unwahrscheinlich, dass die Endgültigkeitszeiten für alle Blockchains jemals für Benutzer „instantan“ erscheinen werden, was auf einen anhaltenden Bedarf an schnellen Brückenlösungen hindeutet. Es ist unmöglich, eine Nachricht schneller zu übermitteln als die Endgültigkeitsperiode, ohne das Endgültigkeitsrisiko zu übernehmen - was außerhalb des Bereichs einer Nachrichtenübergangsbrücke liegt - es sei denn, die Brücke möchte einen zusätzlichen vertrauenswürdigen Agenten hinzufügen, der Verluste aufgrund von Kettenneuanordnungen absichert.

Die Beschleunigung, die durch die architekturbasierte Absicht angeboten wird, entsteht, weil einzelne Solver innerhalb eines heterogenen Solver-Netzwerks mehr Endgültigkeitsrisiko übernehmen können als ein Nachrichtenübertragungsprotokoll und den Benutzerwunsch erfüllen, bevor das Risiko eines Kettenumbaus vollständig verschwindet. Solver werden den Benutzern anschließend für dieses Endgültigkeitsrisiko, das sie im Austausch für schnellere Füllzeiten übernehmen, Gebühren berechnen.

Das Auslagern der Erfüllung von Cross-Chain-Intentionen an einen Agenten führt im Durchschnitt auch zu einer Preisverbesserung für die Benutzer. Bei Intention-basierten Brücken werden Problemlöser, die Benutzerbestellungen auf der gewünschten Zielkette vorwegnehmen, später vom System nach Validierung ihrer Erfüllung zurückgezahlt. Diese Intentionssiedlungen können zusammengefasst werden, um die Kosten zu amortisieren. Anders als Benutzer verlangen Füller keine sofortige Rückzahlung und berechnen den Benutzern entsprechend für die Bereitstellung von Kapital. Die Chargenabrechnung ist nicht einzigartig für die Intention-basierte Architektur, aber die Architektur ist synergistischer mit der Chargenabrechnung, weil sie den Rückzahlungsschritt von dem Intentionserfüllungsschritt trennt.

Der größere Quellpreisverbesserung kommt von der Intuition, dass Wert fungibel ist, und das Finden des besten Weges just-in-time wird in der Regel die Wertübertragung übertreffen. (Einige Wege werden jedoch unmöglich zu schlagen sein, wenn es um die Kosten just-in-time geht, wie z.B. beim Überbrücken von USDC über CCTP.)

Nachrichtenüberbrückungen müssen codieren, wie sie den Wert an den Benutzer übertragen werden. Einige entscheiden sich dafür, Token aus einem Liquiditätspool zu einem vorbestimmten Wechselkurs zu senden, während andere repräsentative Token für Empfänger prägen, die diese dann gegen das gewünschte kanonische Token-Asset umtauschen müssen.

Beim Erfüllen des Benutzerwunsches kann ein Agent Liquidität aus einer Kombination von On-Chain- und Off-Chain-Liquiditätsquellen beschaffen. Wettbewerbsfähige Lösernetzwerke bieten den Benutzern theoretisch unbegrenzte Liquiditätsquellen (aber selbst diese Liquiditätsquellen können schnell aufgebraucht sein, wenn das Handelsvolumen bei hoher Volatilität in eine Richtung tendiert, z. B. bei beliebten NFT-Münzen, Lufttropfen und Rug Pulls auf On-Chain-Ereignissen).

Das Einreichen eines Cross-Chain-Auftrags als Absicht ermöglicht es den Lösungen, das generierte MEV des Auftrags als Preiserhöhung zu internalisieren.

Die auf Absicht basierende Architektur ist grundsätzlich darauf ausgelegt, sicher zu sein

Absichtsbasierte Brücken können sicher gebaut werden, da sie die dringenden Anforderungen des Benutzers von den komplexen Anforderungen des Abwicklungsnetzwerks trennen. Löser können auf die Rückzahlung warten, im Gegensatz zu Benutzern, und sie werden Benutzer für die Zeit in Rechnung stellen, die das Abwicklungsprotokoll sie auf die Rückzahlung warten lässt. Daher können Absichtsabwicklungen mit sehr robusten Mechanismen validiert werden, ohne strenge zeitliche Einschränkungen. Dies ist aus Sicherheitssicht vorzuziehen, da die Überprüfung einer Absichtserfüllung intuitiv komplex ist.

Als Beispiel für die Absichtsüberprüfung in der Produktion, Übervalidiert und begleicht Füller in Chargen nach einer 90-minütigen optimistischen Herausforderungsphase. Natürlich sollten Abrechnungsnetzwerke bestrebt sein, Füller so schnell wie möglich zurückzuzahlen, um die Gebühren für Endbenutzer zu reduzieren. Eine Verbesserung des optimistischen Herausforderungsmechanismus wäre ein ZK-Gültigkeitsbeweismechanismus, der verlangen würde, die Absichtsvalidierungslogik in einen ZK-Schaltkreis zu codieren. Meiner Meinung nach ist es unausweichlich, dass Gültigkeitsbeweismechanismen optimistische Herausforderungsmechanismen ersetzen und es Abrechnungsnetzwerken ermöglichen, Benutzer schneller zurückzuzahlen.

Also, wie entsteht eine Kettenabstraktion aus der architekturabhängigen Architektur?

Denken Sie daran, dass die Gate-Abstraktion eine schnelle und kostengünstige plattformübergreifende Wertübertragung erfordert. Es sollte auch nicht erforderlich sein, dass der Benutzer eine Onchain-Transaktion im Netzwerk, in dem ihre Vermögenswerte gespeichert sind, einreichen muss.

Ein Benutzer muss seine Absicht nicht auf der Blockchain einreichen, wenn sie eine Erlaubnis2oderEIP3074Signatur. Dies gilt sowohl für nachrichtenbasierte als auch für intentionsbasierte Brücken. Beide Architekturen können von dem Permit2-Muster profitieren, um es dem Benutzer zu ermöglichen, außerhalb der Kette die Menge an Tokens zu unterschreiben, die sie aus ihrem Wallet der Ursprungskette bezahlen möchten.

Intent-Marktplätze unterstützen die Abstraktion der Kette am besten, da sie einen kostengünstigen und schnellen Cross-Chain-Werttransfer bieten. Stellen Sie sich eine Welt vor, in der ein Benutzer einen Solver bitten könnte, ihm ein Angebot zu unterbreiten, um eine WETH-Staking-Position auf Arbitrum einzugehen, wobei er seine USDC auf Optimism als Zahlung verwendet. Der Benutzer könnte diese Absicht offchain an eine RFQ-Auktion senden, bei der Solver darauf bieten könnten. Der Gewinnerlöser der Auktion könnte dann die unterschriebene Absicht des Benutzers erhalten, die ein Kontingent für die Ausgabe seiner USDC für Optimism, die gewünschte Menge an WETH für Arbitrum und die Calldaten enthält, die erforderlich sind, um diese WETH in eine Staking-Position auf Arbitrum einzuzahlen. Der Solver könnte diese Transaktion anschließend auf Optimism (im Namen des Benutzers) übermitteln, um die Cross-Chain-Absicht zu initiieren und USDC aus der Optimism-Wallet des Benutzers zu ziehen. Schließlich könnte der Solver die Absicht des Benutzers auf Arbitrum erfüllen, indem er ihm WETH sendet und die Aufrufdaten weiterleitet, um den Benutzer in die Onchain-Staking-Position zu bringen.

Den Aufbau einer Kettenabstraktionsinfrastruktur zu ermöglichen, bedeutet, diesen Benutzerfluss sofort und kostengünstig erscheinen zu lassen, ohne dass sie eine Onchain-Transaktion durchführen müssen. Lassen Sie uns diesen Artikel abschließen, indem wir Hindernisse für eine breitere Akzeptanz von Absichten diskutieren.

Intent-Architektur von Across

Für das bestmögliche Benutzererlebnis muss ein wettbewerbsfähiges Netzwerk von Lösern aus der absichtsbasierten Kettenabstraktion entstehen.

Das Bridging mit Absichten hängt von Solver-Netzwerkeffekten ab, um eine bessere Leistung als Varianten mit Nachrichtenübergabe zu erzielen. Dies ist der zentrale Kompromiss zwischen Absichts- und Nachrichtenübergabearchitekturen. Realistisch betrachtet benötigen nicht alle Anwendungen, die Absichten erzeugen, Zugriff auf einen perfekt wettbewerbsfähigen Satz von Solvers, und einige ziehen es möglicherweise vor, ihre Absichten an oligopolistische Lösernetzwerke. Allerdings ist der aktuelle Zustand der Lösungsnetzwerke unreifund ist noch weit davon entfernt, die Annahmen zur Netzwerk-Lebendigkeit zu erfüllen, von denen Marktplätze abhängen.

Wir wollen keine Welt, in der jede Dapp Absichten an isolierte Solver-Netzwerke weiterleitet. Der beste Fall für die Benutzerfreundlichkeit ist, dass viele Dapps mit den gleichen Solver-Pools kommunizieren und alle Dapps die Freiheit haben, zu ändern, an welche Solver-Pools sie ihre Absichten senden.

Wie starten wir das Lösernetzwerk?

Wir müssen den UX-Löser priorisieren.

Das Ausführen eines Absichtslösers ist kompliziert und erfordert Fachkenntnisse im Bau von hochperformanter Software sowie im Umgang mit dem Risiko des Cross-Chain-Inventars. Natürlich wird es nur begrenzte Parteien geben, die an den anfänglichen Kosten interessiert sind, um diesen Code auszuführen. Im besten Fall könnte ein für eine Dapp geschriebener Löser, wie z.B. ein UniswapX-Löser, wiederverwendet werden, um für andere Absicht-produzierende Dapps wie Across und CowSwap zu lösen.

Wir müssen die aggregierte Kapitaleffizienz des Solver-Netzwerks für alle anwendungsbezogenen Dapps wirklich steigern. Dies erfordert die Bewältigung der Hindernisse beim Betrieb eines Solvers.

Dafür müssen dApps, die Absichten produzieren, für jeden Solver sichtbar sein und sicherstellen, dass alle Solver Zugang zu vielen differenzierten und wettbewerbsfähigen Intent-Settlement-Netzwerken haben. Dies würde den Solvern das Vertrauen geben, dass sie wählen könnten, ihre Absichtserfüllungen an ein Settlement-Netzwerk zu leiten, dem sie vertrauen. Der Wettbewerb zwischen den Settlement-Netzwerken würde auch die Kosten für die Solver senken.

Der Wertversprechen von Absichtsabrechnungsnetzwerken besteht darin, Sicherheit für Löser sowie andere Funktionen anzubieten, die sich auf die Fähigkeit des Löser auswirken würden, eine Absicht zu erfüllen.

Die Wahl des Abrechnungsnetzwerks des Löser wird sich auf ihre Fähigkeit auswirken, Gebühren und Ausführungszeitgarantien für Benutzer anzubieten. Einige Abrechnungsnetzwerke könnten Löserausschließlichkeitszeiten anbieten, die die Entwicklung von Off-Chain-Auktionen unterstützen würden, bei denen Löser und Benutzer Gebühren verhandeln und sich darauf festlegen könnten. (Diese Absichtsauktionen könnten außerdem wirtschaftlich gebundene Vorbestätigungen anbieten, um die Benutzererfahrung weiter zu verbessern. Um mehr über einen Benutzerfluss zu erfahren, der die Absichtsentdeckung über Auktionen und Vorbestätigungen bietet, empfehle ich diesVortrag von Karthik von Sorella.)

Einige Abrechnungsnetzwerke könnten eine Absichtsverfall anbieten (d.h. die Rücksendung des Werts an die Benutzer, nachdem eine bestimmte Erfüllungsfrist abgelaufen ist), Absicherung der Absicht (d.h. das Abrechnungsnetzwerk verwendet seine eigene Bilanz, um die Absicht eines Benutzers zu erfüllen, wenn kein Solver dies tut) oder eine flexible Rückzahlungskette (d.h. dem Solver zu ermöglichen, auf seiner bevorzugten Kette zurückgezahlt zu werden).

Letztendlich werden Abrechnungsnetzwerke erbittert miteinander konkurrieren, um Lösern eine schnelle und kostengünstige Rückzahlung zu ermöglichen, ohne die Sicherheit zu beeinträchtigen. Im Gegenzug werden Löser ihre Orderflows an die Abrechnungsnetzwerke senden, die es ihnen ermöglichen, den Benutzern die günstigsten Gebühren anzubieten, um den Dapp-Orderflow zu gewinnen. Der Wettbewerb in Abrechnungs- und Lösernetzwerken hängt davon ab, dass alle Parteien in der Absichts-Wertschöpfungskette koordinieren, um dieselbe Sprache zu sprechen, und der Wettbewerb wird zu der besten UX für den wertübergreifenden Transfer führen.

Es ist klar, dass wir einen Standard für Cross-Chain-Intents benötigen

Wenn Löser davon ausgehen können, dass Absichten gemeinsame Elemente teilen werden, können sie ihren Code wiederverwenden, um Absichten zu lösen, die von verschiedenen DApps stammen, und anschließend ihre Einrichtungskosten senken. Wenn verschiedene DApps Absichten erstellen, die dem gleichen Standard entsprechen, können sie alle ihre Absichten an dieselben Löserpools routen. Dies würde dazu beitragen, die nächste Generation von DApps an Bord zu holen, indem sie ihnen die Möglichkeit geben, ihre Cross-Chain-Absichten direkt in einen vorhandenen und ausgereiften Löserpool einzustecken. Neue DApps müssten keine Löser einzeln an Bord holen und stattdessen Zugang zu kostengünstigen, schnellen, sicheren und permissionless Werttransfers erhalten.

Drittanbieter-Tracking-Software könnte auch leichter in der Lage sein, Absichtsstatus für jede neue Dapp zu verfolgen, wenn sie einem Standard entsprechen.

Diese Absichtsstandard sollte es dem Absichtsprinzipal oder dem Solver ermöglichen, anzugeben, auf welchem Abrechnungsnetzwerk sie ihre Absicht abwickeln möchten.

Ich stelle mir vor, dass konkurrierende Abrechnungsprotokolle wie SUAVE, Across, Anoma und Khalani differenzierte Funktionen für Intent-Löser anbieten. Abhängig davon, welches Abrechnungsnetzwerk den Löser zurückzahlt, kann der Löser dem Besitzer des Intent unterschiedliche Preis- und Zeitgarantien anbieten. Die Dapp und der Löser könnten sich darauf einigen, den Intent eines Benutzers an ein Abrechnungsnetzwerk zu leiten, dem sie vertrauen, um Zensur zu vermeiden, die Datenschutz zu wahren und auch sicher genug zu sein, um dem Löser vertraut zu werden.

Indem die Auswahl des Abrechnungsnetzwerks direkt in den Absichtsauftrag aufgenommen wird, könnte der Solver diese Sicherheit in das Angebot einbauen, das sie dem Benutzer zeigen würden. Der Solver und der Benutzer würden die anfängliche Unsicherheit über die Brückenpreisgestaltung beseitigen, bevor sie die Absicht onchain einreichen, was die Kosten reduziert.

In Zusammenarbeit mit Uniswap und basierend auf dem Feedback der CAKE-Arbeitsgruppe schlagen Across und ich den folgenden Cross-Chain-Intents-Standard vor, der den UX des Lösevorgangs priorisiert:

///@titleCrossChainOrder Typ

///@noticeStandardauftragsstruktur, die von Swappern unterzeichnet, an Füller weitergegeben und an Abrechnungsverträge übermittelt werden soll

struct CrossChainOrder {

/// @dev Die Vertragsadresse, an die der Auftrag abgewickelt werden soll./// Füller senden diesen Auftrag an diese Vertragsadresse auf der Ursprungsketteadresse settlementContract;/// @dev Die Adresse des Benutzers, der den Tausch initiiert,/// dessen Eingabetoken entnommen und treuhänderisch hinterlegt werdenadresse swapper;/// @dev Nonce, der als Wiederholungsschutz für den Auftrag verwendet werden solluint256 nonce;/// @dev Die chainId der Ursprungsketteuint32 originChainId;/// @dev Der Zeitstempel, bis zu dem der Auftrag initiiert werden mussuint32 initiateDeadline;/// @dev Der Zeitstempel, bis zu dem der Auftrag auf der Zielskette ausgeführt sein mussuint32 fillDeadline;/// @dev Beliebige, implementierungsspezifische Daten/// Können verwendet werden, um Token, Beträge, Zielketten, Gebühren, Abwicklungskriterien,/// oder andere auf den Auftragstyp bezogene Informationen zu definierenbytes orderData;

}

Dieser Standard wurde entwickelt, um die Arbeit eines Lösers zu erleichtern. Eine entschiedene Wahl, die getroffen wird, ist, Permit2/EIP3074 nativ mit der Nonce und initiateDeadline zu unterstützen und den Fillern einige Garantien zu geben, wie z. B. die Höhe der Rückerstattung aus dem Abrechnungsnetzwerk und das Format des Benutzerwunsches, den sie verfolgen können. Darüber hinaus wird in dem Standard eine Initiate-Funktion definiert, die es dem Füller, der die Bestellung onchain bringt, entscheidend ermöglicht, zusätzliche „FillerData“ onchain anzugeben, von dem der Benutzer zum Zeitpunkt des Unterzeichnens des CrossChainOrders nichts gewusst haben würde. Dies ermöglicht es dem Füller sicherzustellen, dass er vom Abrechnungsvertrag belohnt wird, wenn er die Meta-Transaktion des Benutzers einreicht, und auch spezifische Informationen zur Rückzahlung festzulegen, wie z. B. Rückzahlungsketten.

Dieser Standard wurde auch entwickelt, um es Dapps zu erleichtern, den Erfüllungsstatus der Absicht während ihres Lebenszyklus zu verfolgen. Jeder Abrechnungsvertrag, der diesen Standard implementiert, sollte einen benutzerdefinierten Subtyp ResolvedCrossChainOrder erstellen, der aus dem beliebigen orderData-Feld geparst werden kann. Dies kann Informationen wie die beteiligten Token im Swap, die Zielkette(n) und andere Erfüllungsbeschränkungen umfassen. Eine Auflösefunktion ist im Standard enthalten, um Dapps zu ermöglichen, zu verstehen, wie sie Absichtsstatus für Benutzer anzeigen können, und für Löser, die genaue Absichtsordnungsstruktur zu kennen, mit der sie arbeiten.

/// @titleGelösterCrossChainOrder-Typ

/// @noticeEine implementierungsunabhängige Darstellung einer Bestellung

///@devDefiniert alle Anforderungen für die Erfüllung einer Bestellung durch die Entbündelung der implementierungsspezifischen Auftragsdaten.

/// @devZiel ist es, die Integration zu verbessern, indem Füllstoffe in der Lage sind, die genauen Eingabe- und Ausgabeinformationen jeder Reihenfolge zu berechnen.

struct ResolvedCrossChainOrder {

/// @dev Die Vertragsadresse, an die die Bestellung abgewickelt werden soll, Adressabwicklung Vertragsadresse;/// @dev Die Adresse des Benutzers, der den Tausch initiiert, Adressentauscher;/// @dev Nonce, der als Wiederholungsschutz für die Bestellung verwendet werden soll, uint256 nonce;/// @dev Die chainId der Ursprungskette, uint32 originChainId;/// @dev Der Zeitstempel, bis zu dem die Bestellung initiiert werden muss, uint32 initiateDeadline;/// @dev Der Zeitstempel, bis zu dem die Bestellung auf den Zielschain(s) gefüllt werden muss, uint32 fillDeadline;/// @dev Die Eingaben, die vom Tauscher im Rahmen der Bestellinitiierung übernommen werden sollen, Input[] swapperInputs;/// @dev Die Ausgaben, die dem Tauscher im Rahmen der Bestellabwicklung gegeben werden sollen, Output[] swapperOutputs;/// @dev Die Ausgaben, die dem Füller im Rahmen der Bestellabwicklung gegeben werden sollen, Output[] fillerOutputs;

}

/// @noticeToken, die vom Swapper als Eingaben für die Order gesendet werden

struct Input {

/// @dev Die Adresse des ERC20-Tokens auf der Ursprungsketteadresse token;/// @dev Die Menge des zu sendenden Tokensuint256 Betrag;

}

///@noticeToken, die für eine gültige Auftragserfüllung erhalten werden müssen

struct Output {

/// @dev Die Adresse des ERC20-Token auf der Zielkette/// @dev Adresse(0) als Sentinel für den nativen Token verwendet Adresse Token;/// @dev Die Menge des zu sendenden Tokens uint256 Menge;/// @dev Die Adresse zum Empfangen der Ausgangstoken Adresse Empfänger;/// @dev Die Zielkette für diesen Output uint32 chainId;

}

Eine konforme Abwicklung Vertragsimplementierung MUSS das ISettlementContract-Interface implementieren:

///@titleISiedlungsvertrag

///@noticeStandard-Schnittstelle für Abrechnungsverträge

Schnittstelle ISettlementContract {

/// @notice Initiiert die Abwicklung einer Cross-Chain-Bestellung/// @dev Wird vom Füller aufgerufen/// @param order Die CrossChainOrder-Definition/// @param signature Die Signatur des Swappers über die Bestellung/// @param fillerData Alle vom Füller definierten Daten, die vom Abwickler benötigt werdenfunction initiate(CrossChainOrder order, bytes signature, bytes fillerData) extern;/// @notice Löst eine spezifische CrossChainOrder in eine generische ResolvedCrossChainOrder auf/// @dev Vorgesehen zur Verbesserung der standardisierten Integration verschiedener Bestelltypen und Abwicklungsverträge/// @param order Die CrossChainOrder-Definition/// @param fillerData Alle vom Füller definierten Daten, die vom Abwickler benötigt werden/// @returns ResolvedCrossChainOrder hydrierte Bestelldaten einschließlich der Eingänge und Ausgänge der Orderfunction resolve(CrossChainOrder order, bytes fillerData) extern view returns (ResolvedCrossChainOrder);

}

Die Designziele dieses Standards bestanden darin, die Benutzeroberfläche des Löser zu verbessern, es ihnen zu erleichtern, mehrere Abrechnungsnetzwerke zu unterstützen und ihre Belohnungen deterministisch zu berechnen. Ich glaube, dass dies es ihnen ermöglichen wird, den Benutzern genauere und engere Angebote zu machen. Weitere Details zu diesem Standard mit dem Codenamen ERC7683 finden Sie im Folgenden: in diesem X/Twitter-Beitragund die Diskussion darumim Ethereum Magicians Forum.

Abschließende Gedanken

"Intents" sind verwirrend, weil sie nicht definiert sind, und dieses Fehlen einer Definition führt zu echten UX-Defekten.

Jeder möchte, dass alle anderen ihre standardmäßige Definition einer Absicht verwenden, daher erkenne ich voll und ganz an, dass Standards praktisch unmöglich zu etablieren sind. Ich glaube nicht, dass es der richtige Ansatz ist, zuerst ein Absicht-Abrechnungssystem zu definieren und dann zu versuchen, den Auftragsfluss anzuziehen, um einen branchenweiten Standard zu etablieren.

Meiner Meinung nach ist der zugänglichere Ansatz für Dapps, die bereits über eine hohe Benutzeranzahl verfügen und viele Benutzerabsichten generieren, sich auf einen minimalen Standard zu einigen, den ihre bestehenden Solver übernehmen werden. Dadurch entsteht ein neuer und größerer Solver-Pool. Durch den Zugriff auf zusammengeführte Orderflows von bereits prominenten Handelsplätzen wird dieser neue Solver-Pool mehr Gewinne erzielen und in der Lage sein, bessere Preise für Endbenutzer anzubieten. Letztendlich werden auch neuere Dapps verlangen, ihre Absichten an diesen Solver-Pool zu leiten und dessen Standard zu unterstützen.

Um uns in Gang zu bringen, arbeiten Across und Uniswap gemeinsam aneinen Standard vorschlagenfür alle beabsichtigten Lieferkettenparteien zur Verwendung beim Umgang mit Benutzerbestellungen zum Senden von X-Token von Kette A und zum Empfangen von Y-Token auf Kette B. Der Orderflow, der über UniswapX (mit einem komparativen Vorteil im Auktionsdesign und der Ursprungsgedanken) und Across (mit einem komparativen Vorteil bei der Erfüllung von Absichten) läuft, kann fusionieren und den Prozess des Aufbaus eines größeren, wettbewerbsfähigeren Lösernetzwerks einleiten.

Haftungsausschluss：

1. Dieser Artikel ist abgedruckt von [Spiegel], Alle Urheberrechte gehören dem Originalautor[Nick Pai]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die Gate LearnTeam, und sie werden es schnell bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, 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, Verteilen oder Plagiieren der übersetzten Artikel untersagt.