Die Uniswap-Governance prüft eine Request for Comments, kurz RFC, die einen optionalen privaten Ausführungspfad innerhalb der Uniswap-Oberfläche einführen würde. Der Vorschlag würde Uniswap v4 Hooks und UniswapX nutzen, um die Menge an Transaktionsinformationen zu reduzieren, die vor der Ausführung eines Swaps offengelegt wird.

Die von SilentSwap eingereichte RFC beschreibt die vorgeschlagene Funktion als Option „Swap Privately“. Dem Vorschlag zufolge würden Standardswaps unverändert bleiben, und Pool-Gebühren wären nicht betroffen. Das vorgeschlagene Design stützt sich auf zk-SNARKs und ein Compliance-Screening vor der Ausführung, um eine privatere Handelsverarbeitung zu unterstützen.

Das Nutzerproblem hinter dem technischen Design ist klar: On-Chain-Swaps sind transparent. Diese Transparenz ist ein Kernmerkmal der dezentralen Finanzwelt, kann aber auch die Transaktionsabsicht vor der Ausführung offenlegen. Wenn diese Informationen sichtbar werden, können Bots und professionelle Trader Nutzer möglicherweise durch Front-Running, Sandwich-Angriffe oder andere Methoden ausnutzen.

Da Uniswap eine der meistgenutzten Handelsoberflächen in DeFi ist, könnte eine Governance-Diskussion über Ausführungsprivatsphäre über eine einzelne Oberflächenfunktion hinaus Bedeutung haben. Der Vorschlag bleibt ein Diskussionspunkt und wurde weder genehmigt noch eingeführt.

Warum Swap-Privatsphäre wichtig ist

Der DeFi-Handel hat seit Langem ein Sichtbarkeitsproblem. Wenn Nutzer Transaktionen einreichen, können ihre Absichten vor der endgültigen Abwicklung sichtbar werden. Bots können ausstehende Transaktionen überwachen, die wahrscheinlichen Preiseffekte einschätzen und eigene Trades um die Transaktion eines Nutzers herum platzieren. Dies kann für gewöhnliche Trader zu schlechterer Ausführung führen.

MEV, Sandwich-Angriffe und Execution Leakage sind seit Jahren wiederkehrende Probleme in DeFi. Der Begriff MEV, kurz für maximal extractable value, wurde um 2019 formalisiert und ist seitdem zu einer anerkannten strukturellen Herausforderung im Ethereum-basierten Handel geworden. Infrastruktur wie Flashbots’ MEV-Boost, die nach Ethereums Übergang zu Proof-of-Stake breit übernommen wurde, wurde entwickelt, um Aspekte dieses Problems auf Ebene der Blockerstellung zu adressieren. Einige Nutzer setzen außerdem auf private RPCs, Aggregatoren, Slippage-Kontrollen oder fortgeschrittenere Routing-Tools, um ihre Exponierung zu verringern. Andere nutzen diese Schutzmechanismen nicht, entweder weil sie sie nicht kennen oder weil die Tools nicht Teil ihres normalen Handelsablaufs sind.

Ein privater Ausführungspfad würde darauf abzielen, diese Art von Schutz auf Ebene der Oberfläche leichter zugänglich zu machen. Diese Unterscheidung ist wichtig, weil die meisten Nutzer mit DeFi über Frontends interagieren und nicht direkt über Smart Contracts. Wenn Datenschutz oder MEV-Schutz auf Spezialwerkzeuge beschränkt bleibt, werden viele Nutzer ihn möglicherweise nie übernehmen.

Das Hinzufügen einer Option „Swap Privately“ zu einer Mainstream-Oberfläche würde den Schutz näher an den Punkt bringen, an dem Nutzer Trades initiieren. Die RFC stellt die Funktion als optional dar, nicht als Ersatz für die standardmäßige Swap-Ausführung.

v4 Hooks würden ein flexibleres Design unterstützen

Uniswap v4 Hooks sind ein zentraler Bestandteil der vorgeschlagenen Architektur. Hooks ermöglichen es Entwicklern, das Verhalten von Pools und die Ausführungslogik rund um Swaps anzupassen. Diese Flexibilität kann unterschiedliche Routing-Designs, Gebührenstrukturen, Mechanismen zur Auftragsabwicklung und datenschutzbezogene Funktionen unterstützen. Uniswap v4 selbst befindet sich weiterhin in Entwicklung und wurde noch nicht im Mainnet bereitgestellt, was bedeutet, dass die technische Grundlage für die vorgeschlagene Funktion noch geprüft und getestet wird.

Im Rahmen der RFC würden v4 Hooks als Teil der privaten Ausführungsarchitektur verwendet. UniswapX ist ebenfalls in das Design einbezogen, weil es bereits eine flexiblere Swap-Ausführung über ein auktionsbasiertes Routing-System mit externen Fillern unterstützt. UniswapX wurde 2023 eingeführt und enthält selbst bestimmte MEV-Schutz-Eigenschaften im Design, da Orders über wettbewerbliche Auktionen off-chain ausgeführt werden, statt direkt an den öffentlichen Mempool gesendet zu werden. Zusammen könnten die beiden Komponenten eine Route bereitstellen, bei der Transaktionsdetails vor der Ausführung weniger offengelegt werden, während weiterhin die Liquidität und Oberfläche von Uniswap genutzt werden.

Das Design bleibt jedoch Gegenstand der Governance-Diskussion. Eine RFC ist keine genehmigte Governance-Änderung und bedeutet nicht, dass die Funktion live ist. Es handelt sich um einen Vorschlag, den die Community prüfen, kritisieren, verfeinern oder ablehnen kann.

