Dark Pools entwickeln sich schnell zur nächsten Front des dezentralen Finanzsektors von Ethereum (DeFi). Dark Pool-Designs mildern Probleme wie Preisunsicherheit und schlechte Handelsprivatsphäre in On-Chain-Börsen - Probleme, die externe Investoren trotz offensichtlicher Vorteile wie dem Zugang zu rund um die Uhr Liquidität und neuartigen Ertragsgenerierungsmechanismen misstrauisch gegenüber DeFi gemacht haben.

In diesem Artikel geben wir einen Überblick über Dark Pools und untersuchen ihre Rolle im traditionellen Finanzwesen und DeFi. Darüber hinaus erläutern wir die Funktionsweise von krypto-nativen Dark Pools und diskutieren mögliche Hindernisse für eine breitere Akzeptanz von Onchain-Dark Pools.

Einführung: Dark Pools im traditionellen Finanzwesen

Trotz des düsteren und illegalen Klangs sind Dark Pools tatsächlich ein langjähriger Bestandteil des (hoch regulierten) traditionellen Finanzsystems. Unten finden Sie eine Definition eines Dark Pools von Investopedia:

Ein Dark Pool ist ein privat organisiertes Finanzforum oder eine Börse zum Handel mit Wertpapieren. Dark Pools ermöglichen institutionellen Anlegern den Handel, ohne bis nach der Ausführung und Meldung des Handels exponiert zu sein. Dark Pools sind eine Art alternativen Handelssystems (ATS), das bestimmten Investoren die Möglichkeit gibt, große Aufträge zu platzieren und Trades durchzuführen, ohne während der Suche nach einem Käufer oder Verkäufer ihre Absichten öffentlich preiszugeben.

Dark Pools sind bei institutionellen Anlegern, vermögenden Privatpersonen, Hedgefonds, Investmentgesellschaften und anderen Unternehmen beliebt, die große Trades anonym ausführen möchten. Der Wunsch nach anonymen Trades resultiert aus der Sensibilität der Marktpreise für wahrgenommene Nachfrage und Angebot (die durch elektronische Handelsplattformen, die sogar auf schwache Signale schnell reagieren können, weiter erhöht wird). Dies gilt insbesondere für traditionelle Börsen, bei denen das Orderbuch öffentlich ist und Personen Aufträge platzieren oder stornieren können, wie sie möchten.

Das Orderbuch an einer zentralen Limit Orderbuch (CLOB) Börse ist öffentlich. (Quelle)

Angenommen, Alice platziert eine Marktverkaufsorder, um 500 Tesla-Aktien an einer Börse zu verkaufen. Dies ist eine kleine Order, die kaum Auswirkungen auf den Preis der Tesla-Aktien haben wird, die an der Börse angeboten werden. Wenn Alice jedoch eine Order zum Verkauf von 10 Millionen Tesla-Aktien platziert, ist das etwas ganz anderes.

In diesem Szenario signalisiert eine große Verkaufsorder im Orderbuch einen möglichen Rückgang der Nachfrage nach Tesla-Aktien. Sophisticated Handelsfirmen, insbesondere solche, die hochfrequente Handelsalgorithmen (HFT) nutzen, werden wahrscheinlich auf dieses Signal aufmerksam. Sie könnten schnell handeln, indem sie ihre Bestände verkaufen, bevor Alice's Order ausgeführt werden kann, in Erwartung eines Rückgangs des Tesla-Aktienkurses. Folglich könnte der Marktwert der Tesla-Aktien abnehmen, was zu einem schlechteren Ausführungspreis für Alice führen könnte. Wenn Alice keine fortgeschrittenen Handelstechniken verwendet, könnte ihr Handel aufgrund des Preisrückgangs vor Ausführung ihrer Order zu einem Verlust führen.

Das Problem wird durch die Anwesenheit von weiter kompliziert.HFT-Firmendie eigene Algorithmen einsetzen, die in der Lage sind, in Echtzeit auf Aktivitäten an einer zentralen Limit-Orderbuch (CLOB)-Börse zu reagieren. Hier sind einige hypothetische Szenarien:

Frontrunning

Stellen Sie sich vor, Alice, eine Anlegerin, entscheidet sich, eine große Anzahl von Tesla-Aktien an einer traditionellen Börse zu verkaufen. Wenn sie ihren Verkaufsauftrag auf dem Markt platziert, werden die Einzelheiten dieses Auftrags, einschließlich der Größe und Absicht, öffentlich sichtbar für andere Teilnehmer, bevor der Handel abgeschlossen ist. Ein raffiniertes Handelsunternehmen, ausgestattet mit Hochgeschwindigkeits-Handelsalgorithmen, könnte diesen großen Auftrag bemerken und schnell auf diese Informationen reagieren.

Beispielsweise könnte das Handelsunternehmen beschließen, seine eigenen Tesla-Aktien zu verkaufen, bevor Alice' Auftrag ausgeführt wird, in der Erwartung, dass ihr großer Verkaufsauftrag den Aktienkurs senken wird. Dadurch sichert das Unternehmen einen höheren Preis für seine Aktien, bevor der Markt auf Alice' Verkauf reagiert. Sobald Alice' großer Auftrag ausgeführt ist, drückt die Flut an Aktien, die den Markt überschwemmen, den Preis nach unten, und das Handelsunternehmen kann dann die gleiche Aktie zu einem ermäßigten Kurs zurückkaufen und vom Unterschied profitieren.

Dieses Vorgehen, das als Frontrunning bezeichnet wird, nutzt die Sichtbarkeit von Alice's Bestellung aus, um einen finanziellen Vorteil zu Lasten von Alice zu erlangen. Das Ergebnis für Alice ist ein schlechterer Ausführungspreis für ihren Handel, da der Markt negativ reagiert, bevor ihre Bestellung abgeschlossen ist. Frontrunning ist ein erhebliches Problem in traditionellen Finanzsystemen, in denen Orderbücher öffentlich sind und es bestimmten Teilnehmern ermöglichen, auf Informationen zu reagieren, bevor andere die Chance dazu haben.

Angebotsschwund

Lassen Sie uns mit dem Beispiel von Alice fortfahren, aber dieses Mal konzentrieren wir uns auf das Verhalten von Market Makern - Einheiten, die Kauf- und Verkaufsangebote an einer Börse bereitstellen. Angenommen, Alice's großes Verkaufsangebot wird im öffentlichen Orderbuch der Börse sichtbar. Ein Market Maker hatte ursprünglich ein stehendes Angebot, Tesla-Aktien zu je 200 US-Dollar zu kaufen. Beim Anblick von Alice's beträchtlichem Verkaufsangebot könnte der Market Maker vermuten, dass das erhöhte Angebot den Preis der Tesla-Aktien sinken lässt.

Um den Kauf der Aktien zu vermeiden, nur um ihren Wert sinken zu sehen, storniert oder ändert der Market Maker schnell seine Kauforder. Diese Maßnahme, bekannt als Quote Fading, entfernt effektiv Liquidität aus dem Markt. Wenn Alice's Verkaufsorder schließlich ausgeführt wird, gibt es weniger Käufer, und sie muss sich mit einem niedrigeren Preis zufriedengeben - vielleicht 195 $ anstelle von 200 $.

Das unfaire Verblasen von Angeboten benachteiligt Trader wie Alice, indem es Liquiditätsanbietern ermöglicht, ihre Angebote aufgrund von Insider-ähnlichem Wissen über die Trades anderer Teilnehmer anzupassen. Da das Orderbuch an zentralisierten Limit-Orderbuch (CLOB)-Börsen öffentlich ist, können Market Maker eingehende Bestellungen in Echtzeit sehen und entsprechend reagieren. Leider hat Alice keine Möglichkeit, ihren Handel vor dieser Praxis zu schützen, da sie aus der Transparenz des Orderbuchs selbst resultiert.

Warum Dark Pools?

Dark Pools entstanden im traditionellen Finanzwesen als Reaktion auf die oben genannten Probleme. Im Gegensatz zu einer "beleuchteten" Börse führen Dark Pools Trades außerhalb öffentlicher Börsen wie der NYSE (New York Stock Exchange) und der Nasdaq aus. Die von Käufern und Verkäufern eingereichten Aufträge werden direkt abgeglichen, und niemand außer dem zentralen Betreiber hat Informationen über das Orderbuch.

Noch wichtiger ist, dass jeder, der über ein Dark Pool handelt, nur über seine eigenen Aufträge und den Clearing-Preis informiert ist. Es ist unmöglich, etwas über andere Benutzer zu wissen - wie ihre Identitäten und Größe/Wert von Aufträgen - selbst beim Handel mit Gegenparteien, es sei denn, der zentrale Betreiber gibt Informationen preis.

