Einführung

Die Bewältigung von MEV (Maximal Extrahierbarem Wert) war eine fortwährende Herausforderung für Ethereum; die Wertschöpfungskette incentiviert ständige Aktivität von Arbitrageuren mit vielfältigen Strategien unterschiedlicher Raffinesse, oft auf Kosten von Einzelhandelsnutzern. Obwohl viele Forscher versucht haben, MEV durch Änderungen auf Protokollebene anzugehen, haben diese Bemühungen bisher keine zufriedenstellende Lösung geliefert. Die derzeit verwendete kanonische Infrastruktur und Auktionsmechanismen sind in der Lage, den Gesamt-MEV in einem Block wettbewerbsfähig zu erfassen, aber die Erfassung ohne faire Umverteilung ist unzureichend: Warum sollte sich der MEV-Wert auf die Netzwerkvalidatoren akkumulieren, wenn er effektiver auf Anwendungsgrundlage erfasst und internalisiert werden kann?

Geben Sie die anwendungsspezifische Sequenzierung (ASS) ein. Anstatt zu versuchen, die Regeln auf Protokollebene neu zu schreiben, gibt ASS einzelnen Apps die Möglichkeit, die Kontrolle darüber zu übernehmen, wie ihre Transaktionen sequenziert werden. Auf diese Weise ermöglicht ASS Onchain-Anwendungen, ihre Benutzer und Liquidität vor den schädlichen Auswirkungen von MEV zu schützen und ihnen gleichzeitig die Möglichkeit zu geben, Werte zu erfassen, die sonst an Ethereum-Validatoren verloren gehen würden.

Stellen Sie sich das Potenzial vor: Anstatt dass Hochfrequenzhändler um die maximale Arbitrage jedes Benutzers konkurrieren (wobei fast der gesamte arbitrierte Wert an die Validatoren und damit an die zugrunde liegenden Ketten verloren geht), könnte jede App ihre eigenen Regeln für die Transaktionsreihenfolge definieren, um ein maßgeschneidertes, effizientes und faires System für ihre eigenen Benutzer zu schaffen. Dies markiert eine Verschiebung vom Versuch, MEV auf Netzwerkebene zu lösen, hin zu seiner Lösung an dem Ort, an dem es am wichtigsten ist - der Anwendung selbst.

Hintergrund

Das Konzept hinter der anwendungsspezifischen Sequenzierung (ASS) stammt aus Matheus' Arbeit an der Verifizierbare Sequenzierungsregel (VSR) für dezentralisierte Börsen (DEXes). Matheus hat gezeigt, dass VSR den Handelsablauf verbessern und MEV mindern kann, indem es den Einfluss der Miner auf die Transaktionsreihenfolge verringert. Tarun später erweiterte diese Ideeindem gezeigt wird, wie app-spezifische Sequenzierungsregeln die Auszahlungsfunktionen für Protokollteilnehmer wie Benutzer, Validatoren und Sequenzer signifikant beeinflussen könnten.

Hier stellt die Auszahlungsfunktion den wirtschaftlichen Wert einer bestimmten Transaktionsreihenfolge dar. Dieser Wert spiegelt den Gewinn oder den Nutzen wider, den die Teilnehmer des Protokolls erzielen, und zeigt, wie sich die Transaktionsreihenfolge auf ihre finanziellen Ergebnisse auswirkt. Es gibt zwei wesentliche Merkmale der Auszahlungsfunktionen:

1. Nicht reibungslose Auszahlungen: Kleine Änderungen in der Reihenfolge können große Änderungen im MEV verursachen.
2. Nicht-monotone Auszahlungen: Kleine Änderungen in der Reihenfolge können den MEV entweder erhöhen oder verringern, aber nicht konsequent in eine Richtung.

Wenn die Auszahlungsfunktionen beide dieser Merkmale aufweisen, wird die Optimierung der Sequenzstrategie äußerst komplex. In solchen Fällen sind anspruchsvollere und maßgeschneiderte Ansätze auf Anwendungsebene erforderlich, um gerechte Ergebnisse für Benutzer und ein nachhaltiges DeFi-Ökosystem zu gewährleisten.

