MEV-Boost, das aktuelle Sidecar-Protokoll für MEV-Extraktion in Ethereum, ist stark auf zentralisierte Akteure namens Relais angewiesen.

Wir schlagen eine alternative Architektur vor, die eine direkte, kryptographisch private Kommunikation zwischen den Erbauern und Vorschlagenden ermöglicht. Sie basiert auf einer neuen, nicht-interaktiven Form der "stillen" Schwellenverschlüsselung, die die bestehenden BLS-Schlüsselpaare der Validatoren verwenden kann.

Im Wesentlichen nutzen wir das Attestkomitee für Datenschutz und Datenverfügbarkeit, indem wir Blockvorschläge für einen Bruchteil der Attester für den Slot schwellwertverschlüsseln. Ihre Attestationen bilden den Entschlüsselungsschlüssel; sobald die gewünschte Schwelle erreicht ist, kann der Block entschlüsselt werden.

Unsere Konstruktion adressiert die Privatsphäre zwischen Bauherren und Antragstellern, garantiert jedoch allein keine Blockvalidität. Sie kann mit anderen Mechanismen kombiniert werden, um die von Relais bereitgestellten Funktionalitäten vollständig zu replizieren - sowohl die Privatsphäre als auch die Blockvalidität. Zum Beispiel Beweisschemata wie Trusted Execution Environment (TEE) oder Zero-Knowledge (ZK) Beweise oder kryptökonomische Mechanismen zur Kollateralisierung von Bauherren.

Indem wir die Notwendigkeit von Relais zur Bereitstellung von Bauherren-Privatsphäre und zur Sicherstellung der Blockgültigkeit beseitigen, zielen wir darauf ab, die Latenzzeit zu reduzieren und die Dezentralisierung und Zensurresistenz von Ethereum zu verbessern.

MEV-Boost und die Rolle von Relais

MEV-Boost ist ein Sidecar-Protokoll, das als Vermittler zwischen Blockerstellern und Vorschlagenden fungiert. Das HauptrolleDie Aufgabe des Relais besteht darin, zwei Garantien bereitzustellen:

• Datenschutz für Entwickler: Das Relais stellt sicher, dass Antragsteller den Blockinhalt nicht sehen und das vom Entwickler gefundenen MEV stehlen können.
• Sicherheit für Vorschlagende: Das Relais garantiert, dass der Erbauer den versprochenen Wert an den Vorschlagenden in der Gebots des Erbauers zahlt und dass der Block gültig ist (z.B. alle Transaktionen zahlen intrinsische Gas).

Die Abhängigkeit von Relais führt jedoch zu einer erheblichen Zentralisierung. Etwa 90 % der Blöcke auf Ethereum werden über nur eine Handvoll Relays bereitgestellt. Dies birgt einige Risiken:

• Zentralisierung: Builder können latenzeffizient sein, indem sie sich mit Relaisknoten zusammenstellen, anstatt die geografische Verteilung der Vorschlagenden widerzuspiegeln. Dies untergräbt direkt die geografische Dezentralisierung und Zensurresistenz, die wir sonst von einem großen, global verteilten Validatoren-Set gewinnen würden.
• Einnahmen: Die durchschnittliche Latenzzeit für die Verarbeitung von Blöcken von effizienten Relais beträgt etwa 5-20 Millisekunden. Dann gibt es eine Kommunikationslatenz zwischen dem Vorschlagenden und dem Erbauer. Das Überspringen von Relais verringert die Latenz, verringert die Risiken bei der Ausführung in verschiedenen Domänen (z.B. CEX/DEX) und erhöht letztendlich die MEV-Belohnungen der Vorschlagenden.

TEE-Boost

Einer der führenden Vorschläge zur Ersetzung von Relais ist „TEE-Boost“, das auf TEEs (Trusted Execution Environments) vertraut. Beachten Sie, dass TEEs nicht unerlässlich für unser Schema sind; es ist nur hilfreich, TEE-Boost als pädagogisches Beispiel für die Probleme zu verwenden, die wir lösen wollen.