Dies hat mehrere Auswirkungen für Personen, die mit minimalem Risiko von Marktschwankungen handeln möchten. Insbesondere können Händler große Trades durchführen, ohne ihre Absicht, eine bestimmte Aktie zu kaufen oder zu verkaufen, öffentlich zu machen und den Einfluss eines Trades auf den Aktienmarkt zu verringern. Dies erhöht die Gewissheit, dass ein bedeutender Handel weder Front Running noch Kursfading erleiden wird und der Verkäufer (oder Käufer) den besten verfügbaren Preis erhält.

Angenommen, Alice beschließt, 10 Milliarden Tesla-Aktien in einem Dark Pool zu verkaufen und setzt einen Angebotspreis von 1 $ pro Aktie fest. Der Dark Pool identifiziert und gleicht Alice' Auftrag mit Bobs entsprechendem Auftrag zum Kauf von 10 Milliarden Tesla-Aktien zur gleichen Bewertung ab. Wenn der Handel ausgeführt wird, bleibt die Öffentlichkeit bis nach der Abwicklung unwissend über die Transaktionsdetails. Erst dann erfährt der Markt, dass 10 Milliarden Aktien den Besitzer gewechselt haben, ohne jedoch die Identitäten des Käufers oder Verkäufers zu kennen, was die Handelsabsichten und -strategien beider Parteien schützt.

Wir können sehen, wie der Handel über einen Dark Pool die Interessen von Alice schützt und die Ausführungsqualität und die Sicherheit des Clearingpreises erhöht:

• Bob weiß nichts über Alice und weiß nur, dass er 10 Milliarden Tesla-Aktien für 10 Milliarden US-Dollar erhalten hat, und jemand 10 Milliarden US-Dollar für diese Aktien erhalten hat. Bob kann das Angebot nicht verblassen lassen, weil das Orderbuch verborgen ist – Bob muss tatsächlich Aktien kaufen, um zu wissen, dass jemand 10 Milliarden Aktien zu verkaufen hat (diese Information ist bekannt, sobald die Bestellung abgeglichen ist).
• Das Vordrängeln von Alice's Handel ist schwierig, da der zentrale Betreiber Einzelheiten zu ausstehenden Kauf- und Verkaufsaufträgen und Markttiefe verschleiert. Die einzige Möglichkeit, dass Alice's Handel öffentlich wird, besteht darin, dass der Administrator des Dark Pools die Informationen mit externen Parteien teilt (Das ist illegal, jedoch).

Heute gibt es Dutzende von Pools in Betrieb und Schätzungen legen nahe, dass 40 Prozent der elektronischen Trades werden über Dark Pools abgewickelt.Die wachsende Beliebtheit von Dark Pools hat sich mit wachsende Regulierung, insbesondere angesichts des privilegierten Zugangs von Pool-Betreibern zu Informationen über ausstehende Aufträge (Credit Suisse und Barclays wurden 2016 mit einer Geldstrafe von insgesamt 150 Millionen US-Dollar belegt, weil sie Informationen über Dark-Pool-Geschäfte an externe Parteien weitergegeben hatten).

Dark Pools im DeFi

(Quelle)

Wenn Dark Pools in TradFi notwendig sind, sind sie aufgrund der inhärenten Transparenz von Blockchain-Systemen und der damit verbundenen Herausforderungen zur Wahrung der Handelsprivatsphäre und der Ausführungsqualität in DeFi möglicherweise noch wichtiger. Dies gilt insbesondere für dezentrale Börsen (DEXes), die elektronische Trades ermöglichen und ähnliche Funktionen wie traditionelle Börsen bieten.

• Archivknoten können die Blockchain nach Informationen über historische Transaktionen abfragen, die mit einem AMM-Pool interagieren, und diese mit der On-Chain-Aktivität in Verbindung bringen, die mit einer bestimmten Adresse verbunden ist. Dadurch wird es für jeden einfach, Handelsstrategien zu kopieren, die von Alpha-Tradern eingesetzt werden.
• Der Mempool, der Informationen über ausstehende Transaktionen speichert, ist öffentlich und für jeden, der mit einem Full Node verbunden ist, zugänglich. Dies macht DEX-Benutzer anfällig für das Quote-Fading-Problem, bei dem Menschen Kauf-/Verkaufsaufträge in Reaktion auf einen großen Handel stornieren können, der in der Lage ist, den Markt zu bewegen, und zu einer schlechtestmöglichen Preisausführung für Händler führt.
• Der Post-Zustand eines DEX kann von jedem, der den Mempool beobachtet, trivial berechnet werden, was die Tür für eine böswillige MEV-Extraktion (Maximum Extractable Value) durch Validatoren und MEV-Bots öffnet. Diese Akteure können die Auswirkungen eines Handels auf den DEX-Pool beobachten und entscheiden, die Transaktion vorzuziehen oder in ein Sandwich zu verschieben, wenn die Simulation von Zustandsänderungen potenzielle Gewinne aufzeigt. (Die Tatsache, dass Benutzer Transaktionen "im Klartext" senden, um sie in einen Block aufzunehmen, verschärft das Problem.)
• Der DEX-Handel könnte scheitern, wenn ein Blockproduzent absichtlich die Transaktion eines Benutzers zensiert. Da Kontoinformationen öffentlich verfügbar sind, können Validatoren Profile für spezifische Adressen erstellen und sich dafür entscheiden, diese Gegenparteien bei der Verarbeitung von Transaktionen zu diskriminieren.
• Validatoren können Informationen über eine Transaktion sehen und entscheiden, sie aus dem nächsten Block auszuschließen. Benutzer können Transaktionsdetails nicht vor Validatoren verschleiern oder die Absicht, Tokens zu kaufen/verkaufen, verheimlichen.

(Quelle)

Diese Probleme haben dazu geführt, dass herkömmliche DEXes bei großen Walen und institutionellen Händlern, die sensibel auf Preis- und Ausführungsqualität reagieren, in Ungnade gefallen sind. DeFi ist jedoch das größte Opfer – DEXes können trotz mehrerer Qualitäten wie grenzenloser Transaktionen und vertrauenswürdiger, transparenter Ausführung für Benutzer die TradFi-Börsen nicht ersetzen. Neue Alternativen wie CowSwapundUniswapXscheinen das Problem gelöst zu haben, aber stellen die Notwendigkeit dar, einem zentralen Betreiber zu vertrauen, ähnlich wie bei herkömmlichen Dark Pools. Während Dark Pools in TradFi privat sind, da Kontoinformationen vor anderen verborgen sind, bleibt diese Datenbank für die Bank oder den Betreiber zugänglich, was sie anfällig für Missbrauch oder Lecks macht, wenn Administratoren weniger kompetent oder skrupellos sind.

Die Integration von Dark Pools in die Blockchain ist nicht nur möglich, sondern stellt einen optimalen Ansatz für den Aufbau dezentraler Handelsplattformen dar, die eine qualitativ hochwertige Ausführung ohne übermäßige Abhängigkeit von zentralen Betreibern bieten. Obwohl die inhärente Transparenz von Blockchains - bei der jeder die Rechenrichtigkeit durch das Ausführen eines Knotens überprüfen kann - scheinbar im Widerspruch zur Funktionalität von Dark Pools steht, kann diese Herausforderung bewältigt werden. Die Lösung liegt in der privacy-enhancing technology (PET), einem kryptografischen Ansatz, der die Verheimlichung von Informationen ermöglicht und gleichzeitig die Integrität von Ledger-Updates gewährleistet. Dadurch können wir die Überprüfbarkeit der Blockchain nutzen und gleichzeitig die für den Betrieb von Dark Pools erforderlichen Datenschutzfunktionen einführen.

Es mag unmöglich erscheinen, dezentralisierte Dark Pools aufzubauen, da Blockchains darauf ausgelegt sind, transparent und abfragbar zu sein. Dies ist tatsächlich das, was Blockchains besser macht als reguläre Datenbanken: Jeder kann einen Knoten ausführen und überprüfen, dass Änderungen an der Datenbank korrekt berechnet werden. Aber wir können diese Einschränkung umgehen, indem wir Kryptografie nutzen - speziell privacy-enhancing technology (PET) -, die es ermöglicht, Informationen zu verbergen, während sicherstellen, dass Aktualisierungen des Hauptbuchs mit den Regeln übereinstimmen.

Wie funktionieren Dark Pools?

Es gibt keinen einheitlichen Weg, um einen Onchain-Dunkelpool zu erstellen. Alle Krypto-Dunkelpools haben jedoch eine gemeinsame Eigenschaft: Sie verwenden verschiedene kryptografische Mechanismen, um Informationen über Onchain-Trades zu verbergen und die Ausführungsqualität für Benutzer zu erhöhen.

Multiparty-Berechnung (MPC), Zero-Knowledge-Beweise, Schwellenverschlüsselung, vollständig homomorphe Verschlüsselung (FHE) und vertrauenswürdige Ausführungsumgebungen (TEEs) sind einige Grundlagen, die Mechanismusdesigner bei der Arbeit an krypto-nativen Dark Pools zur Verfügung stehen. Das Ziel in jedem Fall ist es, Garantien für den Handelsdatenschutz zu gewährleisten, ohne Vertrauensannahmen zu erhöhen oder das System anfällig für Manipulationen zu machen.