Wie funktioniert ASS?

Um ASS zu verstehen, lassen Sie uns zunächst die vorhandene Transaktionslieferkette überprüfen.

Im aktuellen System:

1. Transaktionen werden an öffentliche oder private Mempools gesendet.
2. Builder sammeln diese Transaktionen und packen sie in Blöcke.
3. Dann konkurrieren die Entwickler in einer Blockauktion.
4. Der gewinnende Baustein ist in die Blockchain aufgenommen und der Wert, den sie bieten, wird dem ausgewählten Antragsteller für den entsprechenden Block gezahlt.

Die Abbildung unten veranschaulicht diesen Prozess und zeigt, wie Transaktionen von Mempools über Builder und vertrauenswürdige Relais in die Blockchain fließen.

Diagramm der aktuellen Transaktionslieferkette

Anwendungen, die durch ASS aktiviert werden, haben folgende Eigenschaften:

1. Beschränkte Sequenzierungsrechte: Diese Beschränkung stellt sicher, dass nur ein bestimmter Sequenzer oder gestakte Validatoren mit dem Vertrags der Anwendung auf der Kette interagieren können, auf der sie sich niederlässt, und verhindert betrügerisches Umgehen der Logik der Anwendung für interne Wertumverteilung.
2. App-spezifische Mempools: Anstatt Transaktionen an einen öffentlichen Mempool zu senden, senden Benutzer signierte Nachrichten, in denen ihre Absicht an einen app-spezifischen Mempool ausgedrückt wird. Diese Absichten werden dann gesammelt und vom app-spezifischen Sequenzer verarbeitet.
3. Order-Agnostic Outcomes: Um die Sequenzregel durchzusetzen und den optimalen wirtschaftlichen Ertrag für die Zielbenutzer zu erzielen, müssen ASS-Transaktionen gegenüber der Transaktionsreihenfolge der Erbauer neutral sein. Dies wird durch die Sicherstellung gewährleistet, dass der Zustand der Anwendung durch ihren Konsensmechanismus Gated ist. ASS-Aufträge werden dann zu einem einzigen Bündel konsolidiert, das an die Erbauer zur Aufnahme gesendet wird. Da dieses Bündel nicht im Konflikt mit dem von anderen Anwendungen abgerufenen Zustand steht, ist es unabhängig von seiner Position im Block.

ASS ermöglicht es Anwendungen auf jeder Kette, die Souveränität über ihre Ausführung und Vertragszustand wiederzugewinnen und somit souveräne Anwendungen zu ermöglichen.

Unter Berücksichtigung dieser grundlegenden Grundsätze wollen wir Angstrom als praktisches Beispiel für eine souveräne Anwendung verwenden. Angstrom ist ein UniswapV4-Hook, der seine Liquiditätsanbieter vor nachteiliger Auswahl durch CEX-DEX-Arbitrageure schützt und gleichzeitig Swapper vor Sandwich-Angriffen schützt. Ein Netzwerk von Angstrom-Nodes erzielt parallel zu Ethereum Konsens über die zu bearbeitenden Transaktionen im nächsten Block. Der allgemeine Ablauf ist wie folgt:

1. CEX-DEX-Arbitrageure bieten um das Recht, die erste Transaktion durch die AMM zu tauschen (ohne Gebühr). In der Zwischenzeit senden Benutzer ihre beabsichtigten Swaps als signierte Limit-Orders an den Angstrom-Mempool.
2. Das Angstrom-Netzwerk führt sein Konsensprotokoll aus und bildet ein Bündel, bei dem der erste Tausch die Arbitrageur-Transaktion mit dem höchsten Gebot ist. Der Gebotsbetrag wird anschließend pro rata auf die zugrunde liegenden LPs im Bereich des Tauschs verteilt. Alle anderen gültigen Limitorders sowie die zugrunde liegende AMM-Liquidität werden zum gleichen einheitlichen Clearingpreis ausgeführt.
3. Dieses Bündel wird dann vom vorschlagenden Angstrom-Knoten an Ethereum-Entwickler und die öffentliche Mempool gesendet.
4. Die Erbauer können das Angstrom-Bundle an beliebiger Stelle im Block einfügen. Das Bundle muss lediglich die Grundgebühr für die Aufnahme aufgrund seines ordnungsunabhängigen Aufbaus zahlen.