Konkret verwenden TEE-Boost-Builder TEEs, um Nachweise zu erstellen, die den Vorschlagenden die Ehrlichkeit ihrer Gebote und die Gültigkeit ihrer Blöcke zeigen, ohne den tatsächlichen Blockinhalt den Vorschlagenden preiszugeben. Vorschlagende können diese Nachweise überprüfen, ohne selbst TEEs auf handelsüblicher Hardware auszuführen.

Allerdings hat TEE-Boost ein Datenverfügbarkeitsproblem: Die Ersteller teilen nur TEE-Proofs und Blockheader mit den Anbietern, nicht aber den eigentlichen Blockinhalt.^[1]und könnte sich entscheiden, den Blockinhalt auch nach der Unterzeichnung des Headers durch den Vorschlagenden nicht freizugeben (z.B. wenn sich die Marktkonditionen ungünstig ändern). Die vorgeschlagenen Ansätze zur Lösung dieses DA-Problems sind:

• [ ] TEE-Escrow: Ein TEE-Escrow erhält den Block vom Builder, bevor der Proposer ihn signiert und gibt ihn frei, sobald er den signierten Header sieht.
• [ ] Datenverfügbarkeitsschichten: Builder stellen verschlüsselte Block-Payloads in einer Datenverfügbarkeit (DA)-Schicht bereit.

Beide Ansätze haben Nachteile. Die TEE-Escrow-Lösung repliziert zentralisierende Latenzdynamiken, die denen vorhandener Relais ähnlich sind.^[2]Die Verwendung einer externen DA-Schicht führt zu einer zusätzlichen Protokollannahme und birgt die Latenzdynamik dieses externen Protokolls (die wahrscheinlich auch ungünstig ist).

1. Theoretisch könnten die Ersteller ihre Blöcke auch mit TEEs verschlüsseln, wenn sie darauf Zugriff hätten. Der Ersteller würde den Block erst entschlüsseln, nachdem er ihn signiert hat. Wir glauben jedoch, dass TEE-Boost dieses Design nicht berücksichtigt, da es erfordern würde, dass die Ersteller (Validatoren) TEEs ausführen. Wir möchten, dass Validatoren auf handelsüblicher Hardware ausgeführt werden können.↩

2. Die Latenzdynamik kann vermieden werden, wenn die Vorschlagenden selbst TEE-Escrow als ein seitlich platziertes Sidecar zu ihrem Validierungsknoten ausführen. Allerdings wollen wir die Validatoren nicht dazu bringen, TEEs auszuführen.↩

Schwellenkryptographie zur Erreichung der Privatsphäre des Auftragnehmers

Wir schlagen eine elegante Lösung für das DA-Problem von TEE-Boost vor: Schwellwertverschlüsselung für das Attester-Komitee. Konkret verschlüsselt der Builder Schwellenwerte den Block für einen bestimmten Bruchteil des Attester-Komitees für diesen Slot. Sobald genügend Attestationen gesammelt sind, wird der Block entschlüsselbar und verfügbar.

Die Kern-Ermöglichungstechnologie ist Stille Schwellenverschlüsselung. Diese kryptographische Technik ermöglicht eine Schwellwertverschlüsselung, ohne dass eine interaktive Distributed Key Generation (DKG) Einrichtungsphase erforderlich ist, die bei früheren Konstruktionen erforderlich war. Stattdessen wird der gemeinsame öffentliche Schlüssel deterministisch aus den bereits vorhandenen BLS-öffentlichen Schlüsseln des Attesters plus einigen "Hinweisen" (später diskutiert) berechnet.

Dies ermöglicht eine direkte Kommunikation mit kryptografischer Privatsphäre zwischen dem Entwickler und dem Validierer in einem einzigen Hop. Die Validierer müssen selbst keine TEEs ausführen oder neues Schlüsselmaterial verwalten.

