Eine der Geschichten, die mich an Newton am meisten fesseln, ist: „Mit Zero-Knowledge-Beweisen Compliance-konformes Datenschutz- ermöglichen“. Compliance und Datenschutz galten in den vergangenen zwei Jahren zeitweise als Gegensätze – und Newton versucht, sie wieder miteinander zu verbinden: Nutzer sollen beweisen können, dass sie bestimmte Bedingungen erfüllen, etwa nicht auf einer Sanktionsliste zu stehen oder kein US-Bürger zu sein, ohne dabei konkrete Identitätsinformationen offenlegen zu müssen. Wenn dieser Ansatz funktioniert, könnte er für das gesamte DeFi unter dem Druck regulatorischer Härte ein Ausweg sein.
Aber ich muss es ganz klar fragen: Ist dieser Weg rechtlich überhaupt gangbar?
Vor der Sanktionierung von Tornado Cash glaubten viele ebenfalls, „Datenschutz-Tools an sich seien neutral“, bis das OFAC schließlich die Vertragsadresse direkt in die SDN-Liste aufnahm und damit jede Adresse, die mit dem Vertrag interagiert, einem Compliance-Risiko ausgesetzt ist. Wird die ZK-Beweisschicht von Newton dasselbe Schicksal teilen? Der Unterschied besteht darin, dass Newton im Intent-Layer die „Möglichkeit“ für KYC/AML-Nachweise einbaut, aber keine zwingenden Anforderungen stellt. Das Problem liegt genau in diesen drei Worten: „Möglichkeit“.
Wenn Newton es Nutzern erlaubt, beim Einreichen ihrer Absicht selbst zu wählen, ob sie eine Konformitätsnachweis beilegen oder nicht, dann könnten echte Datenschutzbedürfnisse und Nutzer, die Sanktionen umgehen wollen, auf der Blockchain möglicherweise demselben Verhaltensmuster entsprechen. Sobald die Aufsichtsbehörden nicht mehr unterscheiden können, ist es sehr wahrscheinlich, dass sie mit einer „Pauschallösung“ vorgehen und die gesamten Smart-Contract-Adressen von Newton als potenzielle Risikopunkte einstufen. Im Gegensatz zu zentralisierten Börsen gibt es bei dezentralen Protokollen keinen Kundendienst, der eine E-Mail schicken und erklären kann: „Wir haben es nicht absichtlich so hineingetan.“ Sobald es auf eine Entity-Liste gesetzt wird, könnte das gesamte Frontend mit dem Risiko einer Abschaltung konfrontiert sein.
Es gibt auch einige subtilere Lücken. Angenommen, ein Nutzer besteht die Validierung durch einen bestimmten Compliance-Nachweis-Anbieter, doch dieser Anbieter wird später dabei entdeckt, Beweise gefälscht zu haben oder die Prüfung zu nachlässig durchgeführt zu haben: Kann ein Newton-Knoten erkennen, dass diese bereits „kontaminierten“ Nachweise vorliegen? Wenn nicht, wird der gesamte Datenschutzpool aufgrund weniger „schwarzer Adressen“ als Ganzes markiert. Das ist das sogenannte „Jamming/Bomben- (Torpedo-)Attacke“-Prinzip: Je größer der Datenschutzpool, desto höher sind die Kosten, ihn nach einer Kontamination wieder zu bereinigen.
Noch schlimmer ist, dass die Cross-Chain-Funktionalität von Newton dieses Risiko auf mehrere Ketten verteilt. Wenn ein Operator auf Arbitrum eine Datenschutz-Absicht verarbeitet, die einen „kontaminierten Nachweis“ enthält, und es anschließend auf einen Pool auf Optimism bezieht, kann sich das Compliance-Risiko über Chains hinweg ausbreiten. Das zwingt dann andere Partner oder Infrastruktur-Anbieter auf anderen Ketten, die Beziehung zu Newton zu kappen. Das ist kein technisches Problem, sondern eine Frage der juristischen „Radius“-Auswirkung.$BTC
Ich habe gesehen, dass Newton in seinem Whitepaper „optionale Compliance-Blöcke“ erwähnt, aber genau diese sechs Wörter sind das entscheidende Entscheidungsfeld. Denn „optional“ bedeutet, dass die Verantwortung teilweise auf die Nutzer verlagert wird, während die Folgen am Ende das ganze Protokoll treffen könnten. Wenn das Team vor dem Mainnet-Launch kein klares Compliance-Raster vorlegen kann – also eindeutig, welche Arten von Absichten standardmäßig einen Konformitätsnachweis erfordern und welche nur anhand von On-Chain-Verhaltensbewertungen freigelassen werden können – dann läuft die gesamte Datenschutz-Erzählung wie auf einem Drahtseil, und zwar über einem Abgrund ohne Sicherheitsnetz.
Ich gebe die Datenschutz-Roadmap nicht auf, nur weil ich Angst vor Aufsichtsbehörden habe, aber ich muss sehen, dass Newton auf Protokollebene einen harten Schutz gegen regulatorische Risiken hat – nicht nur, dass in Dokumenten irgendwo das Wort „Compliance“ steht. Bei diesem Thema ist eine klare Begrenzung wertvoller als tausend wohlklingende Möglichkeiten.