Das folgende Diagramm veranschaulicht die Anwendung von Souveränität in Aktion.

Die Transaktionslieferkette in Angstrom

Liveness und Vertrauensannahme

Im Kern ist ASS eine Form des teilweisen Blockbaus, bei der eine souveräne Anwendung die Sequenzierungsrechte an ein dezentrales Netzwerk von Betreibern deleGates, die einer vorgeschriebenen Sequenzierungsregel folgen. Folglich beinhaltet ASS zwangsläufig externe Parteien, die zusätzliche Lebendigkeit und Vertrauensannahmen einführen.

Lebendigkeitsannahme

Souveräne Anwendungen sind auf anwendungsspezifische Sequenzer angewiesen, um das Protokoll korrekt zu befolgen und zeitnahe Zustandsaktualisierungen bereitzustellen. Im Falle eines Verstoßes gegen die Lebensfähigkeit, wie zum Beispiel eine Netzwerkpartition, Benutzer können möglicherweise nicht mit Teilen der Anwendung interagieren, bis ein gültiger Konsens wiederhergestellt ist.

Souveräne Anwendungen können auch den Umfang des Vertragszustands einschränken, dessen Aktualisierungen von ihren Sequenzern abhängen. Dies hilft, die externen Abhängigkeiten des Vertrags zu minimieren, sodass kritische Zustände wie eingezahlte Liquidität auch im Falle eines Sequenzerfehlers zugänglich bleiben können.

Vertrauensannahme

Um sicherzustellen, dass Sequenzer die vorgeschriebenen Sequenzierungsregeln einhalten, können souveräne Anwendungen kryptökonomische Lösungen (wie PoS) oder kryptografische Methoden (wie TEE oder MPC) nutzen. Der konkrete Ansatz kann je nach den Anforderungen der Anwendung erheblich variieren. Einige benötigen möglicherweise Konsens über die Ausführungsoptimalität, während andere den Schwerpunkt auf die Gewährleistung der Vor-Ausführungs-Privatsphäre durch kryptografische Mechanismen legen. Es stehen zahlreiche Tools zur Verfügung, um den Vertrauensaufwand von Sequenzern zu reduzieren und die einzigartigen Ziele jeder souveränen Anwendung zu erfüllen.

Zensurresistenz

Im Ethereum-Ökosystem gibt es verschiedene Arten von Zensur:

1. Regulatorische Zensur: Entwickler und Relays zensieren Transaktionen basierend auf der OFAC-Sanktionsliste. Dies ist eine der prominentesten Formen der Zensur, die heute auf Ethereum vorhanden ist.überwiegend durch Relais durchgesetzt.
2. Wirtschaftszensur: Ein motivierter Angreifer kann Bestechen Sie den Block-Proposer, um Opfertransaktionen zu zensieren.
3. Zensur auf Knotenebene: Knoten im P2P-Netzwerk können sich weigern, eingehende Transaktionen weiterzuleiten. Dies kann ein großes Problem sein, wenn das Protokoll unter der Annahme optimal funktioniert, dass die Mehrheit der Knoten die gleiche Ansicht der eingehenden Transaktionen teilt. Außerdem kann ein Angreifer in solchen Protokollen Anreize haben, die lokalen Ansichten der ehrlichen Knoten zu partitionieren (indem er eine Transaktion nur an die Hälfte der Knoten am Ende eines Slots sendet) und das Protokoll dadurch zu stoppen.

Viele Forscher haben die Notwendigkeit eines besseren Zensurresistenzmechanismus auf Ethereum zum Ausdruck gebracht. Einige Vorschläge, wie z.B. Mehrere gleichzeitige Antragsteller (MCP) und Fork-Choice durchgesetzte Inklusionsliste (FOCIL), sind aufgetaucht und wurden zum Mittelpunkt einer laufenden Diskussion.