Mechanik:

Der Baumeister konstruiert einen Block und verschlüsselt ihn für das Attester-Komitee.

Der Bauherr erstellt einen TEE-Nachweis, der drei Dinge vor dem Attester-Komitee demonstriert: dass das Angebot ehrlich ist, der Block gültig ist und dass er korrekt verschlüsselt ist.

Der Builder kommuniziert den verschlüsselten Schwellenblock und den TEE-Beweis (der den Gebotswert enthält) an den Vorschlagenden.^[3]

Der Antragsteller unterzeichnet den verschlüsselten Block des Gewinner-Builders und verbreitet diesen Vorschlag im Validatoren-Set.

Sobald der spezifizierte Bruchteil (z.B. n/2 oder 2n/3) des n-Attester-Komitees für den Slot den Block beglaubigt, wird er entschlüsselt.

Der entschlüsselte Block wird normalerweise zur Finalisierung weitergeleitet.

1. Die Auswirkungen auf die Bandbreitenanforderungen des Antragstellers müssten untersucht werden. Antragsteller mit geringer Bandbreite könnten ihre Anforderungen begrenzen, indem sie Beweise vor der Anforderung des Blockkörpers überprüfen oder mit anderen heuristischen Filter- und Smart-Download-Techniken. Dies ist eine offene Frage, aber scheint wahrscheinlich nicht schwieriger zu lösen zu sein als normale MemPool-Gerüchte-Spam-Probleme.↩

Überlegungen

Leistung

Die Leistungseigenschaften der Silent Threshold Encryption sind ziemlich günstig. Hier

n ist die maximale Größe des Ausschusses, den wir unterstützen möchten, und t ist die Schwelle für die Entschlüsselung.

Sowohl die Verschlüsselung als auch die teilweise Entschlüsselung erfolgen in konstanter Zeit. Bei einer einfachen Implementierung dauert die Verschlüsselung weniger als 7 ms - und dies kann parallelisiert werden. Die teilweise Entschlüsselung dauert weniger als 1 ms.

Die Größe des Geheimtextes ist ein konstanter additiver Faktor, 768 Bytes, größer als der Klartext (für jedes n und t).

Die Aggregation von Teilentschlüsselungen (d. h. Entschlüsselung) hängt von der Größe des Ausschusses ab. Bei n=1024 dauert eine naive Implementierung weniger als 200 ms. Wir erwarten, dass sich dies bei n=128 (der Größe des Attestationsausschusses für jeden Slot) um den Faktor 10 verringert und dass die Implementierung weiter optimiert werden kann.

Wichtig ist, dass die Verschlüsselungszeit die Schlüsselleistungsnummer ist, die mit der Relaislatenz verglichen werden muss. Dies ist das, was der Ersteller im „kritischen Pfad“ der Blockproduktion berechnen muss. Sie ist niedriger als die vorhandene Blockverarbeitungsverzögerung des Relais und vermeidet Mehrfach-Hop-Kommunikation.

Datenveröffentlichung

Die stille Schwellwertverschlüsselung ist nicht völlig kostenlos. Sie erfordert eine gemeinsame Referenzzeichenfolge in Form von: (g,g^τ,g^τ2,…,g^τn−t), ähnlich wie beim KZG-Polynom-Commitment-Schema verwendet.

Zusätzlich veröffentlicht jeder Validator mit einem BLS Public Key der Form gsk eine Menge von Gruppenelementen, die wir 'Hinweise' nennen: (g^sk⋅τ,…,g^sk⋅τn−t). Diese Hinweise werden nur benötigt, um öffentliche Schlüssel zu aggregieren und Chiffretexte zu entschlüsseln. Die Verschlüsselung verwendet nur einen konstanten aggregierten öffentlichen Schlüssel.

Zum Zeitpunkt der Abfassung dieses Beitrags gibt es etwa 1 Million Validatoren. Wenn wir n=128 setzen und t=n/2, muss jeder Validator ungefähr 3 KB an Hinweisen veröffentlichen. Das Speichern der Hinweise aller Validatoren erfordert daher 3 GB.