Renegade, Tristero, und Railgunsind Beispiele für Onchain-Dark-Pools im Ethereum-Ökosystem. Wir werden kurz jeden dieser Protokolle durchgehen, um einen Überblick darüber zu geben, wie Onchain-Dark-Pools in der Praxis funktionieren. Dieser Artikel konzentriert sich auf Renegade und untersucht sein Design sowie den Ansatz des Protokolls zum Schutz von Informationen über Trades, die von Marktteilnehmern durchgeführt werden.

Renegade: Beschleunigung des privaten DeFi mit modernster Kryptographie

Renegade ist ein dezentraler, datenschutzerhaltender Dark Pool, der entwickelt wurde, um kritische Schwachstellen in der bestehenden dezentralen Finanzhandelslandschaft (DeFi) zu beheben. Durch den Einsatz fortschrittlicher kryptografischer Techniken wie Zero-Knowledge-Beweisen (ZKPs) und Mehrparteienberechnungen (MPC) ermöglicht es Renegade den Benutzern, Bestellungen sicher zu platzieren, abzugleichen und abzurechnen, ohne ihre Kontostände, Handelsabsichten oder Strategien Dritten offenlegen zu müssen. Im Gegensatz zu traditionellen DEXes, bei denen Orderbuchdaten öffentlich geprüft werden können, verschlüsselt Renegade alle Wallet- und Auftragsinformationen, um sicherzustellen, dass Trades privat stattfinden und manipulationssicher sind.

Im Kern ermöglicht Renegade den Benutzern, vertrauensloses, onchain-Handeln mit derselben Präzision und Ausführungsqualität wie zentralisierte Börsen zu erreichen, während gleichzeitig die erforderlichen Datenschutzgarantien zum Schutz vor Front-Running, Quote Fading und anderen ausbeuterischen Praktiken gewährleistet werden. Durch die Einführung eines einzigen globalen Merkle-Baums zur Zustandsverwaltung behält Renegade die Vorteile der Blockchain-Transparenz wie Überprüfbarkeit und Unveränderlichkeit bei, während sensitive Handelsdetails vor den Augen der Öffentlichkeit geschützt werden.

Lösung der Probleme der aktuellen DeFi-Systeme

Das Design von dezentralen Börsen (DEXes) heute - basierend auf automatisierten Marktmachern (AMMs) oder zentralen Limit-Order-Büchern (CLOBs) - führt zu kritischen Schwachstellen, die alle Teilnehmer betreffen, von normalen Benutzern bis hin zu institutionellen Händlern. Diese Probleme entstehen, weil Transaktionen und Aufträge als Klartext auf transparenten Blockchains übertragen werden. Während Transparenz grundlegend für vertrauenswürdige Verifizierung ist, werden Trader auch schädlichen Praktiken wie Front-Running, Quote Fading und Adressprofilierung ausgesetzt.

Sowohl für kleine Händler als auch für große Investoren führen diese Schwachstellen zu einer schlechten Handelsausführung, finanziellen Verlusten und einem geringeren Vertrauen in dezentrale Finanzierung. Renegade beseitigt diese Probleme, indem kryptografische Techniken eingeführt werden, die die Privatsphäre wahren, ohne die Integrität dezentraler Systeme zu gefährden.

Maximal extrahierbarer Wert (MEV)

Durchschnittlicher Gesamt-MEV-Gewinn (30-Tage-Datensatz) entsprechend EigenPhi

Wenn Aufträge und Transaktionen im Mempool sichtbar sind, werden sie anfällig für Manipulationen durch Blockproduzenten (in Layer 1) oder Sequenzer (in Layer 2). Diese Akteure können Transaktionen neu ordnen, vordrängeln oder nachdrängeln, um Profit zu erzielen. Beispielsweise ermöglicht es bösartigen Akteuren, eine große Kauf- oder Verkaufsorder zu beobachten und ihre Transaktionen mit höheren Gasgebühren zuerst auszuführen (vordrängeln) oder sofortige Möglichkeiten nach der Ausführung auszunutzen (nachdrängeln). Diese Form von MEV betrifft alle DEX-Designs, unabhängig davon, ob sie eine AMM- oder CLOB-Architektur verwenden.

Handelstransparenz

Die Transparenz von Blockchain-basierten Orderbüchern macht Händler sowohl prä- als auch post-trade Risiken ausgesetzt:

• Vorhandelrisiken: In offenen Orderbuchsystemen signalisieren öffentlich sichtbare Aufträge die Absicht der Händler und ermöglichen es Gegnern, Strategien anzupassen. Dies kann zu manipulativen Taktiken führen, wie z.B. dem Zitieren von Fading, bei dem Liquiditätsanbieter ihre Aufträge zurückziehen, um eingehende Trades auszunutzen, was zu Schlupf und einer beeinträchtigten Ausführungsqualität führen kann.
• Post-Trade-Risiken: Sobald ein Handel ausgeführt wird, werden seine Einzelheiten, einschließlich Handelsstrategien und -muster, dauerhaft in der Blockchain aufgezeichnet. Bösartige Akteure oder Konkurrenten können diese historischen Daten analysieren, um zukünftige Trades vorherzusagen und auszunutzen. Diese fehlende Privatsphäre nach dem Handel macht Händler, insbesondere institutionelle Anleger, anfällig für Ausbeutung.

Indem sie diese zu einer breiteren Kategorie kombinieren, löst Renegade den gesamten Lebenszyklus von Handelstransparenzproblemen mit kryptografischen Lösungen, die eine Vor-Handels-Privatsphäre und eine sichere Post-Handels-Abwicklung gewährleisten.

Adressbasiertes Profiling

In transparenten Blockchain-Systemen wird die Adresse der initiierenden Partei bei jeder Transaktion offengelegt. Angreifer können diese Daten analysieren, um detaillierte Profile zu erstellen, die Handelsverhalten mit bestimmten Wallets verknüpfen. Diese Profilerstellung ermöglicht diskriminierende Praktiken wie das Anbieten schlechterer Preise oder die gezielte Ansprache bestimmter Benutzer. Während Blockchain-Identitäten pseudonym sind, können anspruchsvolle Analysen Adressen mit realen Entitäten oder Verhaltensmustern korrelieren, was diese Schwachstellen weiter verschärft.

Renegades datenschutzorientiertes Design stellt sicher, dass Benutzeridentitäten und -strategien während des Handelsprozesses geschützt bleiben und sowohl Einzelhandels- als auch institutionelle Teilnehmer geschützt werden.

Im Kern dieser Probleme liegt die unvermeidliche Transparenz von Blockchains. Während Transparenz vertrauenswürdige Verifizierung und Unveränderlichkeit sicherstellt - kritische Qualitäten für dezentrale Systeme - werden auch sensible Details über die Benutzeraktivität offengelegt. Jeder Handel, jede Aktualisierung des Kontostands oder ausstehende Transaktion wird zu öffentlichen Informationen, die gegnerische Akteure analysieren, manipulieren oder zum Profit ausbeuten können. Dies schafft ein System, in dem Benutzer Herausforderungen wie MEV-Extraktion, Handelsmanipulation und adressenbasiertes Profiling gegenüberstehen, die alle die Ausführungsqualität beeinträchtigen und das Vertrauen in dezentrale Märkte untergraben.

Um diese Probleme zu lösen, ersetzt Renegade Transparenz durch kontrollierte Privatsphäre durch die kombinierte Verwendung von Zero-Knowledge-Proofs (ZKPs) und Multiparty Computation (MPC). ZKPs stellen sicher, dass Trades gültig sind, Guthaben ausreichen und Protokollregeln ohne Offenlegung des Wallet-Inhalts oder der Transaktionsdetails durchgesetzt werden. Gleichzeitig ermöglicht MPC eine sichere Auftragsabwicklung, bei der mehrere Parteien zusammenarbeiten, um Handelsübereinstimmungen zu finden, ohne Eingaben oder sensible Informationen preiszugeben.

Zusammen bilden diese Techniken ein nahtloses System, in dem Trades privat bleiben, die Ausführung nachvollziehbar ist und Auftragsdetails während des gesamten Lebenszyklus verborgen bleiben. Dies beseitigt die inhärenten Schwachstellen transparenter Blockchains und bewahrt gleichzeitig Dezentralisierung und vertrauenslose Validierung.

Mit einem klaren Verständnis der Probleme, die Renegade löst, und seinem Ansatz zur Privatsphäre tauchen wir ein in die Funktionsweise des Systems, um sicheren, privaten und fairen Handel zu ermöglichen.

Wie funktioniert Renegade unter der Haube?