Auch die Zensurresistenz ist ein wesentliches Anliegen für souveräne Anwendungen. Die anwendungsspezifischen Sequenzer sind wahrscheinlich externe Entitäten mit unterschiedlichen Interessen daran, zusätzliche private Transaktionen und Orderflow zu erhalten. Ein anwendungsspezifischer Validator, zum Beispiel ein Market Maker, hat einen Anreiz, Transaktionen von konkurrierenden Market Makern zu zensieren. Die darüber liegende souveräne Anwendung kann daher lokale Zensur erfahren, selbst wenn das Basisprotokoll nicht zensiert.

Ein Beispiel für einen Zensurresistenz-Mechanismus für ASS ist Angstström. Um sicherzustellen, dass alle gültigen Aufträge in den bevorstehenden Slot aufgenommen werden, müssen Angström-Knoten alle verifizierten eingehenden Bestellungen übertragen und einen Konsens über ihre Aufnahme in das vorgeschlagene Transaktionspaket erzielen. Wenn im Bundle Bestellungen fehlen, die von der Mehrheit des Netzwerks beobachtet wurden, wird der Vorschlagende bestraft. Hier ist eine Illustration des Zensurwiderstandsmechanismus für Angstström.

Zensurresistenz in einer dezentralisierten souveränen Anwendung

Das Composability-Dilemma

Eine der großen Herausforderungen, denen souveräne Anwendungen gegenüberstehen, besteht darin, die Komponierbarkeit mit Transaktionen sicherzustellen, die mit externen Vertragszuständen interagieren. Einfaches Bündeln von anwendungsspezifischen Transaktionen mit beliebigen externen Transaktionen untergräbt die ordnungsagnostische Eigenschaft, die für den Schutz der souveränen Anwendung und ihrer Benutzer notwendig ist. Eine einzige ungültige nicht-ASS-Transaktion, wenn sie mit einer anwendungsspezifischen Transaktion zusammengesetzt wird, kann den Zweit-Effekt haben, dass das gesamte Bundle rückgängig gemacht wird. Wenn dies geschieht, kann die souveräne Anwendung die Aufträge ihrer Benutzer während des zugewiesenen Zeitfensters nicht ausführen (obwohl eine gültige Einigung erzielt wurde), was die Benutzererfahrung und das Gesamtwohl beeinträchtigt.

Es gibt jedoch mögliche Lösungen für das Problem der Composability, von denen einige von verschiedenen Teams untersucht werden. Dazu gehören Konzepte wie Vorabbestätigungen für die Inklusion, gemeinsam genutzte App-spezifische Sequenzer und Builder-Verpflichtungen, die jeweils Kompromisse zwischen dem Grad der Composability und dem Vertrauensaufwand bieten.

Vorbestätigungen für die Aufnahme

Um Inklusionsvorbestätigungen zu erklären, ist es wichtig, zunächst zu verstehen, wie basierte Vorbestätigungen funktionieren. Basierte Vorbestätigungen nutzen die kryptowirtschaftliche Sicherheit, indem sichergestellt wird, dass die Vorschlagenden gestecktes Kapital eingesetzt haben, um die Aufnahme eines bestimmten Satzes von Transaktionen vor einem Slot innerhalb des aktuellen Zeitalters zu garantieren. Diese Garantie ist durch die Größe der von den teilnehmenden Vorschlagenden geposteten Anleihe begrenzt.

Inklusionsvorbestätigungen sind eine spezialisierte Form von Vorbestätigungen, bei denen die Transaktionsinklusion unabhängig von einem Vertragszustand erfolgt. Transaktionen, die Inklusionsvorbestätigungen anfordern, müssen zustandsagnostisch und nicht kontrovers sein, d.h. ihre Ausführung wird nicht durch ihre Position im Block beeinflusst. Durch die Nutzung von Inklusionsvorbestätigungen können Vorschlagende sich verpflichten, eine Nicht-ASS-Transaktion nur dann einzuschließen, wenn das ASS-Bündel im selben Block enthalten ist. Dieser Ansatz ermöglicht eine kryptowirtschaftlich durchgesetzte Kombinierbarkeit zwischen nicht kontroversen Transaktionen und ASS-Bündeln.