Diese Anforderung wird voraussichtlich erheblich abnehmen mit demAktivierung von MaxEB, was es Validatoren, die mehr als 32 ETH kontrollieren, ermöglicht, größere Guthaben unter demselben Schlüsselpaar zu halten (anstatt sie auf mehrere 32 ETH-Einlagen aufzuteilen). Die Verringerung des Validatoren-Sets, die realisiert wird, ist umstritten. Es scheint möglich, dass wir auf etwa 1 GB herunterkommen könnten.

Schließlich könnte je nach zukünftigen Änderungen an der Konsensarchitektur von Ethereum (z.B. weiteren Reduzierungen der Validator-Set-Größe oder alternativer Finalitäts-Pipelining) die Größe der gespeicherten Hinweise weiter abnehmen.

Lebendigkeit

Ethereum möchte auch unter ungünstigen Netzwerkbedingungen aktiv bleiben. Ein Problem bei diesem Schema besteht darin, dass Blöcke möglicherweise nicht entschlüsselt werden können, weil der festgelegte Anteil des Ausschusses offline ist.

Eine Lösung besteht darin, dem Builder zu ermöglichen, den akzeptablen Bruchteil (𝑡) des Ausschusses für die Entschlüsselung festzulegen. Es besteht ein Kompromiss zwischen Privatsphäre (der Möglichkeit des Entbündelns und des MEV-Diebstahls) und der Wahrscheinlichkeit, dass die Ausschussschwelle online ist. Es maximiert den Umsatz für Builder, ihre Blöcke einzuschließen, anstatt sie auszuforken, daher sollten sie eine optimierte Schwelleneinstellung ermitteln.^[4]

Zusätzlich sollte die Verwendung dieses Verschlüsselungsverfahrens opt-in sein. Unter ungünstigen Netzwerkbedingungen, bei denen keine akzeptabel große Kommission mit ausreichender Konsistenz verfügbar ist, könnten Anbietende und Ersteller auf Relais, Selbstbau oder einen anderen Mechanismus zurückgreifen, der angesichts der Natur der ungünstigen Umgebung bevorzugt wird.

1. Die spezifische Behauptung hier ist, dass es für einen Block des Erbauers negativer EV ist, ausgesondert zu werden (sie erhalten keine Einnahmen daraus), und hoch negativer EV, ausgelagert zu werden. Wenn Sie dem Erbauer die Möglichkeit geben, t in [0,128] auszuwählen, sollten sie natürlich dazu angeregt werden, t hoch genug zu wählen, dass es sehr geringes Risiko für Auslagerung und hohe Wahrscheinlichkeit gibt, zufrieden zu sein (mindestens t Mitglieder des Ausschusses sind online). Einige Blöcke würden wahrscheinlich selbst unter normalen Netzwerkbedingungen ausgelagert werden, aber wir würden darauf hinweisen, dass dies bereits bei Zeitmessspielen passiert, und die Lebendigkeit der Kette akzeptabel bleibt.↩

Nicht verfügbare Blöcke

Alternativ kann das Gremium zwar online sein, aber ein Entwickler kann eine Situation schaffen, in der der Block entweder nicht entschlüsselt werden kann oder nach der Entschlüsselung ungültig ist (z.B. mit betrügerischen Beweisen).

Aus Sicht des Protokolls ist es in Ordnung, diese Blöcke auszuforken. Der umfassendere Validatoren-Set konnte sie einfach nicht bestätigen oder auf Blöcke verweisen. Der beste Weg, mit dieser Art von Fehler umzugehen, besteht wahrscheinlich darin, den Konsensclient auf die Möglichkeit hinzuweisen und ihm zu ermöglichen, auf elegante Weise zu scheitern. Eine weitere Untersuchung darüber, wie genau dies erforderlich wäre.