Datenschutz und Compliance werden gemeinsam behandelt

Eines der bemerkenswerten Elemente der RFC ist die Kombination von Datenschutzfunktionen mit einem Compliance-Screening vor der Ausführung. Der Vorschlag spiegelt eine breitere Verschiebung in DeFi-Datenschutzdebatten wider, in denen Datenschutz und Compliance zunehmend als Designüberlegungen behandelt werden, die möglicherweise nebeneinander bestehen müssen.

Frühere Debatten im Kryptobereich stellten Datenschutz und Compliance häufig als gegensätzliche Ziele dar: Transaktionen waren entweder sichtbar und compliant oder privat und potenziell verdächtig. Die RFC verfolgt einen differenzierteren Ansatz, indem sie versucht, Nutzer vor Front-Running und Datenlecks zu schützen und zugleich Compliance-Kontrollen einzubeziehen.

Der vorgeschlagene Einsatz von zk-SNARKs baut auf einer Technologie auf, die in Projekten wie Zcash, das 2016 gestartet wurde, sowie in Ethereum-Zero-Knowledge-Rollups, die seit 2023 an Akzeptanz gewonnen haben, bereits erprobt wurde. zk-SNARKs ermöglichen es einer Partei, Wissen über Informationen nachzuweisen, ohne die Informationen selbst offenzulegen, was sie sowohl für Datenschutz als auch für Compliance-Designs mit selektiver Offenlegung relevant macht.

Nutzer wünschen sich möglicherweise Schutz vor dem Durchsickern von Transaktionsabsichten und vor ausbeuterischem Ausführungsverhalten. Gleichzeitig könnten Regulierungsbehörden und Protokolle vermeiden wollen, Tools zu schaffen, die sanktionierte Aktivitäten oder anderen Missbrauch erleichtern. Entwickler untersuchen daher Systeme, die legitime Nutzer schützen und zugleich eine Form von Compliance-Screening erhalten können.

Dieses Gleichgewicht ist schwierig und dürfte umstritten bleiben. Dass die Uniswap-Governance ein Modell mit zk-SNARKs und Compliance-Screening diskutiert, zeigt, wie vielschichtig die Debatte über Datenschutz in DeFi geworden ist.

Eine Genehmigung ist nicht gesichert

Die RFC sollte nicht als fertiges oder genehmigtes Produkt betrachtet werden. Die Uniswap-Governance müsste weiterhin bewerten, ob das Design angemessen ist, ob die technische Implementierung sicher ist, ob die Compliance-Annahmen akzeptabel sind, ob die Nutzererfahrung klar ist und ob die Funktion neue Risiken für das Protokoll oder die Oberfläche einführt.

Mögliche Bedenken umfassen technische Komplexität, Vertrauensannahmen, Screening-Anbieter, rechtliche Risiken, Kosten und die Frage, ob Nutzer verstehen, was „privat“ in diesem Zusammenhang bedeutet. Diese Fragen stehen im Zentrum jedes Versuchs, Ausführungsprivatsphäre zu einer großen DeFi-Oberfläche hinzuzufügen.

Ausführungsprivatsphäre ist sensibel, weil ein schlecht konzipiertes System falsches Vertrauen oder neue Angriffsflächen schaffen könnte. Ein gut konzipiertes System könnte den On-Chain-Handel für gewöhnliche Nutzer sicherer machen, indem es die Exponierung gegenüber bestimmten Formen ausbeuterischer Ausführung reduziert.

Uniswaps Rolle in der DeFi-Marktstruktur

Uniswaps Position im dezentralen Handel verleiht dem Vorschlag eine breitere Relevanz. Wenn Uniswap neue Ausführungsmodelle untersucht, dürften andere DeFi-Protokolle, DEXs und Aggregatoren die Auswirkungen bewerten. Das Protokoll und die Oberfläche sind tief darin eingebettet, wie Nutzer on-chain handeln.

Andere dezentrale Handelsplattformen haben bereits unterschiedliche Ansätze für MEV- und Ausführungsschutz verfolgt. CoW Swap nutzt Batch-Auktionen mit Solver-Wettbewerb, um die Fähigkeit von Bots zu verringern, Trades neu zu ordnen oder einzufügen. 1inch hat Funktionen integriert, die Front-Running mindern sollen. Die Uniswap-RFC fügt dieser laufenden Branchendiskussion einen weiteren Designansatz hinzu.

Eine Datenschutzoption innerhalb dieses Handelsablaufs könnte beeinflussen, was Nutzer von anderen dezentralen Börsen und Aggregatoren erwarten. Sie könnte auch zur breiteren Diskussion über Ausführungsstandards in DeFi beitragen.

Nutzer sollten MEV nicht auf einem tiefen technischen Niveau verstehen müssen, um ihr Risiko einer Ausnutzung zu verringern. Tools auf Oberflächebene können sicherere Voreinstellungen oder klarere Optionen für Nutzer bieten, die sonst auf öffentliche Wege zur Transaktionseinreichung angewiesen sind.

Derzeit bleibt die RFC lediglich ein Vorschlag. Sie weist auf ein mögliches Modell hin, bei dem DeFi-Swaps weiterhin transparent on-chain abgewickelt werden, während in dem Zeitraum, in dem Nutzer am anfälligsten für Execution Leakage sind, weniger Informationen offengelegt werden.

Dieser Artikel basiert auf der Uniswap-Governance-RFC zu nativer Ausführungsprivatsphäre durch v4 Hooks und UniswapX. Der ursprüngliche Bitcoinist-Bericht wurde vom News Desk verfasst und von Samuel Rae redigiert und stützte sich auf Informationen aus Primärquellendokumentation.