Veranschaulichung der Einbindung von Preconf mit ASS

Angesichts der begrenzten Komponierbarkeit, die diese Lösung bietet, kann die zusätzliche Komplexität und Vertrauensbelastung für bestimmte souveräne Anwendungen ihre Vorteile überwiegen. Daher ist es wichtig, alternative Ansätze zu untersuchen, die ein effektiveres Gleichgewicht zwischen Einfachheit und Funktionalität bieten könnten.

Gemeinsame anwendungsspezifische Sequenzer und Builder-Verpflichtungen

Anstelle auf Vorschlagszusagen zu vertrauen, können souveräne Anwendungen anwendungsspezifische Sequenzer verwenden, um die Transaktionsreihenfolge über mehrere Anwendungen hinweg zu verwalten. Ein Sequenzer, der Transaktionen für mehrere souveräne Anwendungen bearbeitet, kann beispielsweise die atomare Komponierbarkeit zwischen ihnen ermöglichen, sofern er den Sequenzierungsregeln jeder Anwendung folgt. Dieser gemeinsame, anwendungsspezifische Sequenzer-Ansatz ermöglicht eine nahtlose Komponierbarkeit und Koordination zwischen souveränen Anwendungen.

Für nicht-souveräne Anwendungen ist jedoch eine andere Lösung erforderlich. Transaktionsinklusionsverpflichtungen von Blockerstellern, die an der Sequenzierung für souveräne Anwendungen teilnehmen, können eine atomare Komponierbarkeit zwischen nicht-souveränen und souveränen Anwendungen schaffen. Der Ersteller stellt die spezifische Transaktionsreihenfolge für beide Arten von Anwendungen sicher. Eine solche Verpflichtung des Erstellers kann die Komponierbarkeitslücke für ASS überbrücken.

Illustration des Builder-Engagements für die atomare Composability zwischen souveränen und nicht-souveränen dApps (rechts) und des gemeinsam genutzten App-spezifischen Sequenzers für die atomare Composability zwischen souveränen Apps (links)

Auch wenn es noch Fragen zur wirtschaftlichen Dynamik der Zusagen von Bauherren, zur Durchführbarkeit der Vorabbestätigung von Inklusionen und zu möglichen Effekten zweiter Ordnung gibt, sind wir zuversichtlich, dass die Herausforderungen bei der Zusammensetzbarkeit von ASS im Laufe der Zeit gelöst werden. Mannschaften mögen AstriaundPrimevforschen und entwickeln aktiv verbesserte Frameworks für gemeinsame Sequenzierung und Builder-Verpflichtungen. Mit dem Fortschreiten dieser Entwicklungen wird die Komponierbarkeit kein Problem mehr für souveräne Anwendungen sein.

ASS vs App-spezifische L2s und L1s

Derzeit müssen dApps app-spezifische Ketten erstellen, wenn sie die Reihenfolge ihrer Transaktionen steuern möchten. Konzepte wie Protokoll Owned Builder (PoB)ermöglicht es Cosmos L1s, überzeugendere Sequenzierungsregeln zu haben, die helfen, MEV zu erfassen und auf ihre Anwendung umzuverteilen. Ebenso kann ein L2-Sequenzer mit VSR auch solche Operationen durchführen. Während beide Lösungen eine ausdrucksstärkere Sequenzierung und Erfassung von MEV durch ihre Anwendungen ermöglichen, ist ASS aufgrund der folgenden Merkmale einzigartig.