Renegade erfindet den dezentralen Handel neu, indem es fortschrittliche kryptographische Techniken integriert, die die Grenzen von Transparenz, Privatsphäre und Fairness im DeFi neu definieren. Indem es die Einschränkungen konventioneller dezentraler Börsen anspricht, führt Renegade einen innovativen Ansatz ein, der Datenschutztechnologien mit vertrauenslosem, On-Chain-Handel verbindet.

In diesem Abschnitt werfen wir einen genaueren Blick auf die einzigartigen architektonischen Komponenten, die Renegade antreiben. Wir werden erkunden:

• Commitment-Baum und Wallet-Design: Wie Benutzerwallets vollständig off-chain und privat bleiben, durch kryptografische Verpflichtungen gesichert und durch eine ausgeklügelte Schlüsselhierarchie verwaltet werden.
• Relayer und Super-Relayer: Die Rolle der Relayer bei der sicheren Handelsabstimmung und -ausführung sowie deren Integration mit delegierten Wallet-Berechtigungen.
• MPC-Matching-Engine: Renegades bahnbrechender Multi-Party-Computation-Mechanismus mit zwei Parteien, der eine private, vertrauenslose Handelsabstimmung gewährleistet.
• Kollaborative SNARKs: Wie atomare Abrechnungen durch die nahtlose Integration von Zero-Knowledge-Beweisen mit Multi-Party-Computing erreicht werden.
• Leistung und Skalierbarkeit: Eine Diskussion über die Abwägungen bei den Designentscheidungen von Renegade und wie seine Architektur die Balance zwischen Privatsphäre, Dezentralisierung und Effizienz herstellt.

Durch die Nutzung dieser Innovationen löst Renegade nicht nur die kritischen Mängel der bestehenden DEX-Modelle, sondern legt auch den Grundstein für eine sicherere, privatere und gerechtere dezentrale Handelsumgebung.

Renegades Wallets und der Commitment-Baum

Renegade führt ein Zustandsverwaltungsmodell ein, das Privatsphäre und Überprüfbarkeit priorisiert. Im Kern verwendet das System einen Commitment Tree, einen nur anhängbaren globalen Merkle-Baum, der kryptografische Darstellungen (Commitments) von Benutzer-Wallets speichert. Dieses Design gewährleistet, dass der Inhalt von Wallets vollständig privat bleibt und gleichzeitig die vertrauenslosen Garantien von dezentralisierten Systemen aufrechterhält.

Im Gegensatz zu traditionellen dezentralen Börsen (DEXs), bei denen Wallet-Daten on-chain sichtbar sind, speichert Renegade alle Wallet-Informationen off-chain und ermöglicht es den Benutzern, ihre Guthaben, Aufträge und Transaktionshistorie sicher zu verwalten, ohne sensible Details preiszugeben. On-chain werden diese Wallets ausschließlich durch Verbergen und Binden von Verpflichtungen dargestellt, kryptografische Hashes, die den Inhalt des Wallets verschleiern und gleichzeitig sicherstellen, dass sie nicht manipuliert oder falsch wiederverwendet werden können.

Eine Analogie: Wallets als Mini-Rollups

Um die Architektur von Renegade besser zu verstehen, können wir eine Parallele zu Ethereum Rollups ziehen. In einem Rollup werden Transaktionen außerhalb der Chain ausgeführt, wo Zustandsänderungen privat erfolgen und nur der Zustandsroot, eine kryptografische Darstellung des kumulativen Zustands des Rollups, periodisch an Ethereum übermittelt wird. Zusammen mit diesem Zustandsroot wird ein Zero-Knowledge-Beweis (ZKP) bereitgestellt, um zu überprüfen, dass der Zustandsübergang den Regeln des Rollup-Protokolls entspricht, ohne Details der Transaktion preiszugeben.

Renegade Wallets funktionieren auffallend ähnlich:

• Off-Chain-Ausführung: Alle Brieftaschenoperationen wie Auftragsplatzierung, Kontostandsaktualisierungen und Handelsausführungen erfolgen off-chain. Diese Aktualisierungen spiegeln sich im privaten Zustand der Brieftasche wider, der für externe Beobachter, einschließlich Ethereum, nicht zugänglich ist.
• On-Chain-Verpflichtung: Nachdem der Zustand des Wallets aktualisiert wurde, wird die neue Verpflichtung dem Verpflichtungsbaum hinzugefügt. Diese Verpflichtung dient als kryptografische Zusammenfassung der neuen Kontostände, Aufträge und aller Änderungen, die während des Aktualisierungsprozesses vorgenommen wurden. Die Aktualisierung wird von einem ZKP begleitet, der sicherstellt, dass der Übergang vom alten Wallet-Zustand zum neuen Zustand gültig ist.

Diese Ähnlichkeit verdeutlicht, wie Renegade Wallets wie Mini-Rollups funktionieren. Sie verarbeiten unabhängig voneinander Zustandsänderungen off-chain, während sie sich auf den Commitment-Baum verlassen, um ihren Zustand mit dem breiteren System zu synchronisieren. Dieser Prozess ist vor allem darauf ausgerichtet, die Privatsphäre zu verbessern, anstatt die Skalierbarkeit zu steigern, indem Wallet-Daten undurchsichtig und für alle externen Beobachter unlesbar gehalten werden.

Commit-reveal-Schema für Wallet-Updates

Jede Operation an einer Geldbörse in Renegade folgt einem Commit-Reveal-Schema, das Privatsphäre und Korrektheit während des Aktualisierungsprozesses gewährleistet. Dieser Mechanismus ermöglicht es Benutzern, ihre Geldbörsen zu bearbeiten, während die Integrität des Systems erhalten bleibt.

1. Offenlegen der alten Brieftasche: Der Benutzer reicht einen Merkle-Beweis ein, der zeigt, dass seine frühere Brieftaschenverpflichtung als Blatt im Commitment-Baum vorhanden ist. Wesentlich dabei ist, dass dieser Offenlegungsprozess keine Details über den Inhalt der Brieftasche preisgibt und somit die vor dem Handel gewährleistete Privatsphäre von Renegade bewahrt. Das System erfährt lediglich, dass die Brieftaschenverpflichtung gültig ist und im Baum enthalten ist.
2. Berechnung von Nullifiern: Um die Wiederverwendung alter Wallet-Zustände zu verhindern, erfordert Renegade die Berechnung von zwei Nullifiern für jedes Wallet: einen Wallet-Spend-Nullifier und einen Wallet-Match-Nullifier. Diese Nullifiere werden aus dem Commitment des alten Wallets und einem privaten Zufallswert abgeleitet, um Einzigartigkeit zu gewährleisten.

Die Nullifier werden dann zusammen mit dem neuen Wallet-Commitment eingereicht, um sicherzustellen, dass das alte Wallet nicht wiederverwendet werden kann.

1. Verpflichten Sie sich zur neuen Brieftasche: Der Benutzer generiert einen neuen Brieftaschenstatus, der die gewünschten Aktualisierungen widerspiegelt - wie Auftragsplatzierungen, Bilanzanpassungen oder Handelsabrechnungen - und berechnet sein kryptografisches Bekenntnis. Ein ZKP wird vorgelegt, um Folgendes nachzuweisen:
   • Das alte Wallet-Commitment existiert im Commitment-Baum.
   • Die Nullifizierer werden korrekt berechnet und sind einzigartig.
   • Der Übergang vom alten Wallet-Zustand zum neuen hält sich an die Protokollregeln (z. B. keine unbefugten Bilanzsteigerungen).
   • Der Benutzer besitzt die geheimen Schlüssel, die erforderlich sind, um das Update zu autorisieren.

Sobald der Nachweis verifiziert und die Nullifier als unbenutzt bestätigt sind, markiert der Smart Contract die Nullifier der alten Brieftasche als 'ausgegeben' und fügt das neue Commitment in den Commitment-Baum ein.

(Quelle: Renegade-Dokumentation)

Die auf Verpflichtungen basierende Architektur von Renegade stellt sicher, dass sensible Handelsdaten jederzeit sicher bleiben. Die versteckende und bindende Natur der Wallet-Verpflichtungen garantiert, dass kein externer Beobachter auf den Inhalt der Wallet schließen kann, selbst wenn er Zugriff auf den Verpflichtungsbaum hat. Darüber hinaus verhindert die in die Berechnung der Wallet-Verpflichtung einbezogene Zufälligkeit, dass Angreifer Regenbogentabellen erstellen, um gemeinsame Wallet-Zustände wie Wallets mit Nullguthaben oder Bestellungen zu identifizieren.

Durch die Kombination dieser kryptografischen Mechanismen mit Zero-Knowledge-Beweisen erreicht Renegade ein Design, bei dem Wallet-Operationen zwar überprüfbar, aber für externe Parteien unsichtbar sind. Dies gewährleistet, dass das Protokoll die Privatsphäre vor dem Handel aufrechterhält und Benutzer vor feindlichen Strategien wie Front-Running und Angebotsmanipulation schützt.