Marktstruktur

Der gewinnende Bauer kennt den Inhalt des Blocks, bevor andere es erreichen, was einen unfairen Vorteil in nachfolgenden Slots schaffen könnte. Die Attester-Kommission soll jedoch vor Ende des nächsten Slots handeln, und der Großteil des Blockwerts liegt am Ende des Slots, sodass die Auswirkungen dieses Vorteils so minimal wie möglich sein sollten.

Rein kryptografische Beweise

Auf lange Sicht könnte es möglich sein, TEE-Nachweise durch Zero-Knowledge (ZK)-Nachweise zu ersetzen. Derzeit sind ZK-Nachweise zu langsam, aber Fortschritte in der Kryptographie, Software und spezieller Hardware (ASICs) könnten ZK-Nachweisgenerierung letztendlich innerhalb der notwendigen Latenzbeschränkungen machbar machen. Bemerkenswerterweise sind ZK-Nachweise, die Blöcke begleiten, bereits ein Kernstück der langfristigen Roadmap von Ethereum.

Adoption

Bei der aktuellen Größe und Wachstumsrate des Validierer-Sets lohnt sich dieses Schema möglicherweise nicht für die Menge an Daten, die auf L1 veröffentlicht werden müssen. Ethereum plant jedoch bereits, die Anzahl der Validatoren mit MaxEB erheblich zu reduzieren.

Der beste Ansatz wäre wahrscheinlich ein Upgrade zusammen mit oder nach MaxEB, bei dem Konsensclients auf die Möglichkeit verschlüsselter Blocksemantik aufmerksam gemacht werden und Validatoren ermutigt werden, Hinweise zu veröffentlichen. Zum Beispiel könnte nach MaxEB von neu eintretenden Validatoren verlangt werden, Hinweise zu veröffentlichen, und älteren Validatoren könnte ein Anreiz zum Upgrade gegeben werden.

Die Erbauer würden den Mechanismus erst dann verwenden, sobald eine ausreichende Fraktion des Validatorensets ihn übernommen hat, um ausreichend große Ausschüsse zu haben (d.h. sowohl akzeptable Privatsphäre als auch Wahrscheinlichkeit der Entschlüsselung).

Wenn unser Ansatz tatsächlich eine günstige Latenz im Vergleich zum mehrstufigen Relais hat, sollte der Markt ihn ohne die Notwendigkeit, dass das Protokoll die Verwendung erzwingt oder eine spezifische Parametrierung festlegt, übernehmen.

Grund

Relais sind eine der bedeutendsten Quellen der Zentralisierung von Ethereum und schaffen Möglichkeiten für Rent-Seeking und Verzerrungen der geografischen Dezentralisierung des Protokolls.

Wir müssen Relais entfernen und denken, dass dies ein relativ eleganter Weg ist, dies zu tun. Es erfordert Änderungen auf der Konsensschicht, aber kein neues Hardware- oder Schlüsselmaterial ist seitens der Validatoren erforderlich.

Der Nachteil besteht darin, dass es eine komplexe Änderung der Konsensschicht für einen Mechanismus ist, der (falls opt-in, wie vorgeschlagen) möglicherweise vom Markt angenommen oder auch nicht angenommen wird. Allerdings werfen viele potenzielle Änderungen am MEV-Pipeline ähnliche Fragen zur Akzeptanz und zur Ertragsoptimierung auf (z. B. Einschlusslisten). Und es können auch andere zukünftige Anwendungsfälle geben, die davon abhängen, dass das Validator-Set über eine verfügbare Schwellwertverschlüsselungsinfrastruktur verfügt.

Haftungsausschluss:

1. Dieser Artikel ist abgedruckt von [Paradigma]. Alle Urheberrechte gehören dem Originalautor [ Charlie NoyesGuru, Vamsi Policharla]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Gate LearnTeam und sie werden es schnell bearbeiten.
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, Verteilen oder Plagiieren der übersetzten Artikel untersagt.