1. Kein Vertrauensaufwand durch Transaktionsausführung - ASS führt die sequenzierte Transaktion nicht aus oder begleicht sie. Nur die Sequenzierung wird deleGated. Die grundlegende Vertrauensannahme erstreckt sich auf die native Ausführungsumgebung wie Ethereum oder andere L2s.
2. Zugang zu Liquidität und Auftragsfluss – Benutzer müssen keine Brücke bilden. dApps können den Fluss und die Liquidität in der Kette direkt nutzen.
3. Der Vermögenswert verbleibt in der nativen Ausführungsumgebung und kann nicht eingefroren werden – Im Gegensatz zu L2s verlangen die meisten ASS nicht, dass Benutzer ihre Gelder in Überbrückungsverträgen sperren. Diese Designentscheidung bietet eine bessere Sicherheit: Wenn ein App-spezifischer Sequenzer ausfällt, hält sich der potenzielle Schaden in Grenzen, da der Sequenzer nur Transaktionen innerhalb der vom Smart Contract festgelegten Grenzen kontrollieren kann. Während einige L2-Lösungen Sicherheitsfunktionen implementieren – wie z. B. Notausstiegsluken und erzwungene Einbeziehung- diese Maßnahmen sind in der Praxis oft schwer umsetzbar. Benutzer müssen möglicherweise mehrere Tage warten, bevor sie nach dem Verlust der Verbindung zu L2-Updates einen Fluchtweg aktivieren können. Eine erzwungene Einbindung über L1 beinhaltet in der Regel mindestens ein Tag Verzögerung. Am wichtigsten ist vielleicht, dass diese Sicherheitsmaßnahmen in der Regel technisches Fachwissen erfordern, über das die meisten Benutzer nicht verfügen, was sie für den Durchschnittsbürger unpraktisch macht.
4. Starke-ASS Liveness-Annahme - Die Liveness des L2 hängt von den Ausführungsknoten ab, die normalerweise der Rollup-Sequencer sind, sofern nicht sequenziert. Die Liveness des L1 hängt von der ehrlichen Mehrheit der Knoten ab, die entsprechende Zustandsübergangsfunktionen erneut ausführen. Die Liveness einer souveränen Anwendung hängt größtenteils von der zugrunde liegenden Ausführungsumgebung ab, und Smart Contracts können Teile angeben, die auf app-spezifischen Sequencern beruhen müssen.

Tabelle mit Vergleich von Sovereign-Anwendungen, L2, Based L2 und L1

Fazit

ASS ermöglicht Anwendungen eine vollständige Souveränität über die Reihenfolge von Transaktionen, wodurch sie benutzerdefinierte Regeln festlegen können, ohne die Komplexität der Ausführungsverwaltung. Diese Souveränität ermöglicht es Anwendungen, die Ausführung zu kontrollieren, um Ergebnisse für ihre Benutzer zu optimieren. Zum Beispiel werden auf Angstrom LPs und Swapper als erstklassige Teilnehmer behandelt, wobei ihre wirtschaftliche Auszahlung direkt durch benutzerdefinierte Sequenzregeln verbessert wird.

Darüber hinaus kann ASS eine Reihe von kryptoökonomischen und kryptografischen Tools nutzen, um die Optimalität der Benutzerauszahlungen durchzusetzen und robuste Zensurresistenzmechanismen zu implementieren. Kryptoökonomische Lösungen wie Staking und Slashing können Anreize für ehrliches Verhalten unter Sequenzern schaffen, während kryptografische Methoden wie TEE und MPC den Datenschutz und die Sicherheit verbessern. Mit diesen Tools ist das Designpotenzial von ASS enorm und ermöglicht die Erstellung sichererer, effizienterer und benutzerzentrierterer souveräner Anwendungen.

Trotz der Möglichkeiten, die ASS bietet, gibt es immer noch Herausforderungen wie das Fehlen nativer Komponierbarkeit. Lösungen wie Inklusions-Vorbestätigung, geteilte ASS und das Engagement der Builder bieten jedoch vielversprechende Möglichkeiten, diese Hürden zu überwinden. Obwohl noch einige Fragen offen sind, sind wir entschlossen, diese Ansätze weiter zu verfeinern, um ein reibungsloseres, stärker komponierbares ASS-Erlebnis zu bieten.

Wir sind hier, um DeFi nachhaltiger zu gestalten, ein ASS nach dem anderen.

Haftungsausschluss:

1. Dieser Artikel wurde von [wiederveröffentlicht.Schwester]. Alle Urheberrechte gehören dem Originalautor [ Yuki Yuminaga]. Wenn es Einwände gegen diese Nachdruck gibt, kontaktieren Sie bitte das Gate LearnTeam, und sie werden es schnell erledigen.
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 verboten.