Schlüsselhierarchie und Relayer-System

Renegade setzt auf Relayer, um wichtige Vorgänge wie Auftragsabgleich und Abrechnung zu erleichtern, so dass Benutzer effizient handeln können, ohne die Sicherheit zu beeinträchtigen. Um dies zu erreichen, implementiert das Protokoll eine robuste Schlüsselhierarchie, ein kryptographisches Framework, das Kontroll- und Sichtberechtigungen trennt und sicherstellt, dass Benutzer die Kontrolle über ihre Vermögenswerte behalten, während sie bestimmte Aufgaben an Relayer delegieren. Dieses System sichert nicht nur sensible Wallet-Informationen, sondern vereinfacht auch die Interaktionen mit Relays, was den privaten und dezentralen Handel praktischer und benutzerfreundlicher macht.

Funktionsweise der Schlüsselhierarchie

Obwohl das aktuelle Design der Schlüsselhierarchie von Renegade über die ursprüngliche Beschreibung im Whitepaper hinaus weiterentwickelt wurde, bleiben die Kernprinzipien bestehen. Wenn eine Brieftasche zum ersten Mal erstellt und dem Commitment-Baum hinzugefügt wird, enthält sie fünf verschiedene Geheimnisse, die gemeinsam ihre Funktionalität definieren. Diese Geheimnisse sind:

• Root-Schlüsselpaar: Das Root-Schlüsselpaar ist ein ECDSA-Schlüsselpaar (secp256k1-Kurve), das mit einem Standard-Ethereum-Privatschlüssel identisch ist. Es ist der maßgebliche Schlüssel und gewährt die volle Verwahrung über das Wallet. Alle Operationen, die den Wallet-Zustand ändern - wie Einzahlungen, Auszahlungen, Auftragserteilung oder Stornierungen - erfordern eine Signatur des geheimen Root-Schlüssels. Um maximale Sicherheit zu gewährleisten, wird der Root-Schlüssel streng auf der Client-Seite aufbewahrt und niemals mit externen Parteien, einschließlich Relays, geteilt.
• Match-Skalar: Der Match-Skalar ist ein geheimer Skalarwert, der über die bn254-Kurve definiert ist und als Mechanismus dient, mit dem Relayer autorisiert sind, Übereinstimmungen zur Abrechnung an den Smart Contract oder Basis-Layer zu senden. Im Gegensatz zu herkömmlichen asymmetrischen Schlüsselpaaren ist der Match-Skalar ein einzelner geheimer Wert, den Relayer verwenden, um Zero-Knowledge-Proofs (ZKPs) zu generieren, die ihr Wissen über das Vorbild des Skalars unter dem Poseidon-Hash beweisen. Dadurch wird sichergestellt, dass Relayer nur Übereinstimmungen abrechnen können, die explizit durch die Konfiguration des Wallets autorisiert sind. Darüber hinaus ist der Match-Skalar mit vordefinierten Gebühren in der Wallet gekoppelt, so dass Benutzer die genauen Gebühren angeben können, die Relayer für ihre Dienste erheben können.
• Symmetrischer API-Schlüssel: Der symmetrische API-Schlüssel ist ein außerhalb des Protokolls verwendetes Werkzeug zur Authentifizierung von Interaktionen zwischen dem Benutzer und dem Relayer. Er ermöglicht es Relays, Echtzeit-Updates wie Wallet-Änderungen oder Bestellstatus an den Benutzer zu übertragen, ohne die Sicherheit des Wallets oder seine kryptografische Integrität zu beeinträchtigen. Obwohl er nicht direkt mit Wallet-Operationen verbunden ist, erleichtert dieser Schlüssel die nahtlose Kommunikation und verbessert das gesamte Handelserlebnis.
• Blinder Seed und Share Seed: Der Blinder Seed und Share Seed sind wesentliche Komponenten, die es Relays ermöglichen, Wallet-Informationen sicher zu entschlüsseln und zu verarbeiten. Diese Seeds fungieren als View-Keys und gewähren Relays die Möglichkeit, auf den privaten Zustand des Wallets zuzugreifen. Als Seeds werden sie jedoch dynamisch in Werte gehasht, die sich mit jeder Transaktion ändern. Dadurch wird sichergestellt, dass die Blinder- und Share-Werte spezifisch für die aktuelle Operation sind und eine Wiederverwendung oder unbeabsichtigten Zugriff verhindert wird.

Der Blinder-Samen ist dafür verantwortlich, die Brieftasche on-chain zu indizieren, indem er eine kryptografische Hash-Kette erstellt, die Brieftaschenzustände verknüpft. Dies stellt sicher, dass die Präsenz der Brieftasche im Commitment-Baum nachweisbar bleibt, ohne ihre Inhalte offenzulegen.

Der Share Seed wird verwendet, um "geheime Shares" von Wallet-Daten zu konstruieren und dem Relayer die Zusammenarbeit mit dem MPC-Matching-Engine während des Order-Matching-Prozesses zu ermöglichen. Diese Integration ermöglicht es Relays, ihre Funktionen sicher auszuführen und sensible Details über das Wallet nicht an das breitere Netzwerk preiszugeben.

Wie Relayer in Renegade funktionieren

Relayer in Renegade fungieren als wichtige Vermittler, die es dem Protokoll ermöglichen, seine privatsphäreerhaltende und dezentrale Natur beizubehalten und gleichzeitig ein reibungsloses Handelserlebnis zu bieten. Als Vermittler und Ermöglicher zugleich werden Relayer durch die Schlüsselhierarchie befähigt, bestimmte Operationen im Auftrag des Benutzers durchzuführen, ohne die Wallet-Verwahrung oder Privatsphäre zu gefährden. Durch die Nutzung der im Wallet eingebetteten Geheimnisse können Relayer Wallet-Informationen entschlüsseln, ausstehende Aufträge identifizieren und Übereinstimmungen an den Smart Contract zur Abwicklung übermitteln – und das alles unter strenger kryptografischer Garantie.

Die Beziehung zwischen Relays und der Schlüsselhierarchie basiert auf einem klaren Delegationsmodell. Benutzer teilen nur die notwendigen Geheimnisse - wie den Übereinstimmungsskalar, den Blindseed und den Shareseed - mit dem Relay. Diese Geheimnisse geben dem Relay die Möglichkeit, Wallet-Daten sicher anzuzeigen und zu verarbeiten. Der Übereinstimmungsskalar ermöglicht es Relays, Übereinstimmungen zu autorisieren und abzuschließen, indem sie Kenntnis des Poseidon-Hash-Vorbilds durch Zero-Knowledge-Beweise (ZKPs) nachweisen. Der Blindseed und der Shareseed stellen sicher, dass Relays auf Wallet-Daten zugreifen können, ohne sie externen Beobachtern preiszugeben oder unbefugte Kontrolle zu erlangen. Diese Aufteilung der Zuständigkeiten gewährleistet, dass Relays die Werkzeuge haben, um ihre delegierten Aufgaben zu erfüllen, ohne die allgemeine Kontrolle oder Sicherheit des Benutzers zu gefährden.

Ein wesentlicher Vorteil dieses Systems besteht darin, dass eine feingliedrige Delegierung ermöglicht wird. Relayer sind auf die von den gemeinsamen Geheimnissen explizit zugelassenen Rollen beschränkt. Beispielsweise können Relayer Wallet-Details anzeigen und ausstehende Bestellungen abgleichen, jedoch keine Bestellungen ändern, abheben oder stornieren, da der Wurzelschlüsselpaar - der ultimative Schlüssel des Verwahrers - beim Benutzer verbleibt. Dieses Design gewährleistet, dass Benutzer die volle Kontrolle über ihre Wallets behalten, während spezifische Aufgaben zur Effizienzsteigerung ausgelagert werden.

Relayer bringen auch erhebliche Bequemlichkeit in den Handelsprozess, indem sie die Rechenkomplexität des Abgleichs von Aufträgen mit dem MPC-Matching-Engine und die Sicherstellung der Gültigkeit dieser Abgleiche durch gemeinsame SNARKs behandeln. Dieser Mechanismus ermöglicht es den Relays, einen Großteil der technischen Last von den Benutzern abzuladen, während sie die strengen Vorhandels- und Nachhandels-Privatsphäre-Garantien von Renegade aufrechterhalten. Durch das sichere Management dieser Operationen schützen die Relays nicht nur sensible Wallet-Details während des Auftragsabgleichs und der Abwicklung, sondern erleichtern auch viele der typischerweise mit privatsphäreerhaltenden Systemen verbundenen UX-Herausforderungen. Ihre Fähigkeit, Echtzeit-Updates über den symmetrischen API-Schlüssel bereitzustellen, verbessert die Benutzererfahrung weiter und gewährleistet, dass Benutzer über ihre Trades und Wallet-Status informiert bleiben, ohne die Sicherheit zu gefährden.

In der Praxis schafft dieses System eine äußerst flexible und sichere Handelsumgebung. Benutzer können ihre Geldbörsen für längere Zeiträume an Relayer delegieren und ihnen so dauerhaften Zugriff auf Match-Aufträge gewähren, ohne wiederholt neue Schlüssel teilen zu müssen. Gleichzeitig können Benutzer den Zugriff des Relayers jederzeit widerrufen, indem sie eine neue Geldbörse erstellen und ihre Vermögenswerte übertragen, was die Delegation effektiv zurücksetzt. Dieser Mechanismus bietet eine Balance zwischen langfristiger Bequemlichkeit und kurzfristiger Anpassungsfähigkeit und richtet sich gleichermaßen an Gelegenheitshändler und sicherheitsbewusstere Teilnehmer.

Durch die Integration von Relayers in seine Architektur erreicht Renegade eine seltene Kombination aus Dezentralisierung, Datenschutz und Benutzerfreundlichkeit. Relayers fungieren als vertrauenswürdige Vermittler, ohne explizites Vertrauen zu erfordern, dank der kryptografischen Schutzmaßnahmen, die von der Schlüsselhierarchie durchgesetzt werden. Dies ermöglicht es Renegade, seine Aktivitäten zu skalieren, während die höchsten Sicherheitsstandards und die Benutzerautonomie aufrechterhalten werden.

Kurz gesagt, die Commitment-Baumarchitektur und Schlüsselhierarchie von Renegade bieten einen grundlegenden Rahmen für das Ausbalancieren von Datenschutz und Verifizierbarkeit beim dezentralen Handel. Indem sichergestellt wird, dass Benutzerwallets vollständig off-chain bleiben und on-chain nur als kryptografische Commitments dargestellt werden, beseitigt Renegade die Sichtbarkeit sensibler Handelsdaten.

Dieses Design verhindert nicht nur Front-Running, Quote-Fading und andere ausbeuterische Verhaltensweisen, sondern ermöglicht es den Benutzern auch, die volle Kontrolle über ihre Gelder durch das Wurzelschlüsselpaar zu behalten. Das Commit-Reveal-Schema in Verbindung mit der Verwendung von ZKPs garantiert, dass Wallet-Updates und Statusübergänge sicher, manipulationssicher und für externe Beobachter vollständig undurchsichtig sind. Dies gewährleistet eine Handelsumgebung, in der vertrauenswürdige Überprüfung und hohe Privatsphäre nahtlos nebeneinander existieren.

Das Relayer-System, das mit der Schlüsselhierarchie integriert ist, verbessert die Benutzererfahrung und die betriebliche Effizienz von Renegade weiter. Relayers vereinfachen den Handelsprozess, indem sie sich um die rechenintensive Aufgabe der Auftragsabstimmung und Abwicklung kümmern und dabei die MPC-Matching-Engine und SNARK-Proofs nutzen, um die Privatsphäre zu wahren und die Korrektheit sicherzustellen. Gleichzeitig überbrücken sie die Kluft zwischen robusten Datenschutzgarantien und einer reibungslosen Benutzererfahrung, indem sie Echtzeit-Updates über den symmetrischen API-Schlüssel bereitstellen.

Durch die Trennung von Ansichts- und Übereinstimmungsberechtigungen gewährleistet die Schlüsselhierarchie, dass Benutzer die ultimative Kontrolle über ihre Geldbörsen behalten, während Relayer in streng definierten Rollen agieren. Dieses System schafft ein einzigartiges Gleichgewicht, bei dem Benutzer von den datenschutzerhaltenden Eigenschaften fortschrittlicher kryptografischer Techniken profitieren, ohne auf die mit solchen Systemen in der Regel verbundenen Benutzerfreundlichkeitsbarrieren zu stoßen.

Wie Bestellungen bei Renegade abgeglichen werden

Bei Renegade kombiniert der Prozess der Auftragsabstimmung Benutzeraktionen, Relayer-Fazilitation und modernste kryptografische Protokolle, um ein nahtloses und privates Handelserlebnis zu schaffen. Dieser Abschnitt verfolgt die Reise eines einzigen Auftrags - von seiner Erstellung durch den Benutzer bis zur endgültigen Abwicklung - und erklärt die Rolle von Relays, die Mechanik des MPC-Matching-Motors und die Sicherheitsgarantien, die durch kollaborative SNARKs bereitgestellt werden. Indem wir diese Phasen untersuchen, werden wir herausfinden, wie Renegade sicherstellt, dass Trades privat, atomar und vollständig überprüfbar bleiben, ohne Benutzerfreundlichkeit oder Vertrauenslosigkeit zu opfern.

Damit wollen wir beginnen, den ersten Schritt zu untersuchen: wie ein Benutzer eine Bestellung erstellt und wie diese Aktion die Bühne für den restlichen Abgleichungsprozess setzt.

Benutzer erstellt eine Bestellung

Die Order-Matching-Reise in Renegade beginnt damit, dass der Benutzer mit der Benutzeroberfläche interagiert, um eine Bestellung zu erstellen. Dabei werden wichtige Parameter wie das Handelspaar (z.B. WETH/USDC) und die gewünschte Handelsmenge angegeben. Im Gegensatz zu traditionellen Systemen unterstützt Renegade keine Limit-Orders - da Renegade kein zentrales Limit-Orderbuch (CLOB) ist und unnötige Komplexität vermeiden möchte - sondern jede Bestellung wird auf den Mittelpunkt festgelegt, d.h. der Handel erfolgt zum Mittelpunkt des aktuellen Spreads auf großen Börsen wie Binance, Coinbase, OKX und Kraken. Sobald der Preis unter Verwendung von Daten aus mehreren Quellen bestimmt wurde, bestätigen die Benutzer ihre Bestelldetails, und die Wallet-Software aktualisiert den Zustand nahtlos, um die neue Bestellung widerzuspiegeln, während sie die Datenschutz-architektur von Renegade einhält.

Der aktualisierte Wallet-Zustand berücksichtigt alle reservierten Bilanzen, die zur Erfüllung des Handels sowie der Relayer-Gebühren erforderlich sind. Dieser neue Zustand wird kryptografisch mithilfe eines Verbergungs- und Bindungsverpflichtungsschemas verpflichtet, um sicherzustellen, dass der Inhalt des Wallets für externe Beobachter privat und unverständlich bleibt. Um die Integrität des Systems zu gewährleisten, wird der vorherige Wallet-Zustand sicher neutralisiert, um jegliche Möglichkeit einer Wiederverwendung oder doppelten Ausgabe zu verhindern.

Die Wallet-Software übermittelt dann das aktualisierte Engagement als Teil des Commit-Reveal-Schemas von Renegade an den Commitment-Baum, zusammen mit einem Zero-Knowledge-Beweis (ZKP), der den gesamten Übergang validiert. Dieser Beweis stellt sicher, dass das Wallet-Update die Protokollregeln einhält, einschließlich ausreichender Kontostände und korrekter Statusübergänge, ohne dabei sensible Details über die Bestellung oder Wallet-Inhalte preiszugeben. Sobald der Übergang verifiziert ist, wird das alte Wallet als ausgegeben markiert und das neue Engagement wird sicher zum Commitment-Baum hinzugefügt.

Aus Sicht des Benutzers ist dieser gesamte Prozess nahtlos. Sobald die Bestellung erfolgreich abgeschlossen ist, wird der aktualisierte Wallet-Zustand, einschließlich der verbleibenden Guthaben und aktiven Bestellungen, in Echtzeit angezeigt. Wichtig ist, dass die Handelsabsicht des Benutzers und die Details des Wallets vollständig privat bleiben und somit die vor dem Handel gewährleistete Privatsphäre von Renegade erhalten bleibt.

Mit der nun im System festgelegten Bestellung kann der Relayer mit der Verarbeitung beginnen, um potenzielle Übereinstimmungen zu erzielen und den nächsten Schritt im sicheren und privaten Handelsprozess einzuleiten.

Relayer verarbeitet die Bestellung

Sobald der Benutzer eine Bestellung aufgibt, wird der Relayer zu einem wesentlichen Bestandteil des Prozesses und erleichtert sichere und private Interaktionen zwischen der Brieftasche des Benutzers und dem breiteren Renegade-System. Ausgestattet mit den delegierten Geheimnissen - dem Match-Skalar, dem Blinder-Samen und dem Share-Samen - entschlüsselt der Relayer die Brieftasche des Benutzers, um auf die Details der neu erstellten Bestellung zuzugreifen. Diese Delegation macht den Relayer zum entscheidenden Vermittler und überbrückt nahtlos die private Brieftasche des Benutzers und das breitere Handelsökosystem, um sicherzustellen, dass die Bestellung effizient und in voller Übereinstimmung mit den Datenschutz- und Sicherheitsgarantien des Protokolls abgestimmt wird.

Die erste Aufgabe des Relayers besteht darin, die Brieftasche mithilfe des Blinder-Samen und des Shared-Samen zu entschlüsseln, die dynamisch für jede Transaktion gehasht sind. Dies stellt sicher, dass diese Werte eindeutig für die spezifische Operation sind, was die Privatsphäre und Sicherheit weiter stärkt. Sobald der Relayer entschlüsselt ist, erhält er Zugriff auf den privaten Zustand der Brieftasche, einschließlich des neu erstellten Auftrags, der Bilanzen und aller anderen ausstehenden Aufträge. Der Relayer kann jedoch den Inhalt der Brieftasche nicht ändern oder eingreifen, da das Root-Schlüsselpaar ausschließlich unter der Kontrolle des Benutzers bleibt.

Nach dem Zugriff auf den Wallet-Zustand konstruiert der Relayer ein Handshake-Tupel, um die Bestellung sicher an das Renegade-Netzwerk zu kommunizieren. Dieses Tupel enthält:

• Kryptografische Verpflichtungen für die Bestelldetails (z. B. Token-Paar, Menge, Preis).
• Ein Zero-Knowledge-Prädikat, das kryptografisch beweist, dass die Reihenfolge gemäß den Protokollregeln gültig ist, ohne sensible Details wie die Kontostände der Brieftasche oder Bestelldetails preiszugeben.
• Zusätzliche Metadaten erforderlich für Kompatibilitätsprüfungen, wie Gebühren und Abwicklungsvorlieben.

Das Handshake-Tupel wird dann an andere Relayer im Peer-to-Peer-Netzwerk übertragen, um die Verfügbarkeit des Auftrags anzuzeigen und gleichzeitig die Privatsphäre des Auftrags zu gewährleisten. Während sich das Handshake verbreitet, überwachen andere Relayer eingehende Tupel, um Aufträge zu identifizieren, die potenziell mit denen in ihren Wallets verwalteten Aufträgen übereinstimmen könnten. Der für den Auftrag des Benutzers verantwortliche Relayer tut dasselbe und sucht kontinuierlich nach Gegenparteien, die die vom Benutzer angegebenen Kriterien mithilfe kryptografischer Commitments und Kompatibilitätsmetadaten erfüllen.

(Quelle: Renegade-Dokumentation)

Wenn eine potenzielle Übereinstimmung identifiziert wird, beginnen die Relayer, die für die beiden Aufträge verantwortlich sind, eine direkte Kommunikation, um die nächste Phase einzuleiten: die sichere Auftragsabstimmung mit der MPC Matching Engine. Dies gewährleistet einen nahtlosen Übergang von der Auftragserteilung zur sicheren Abstimmung und gewährleistet gleichzeitig die Kern-Datenschutzgarantien von Renegade.

Das Abgleichen der Aufträge

Der Prozess des Abgleichs von Aufträgen in Renegade zeigt eine innovative Anwendung vonMulti-Party Computation (MPC), speziell entwickelt, um sicheres, privates und dezentrales Trading zu ermöglichen. Im Gegensatz zu traditionellen Implementierungen von MPC, bei denen oft mehrere Teilnehmer Inputs für eine kollektive Berechnung bereitstellen, ist das MPC von Renegade für ein Zwei-Parteien-Setup konzipiert. In diesem Fall arbeiten zwei Vermittler, die jeweils im Namen ihrer jeweiligen Benutzer handeln, zusammen, um zu bewerten, ob ihre Aufträge abgeglichen werden können. Diese einzigartige Anpassung von MPC stellt sicher, dass kein Vermittler sensible Details über den Auftrag des anderen erfährt, wie z.B. Token-Typen, Kontostände oder Preise, und ermöglicht dennoch eine genaue und vertrauenswürdige Auftragsabwicklung.

(Quelle: Renegade-Dokumentation)

Der MPC-Matching-Engine beginnt mit der Verarbeitung der verschlüsselten Eingaben von beiden Relays. Diese Eingaben enthalten wichtige Details wie die Token-Paare, Beträge, Preise und zugehörigen Wallet-Zustände der Aufträge. Während dieses Prozesses bleibt alle Informationen verschlüsselt und wird als geheime Anteile im MPC-Protokoll dargestellt. Die Berechnung überprüft, ob die Aufträge in Schlüsselparametern übereinstimmen, wie z.B. die Kompatibilität der Token-Paare, die ausreichende Balance und die Preisbedingungen. Wenn festgestellt wird, dass die Aufträge nicht kompatibel sind, wird der Prozess ohne Offenlegung von Informationen über den Versuch der Übereinstimmung beendet und gewährleistet so die Handelsprivatsphäre beider Parteien.

Wenn der MPC-Motor feststellt, dass die Aufträge kompatibel sind, generiert er ein Übereinstimmungstupel, eine kryptografische Darstellung der Übereinstimmung. Dieses Tupel enthält wesentliche Details wie die zu tauschenden Tokens, die beteiligten Beträge und die Handelsrichtung für jeden Teilnehmer.

Entsprechend Renegades privatsphärefokussiertem Ansatz wird dieses Tupel jedoch nicht sofort geöffnet. Stattdessen bleibt es verschlüsselt, sodass kein Vermittler vorzeitig auf den Inhalt zugreifen oder Details zur Bestellung der Gegenpartei ableiten kann. Durch die Verzögerung der Offenlegung dieser Informationen und aufgrund der robusten kryptografischen Annahmen des MPC Matching Engine eliminiert Renegade das Risiko, dass sensitive Daten während des Matching-Prozesses enthüllt werden, selbst im Fall eines bösartigen Vermittlers.

(Quelle: Renegade-Dokumentation)

Die Hauptausnahme ist der Relayer, den Sie vor der Übermittlung Ihrer Bestellung auswählen; da sie Ihren Ansichtsschlüssel übertragen bekommen, könnte ein unehrlicher Relayer auf alle Ihre vergangenen und zukünftigen Bestellungen zugreifen. Nichtsdestotrotz ist die Tatsache, dass dies die einzige Vertrauensannahme innerhalb von Renegade ist und dass Sie Ihren eigenen Relayer frei betreiben können, macht diese Bedenken weitgehend vernachlässigbar.

Um das Match-Tupel zu validieren, erstellen die Relayer gemeinsam einen kollaborativen SNARK-Beweis, der kryptografisch bestätigt, dass das Match gemäß den Regeln des Protokolls gültig ist. Dieser Beweis stellt sicher, dass:

• Die Aufträge wurden korrekt basierend auf ihren verschlüsselten Eingaben abgeglichen.
• Das Match-Tupel spiegelt genau die Wallet-Status und Aufträge wider, die während des MPC-Prozesses bereitgestellt wurden.
• Kein Relayer hat das Match-Tupel manipuliert oder ungültige Daten an den MPC-Motor übermittelt.

Kollaborative SNARK-Proofs spielen eine entscheidende Rolle bei der Gewährleistung der Integrität des Matching-Prozesses. Indem sie die verschlüsselten Ausgaben des MPC-Motors mit den in dem Commitment-Tree gespeicherten Verpflichtungen verknüpfen, stellen sie einen vertrauenswürdigen Validierungsmechanismus bereit, der gewährleistet, dass das Match den Protokollregeln von Renegade entspricht. Erst nachdem der Nachweis an die verschlüsselten Werte im Match-Tupel überprüft wurde - wie zum Beispiel die zu tauschenden Beträge - werden sie zugänglich. Dieser gestaffelte Ansatz schützt die Handelsprivatsphäre beider Parteien während des Matching- und Validierungsprozesses.

Sobald der Collaborative SNARK-Proof verifiziert ist und das verschlüsselte Match-Tupel geöffnet ist, wechselt das System in die Abwicklungsphase. Zu diesem Zeitpunkt sind die abgeglichenen Aufträge vollständig validiert und bereit für die Abwicklung, wobei alle Handelsdetails sicher verpackt und überprüft sind. Diese nahtlose Integration von MPC und Collaborative SNARKs gewährleistet, dass der Matching-Prozess von Renegade nicht nur privat und sicher, sondern auch vertrauenswürdig und manipulationssicher ist und damit einen neuen Standard für dezentrales Trading setzt.

Handelsabschluss

Nachdem das Match-Tupel und der kollaborative SNARK-Proof validiert wurden, geht der Prozess in die Finalisierungsphase über, in der die Ergebnisse des übereinstimmenden Handels sicher aufgezeichnet und für die Abwicklung vorbereitet werden. Zu diesem Zeitpunkt sind alle erforderlichen kryptografischen Validierungen abgeschlossen, um die Integrität des Handels zu gewährleisten und gleichzeitig die Privatsphäre beider beteiligten Parteien zu wahren.

Um den Handel abzuschließen, generiert die Wallet jedes Traders einen Datensatz des Handels, der zusammenfasst, welche Tokens in welchen Mengen und in welche Richtung ausgetauscht wurden. Diese Datensätze dienen als sichere Platzhalter für die Ergebnisse des Handels und sind direkt mit den kryptografischen Verpflichtungen verbunden, die die aktualisierten Wallet-States darstellen. Diese Datensätze werden für jeden Trader privat generiert und enthalten wichtige kryptografische Schutzmechanismen, um unbefugten Zugriff oder Manipulation zu verhindern.

Nach Überprüfung der verschlüsselten Handelsaufzeichnungen und Beweise aktualisiert der intelligente Vertrag von Renegade den Verpflichtungsbaum und markiert die Aufträge als "belastet" - um weiteres Handeln bis zur Abwicklung zu verhindern. Diese verschlüsselten Aufzeichnungen bleiben im Verpflichtungsbaum als Referenz für die Abwicklung bestehen. Diese Phase zeigt die Datenschutz-Sicherheitsarchitektur von Renegade: Verschlüsselte Handelsdetails in Kombination mit kryptografischen Beweisen ermöglichen einen vertrauenslosen, privaten Handel und gewährleisten gleichzeitig die Überprüfbarkeit während des Abwicklungsprozesses.

Leistung und Skalierbarkeit

Dieser Abschnitt behandelt zwei grundlegende Herausforderungen, die sich aus den innovativen Designentscheidungen von Renegade ergeben:

• Rechenkosten von MPC und SNARKs: Die Kompromisse in Bezug auf Latenz und Ressourcenanforderungen, die durch diese fortgeschrittenen kryptografischen Techniken eingeführt werden.
• Skalierbarkeit des Relayer-Netzwerks: Wie die Peer-to-Peer-Infrastruktur von Renegade hohe Handelsvolumen verwaltet und sich an unterschiedliche Benutzeranforderungen anpasst.

Lassen Sie uns jeden einzelnen im Detail erkunden.

Berechnungskosten für MPC und SNARKs

Die Architektur von Renegade basiert stark auf dem MPC-Matching-Engine und kollaborativen SNARK-Beweisen, um beispiellose Privatsphäre und Sicherheit zu gewährleisten. Diese fortgeschrittenen kryptografischen Techniken erfordern jedoch erhebliche Rechenleistung. Der MPC-Prozess erfordert, dass Relayer verschlüsselte Berechnungen über geheim geteilte Eingaben durchführen, was mehrere Runden sichere Kommunikation und Berechnung zur Auswertung der Kompatibilität von Aufträgen beinhaltet. Dies führt im Vergleich zu traditionellen Matching-Systemen, insbesondere bei der Verarbeitung komplexer oder umfangreicher Trades, zu erheblichem Overhead.

Ebenso ist die Erzeugung von gemeinschaftlichen SNARK-Beweisen eine ressourcenintensive Aufgabe. Obwohl SNARKs für die effiziente Verifikation in der Blockchain ausgelegt sind, erfordert ihre Erstellung umfangreiche kryptografische Operationen, insbesondere bei komplexen Aussagen wie der Gültigkeit von Aufträgen und dem Übergang des Wallet-Zustands. Diese Rechenkosten erhöhen die Zeit und die Ressourcen, die für den Abschluss eines Handels erforderlich sind, was es weniger geeignet für Szenarien macht, die einen hohen Handelsfrequenz oder eine sofortige Ausführung erfordern.

Zusammenfassend stellen diese beiden Operationen eine der größten Rechenlasten für Relayer dar, die mit der Zuordnung von Benutzerbestellungen betraut sind. Obwohl diese Kosten ein notwendiger Kompromiss sind, um die starken Datenschutz- und Sicherheitsgarantien zu erreichen, die Renegade definieren, bleiben sie ein wichtiger Aspekt für Skalierbarkeit und Benutzererfahrung.

Skalierbarkeit des Relayer-Netzwerks

Das Design von Renegade minimiert das Vertrauen in Relayer, verlässt sich nur auf sie für die erforderliche Lebendigkeit, um Trades abzugleichen. Darüber hinaus haben Relayer keine verwahrende Autorität oder Entscheidungsbefugnis, da alle Aktionen kryptographisch durch Zero-Knowledge-Proofs (ZKPs) validiert werden. Dieses vertrauenslose Design bedeutet, dass die Stärkung der Relayer rechnerisch - zum Beispiel durch Erhöhung ihrer Rechenleistung, um mehr Trades zu bewältigen - keine signifikanten Risiken mit sich bringt. Gleichzeitig ist die Netzwerkarchitektur von Renegade vollständig permissionless, was eine vielfältige Palette von Relays ermöglicht, die sich in Größe und Rechenfähigkeit unterscheiden, um im selben Ökosystem zu existieren, ohne dabei systemische Probleme zu verursachen.

Diese Flexibilität ist eine der Stärken von Renegade. Kleinere Relayer können effektiv neben größeren und leistungsstärkeren agieren und so ein robustes und dezentrales Netzwerk gewährleisten. Die Abhängigkeit des Protokolls von kryptografischen Garantien gewährleistet, dass alle Relayer, unabhängig von ihrer Größe oder ihrem Umfang, den gleichen strengen Validierungsregeln folgen müssen, um die Fairness und Integrität des Systems zu bewahren.

Super-Relayers hingegen bieten eine spezialisierte Rolle im Netzwerk, die darauf abzielt, fortgeschrittene Benutzer und institutionelle Teilnehmer anzusprechen. Im Gegensatz zu Standard-Relayers arbeiten Super-Relayers mit delegiertem Root-Key-Zugriff, der ihnen die volle Kontrolle über die Brieftasche eines Benutzers ermöglicht. Das bedeutet, dass ihnen nicht nur vertraut wird, Handelsgeschäfte abzugleichen, sondern auch den gesamten Lebenszyklus der Brieftasche zu verwalten, einschließlich Auftragserteilungen, Stornierungen und Saldoanpassungen. Durch die Delegierung des Root-Keys erzielen Benutzer erhebliche Verbesserungen bei Geschwindigkeit und Leistung, da der Super-Relayer bestimmte Operationen umgehen kann, die eine On-Chain-Verifizierung erfordern.

Die Delegation des Root-Schlüssels führt jedoch zu einem hohen Maß an Vertrauen, wodurch Super-Relays hauptsächlich für Einheiten geeignet sind, die ihre eigene Relayer-Infrastruktur für den persönlichen Gebrauch betreiben, wie Institutionen oder anspruchsvolle individuelle Händler. Diese Benutzer können Super-Relays nutzen, um ihre Handelssysteme zu optimieren, von nahezu sofortiger Auftragsausführung und reduzierten Kosten zu profitieren und gleichzeitig die direkte Aufsicht über die Infrastruktur zu behalten.

(Quelle: Dokumentation für Außenseiter)

Renegades Relayer-Netzwerk mit seiner Mischung aus Standard- und Super-Relayern veranschaulicht ein skalierbares und anpassungsfähiges System. Es erreicht diese Skalierbarkeit, ohne Dezentralisierung oder Sicherheit zu opfern, und stellt sicher, dass das Netzwerk diverse Benutzeranforderungen und Handelsvolumina bewältigen kann, während es seine Kernprinzipien von Vertrauenslosigkeit und Erlaubnislosigkeit beibehält.

Fazit

In diesem Artikel haben wir das Konzept der Dark Pools vorgestellt und ihre Rolle im traditionellen Finanzwesen sowie ihre wachsende Bedeutung im dezentralen Finanzwesen hervorgehoben. Durch die Untersuchung von Renegade haben wir gezeigt, wie kryptografische Innovationen wie Zero-Knowledge-Beweise und Mehrparteienberechnungen wichtige Probleme wie Front-Running, Angebotsverdünnung und MEV-Extraktion angehen können, um den Weg für sicheren und privaten dezentralen Handel zu ebnen.

In Zukunft wird die Diskussion über Dark Pools auf andere bemerkenswerte Protokolle wie Tristero und Railgun ausgeweitet werden. Beide Projekte bieten einzigartige Ansätze zur Verbesserung der Handelsprivatsphäre und der Ausführungsqualität und setzen dabei unterschiedliche Methoden ein, um ihre Ziele zu erreichen.

In kommenden Artikeln werden wir tiefer in die Designs dieser Protokolle eintauchen und ihre Vorteile, besonderen Merkmale sowie den Vergleich untereinander und mit Renegade untersuchen. Diese umfassende Erkundung wird Einblick in die vielfältigen Lösungen bieten, die die Zukunft der datenschutzerhaltenden dezentralen Finanzen prägen.

Haftungsausschluss:

1. Dieser Artikel wurde aus [ wiederveröffentlicht.2077forschung]. Alle Urheberrechte gehören dem Originalautor [Emmanuel AwosikaUndKoray Akpinar]. Falls es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an den Tor lernenTeam, 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. Das Gate Learn-Team übersetzt den Artikel in andere Sprachen. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.