Beweisen, dass man sauber ist, ohne die Kundenliste herauszugeben – dafür gibt es eine Lösung
Das Peinlichste für eine Institution, wenn sie in den Markt einsteigt: Sie möchte beweisen, dass sie sauber ist, aber ihre Kundenliste nicht herausgeben. Im Grunde gibt es bisher zwei Ansätze. Beim ersten überlässt man einer On-Chain-Analysefirma Adressen und Transaktionsverläufe zur Bewertung – damit legt man einem Dritten praktisch alle Karten auf den Tisch. Beim zweiten erstellt man eine Merkle-Whitelist. Damit lässt sich lediglich beweisen, dass eine bestimmte Adresse zur Menge gehört, nicht aber, dass die Menge selbst sauber ist. Auf dem privaten Datenpfad von SXT habe ich einen dritten Ansatz ausprobiert: Man speist die interne Liste und eine öffentliche Liste eingeschränkter Adressen in dieselbe Tabelle ein und lässt die Abfrage einen booleschen Wert samt Beweis zurückgeben. Nach außen wird nur dieses Ergebnis offengelegt, kein einziger Datensatz. Die Einsatzmöglichkeiten sind größer, als die meisten denken: So lassen sich Reservenachweise und Sanktionsprüfungen umsetzen, oder sogar feststellen, ob das Vermögen eines Kunden einen bestimmten Schwellenwert erreicht – stets mit einer bloßen Ja-oder-Nein-Antwort. Die eigentliche technische Herausforderung ist die Aktualität. Die Listen ändern sich täglich, und die Beweise müssen entsprechend neu erstellt werden. Sonst beweist man nur, dass man letzte Woche sauber war. Dabei bin ich einmal selbst auf die Nase gefallen: Ich habe einen alten Beweis für eine neue Liste verwendet, und der Smart Contract meldete, alles sei in Ordnung. Da wurde mir kurz ganz anders. Seitdem nehme ich den Hash der Datenversion in den Beweis auf; stimmt die Version nicht, wird er direkt abgelehnt. Der Engpass liegt nicht in der Kryptografie, sondern in der Liste selbst. Wer pflegt sie, wie oft wird sie aktualisiert, und lassen sich die Änderungen auditieren? Das sind operative Fragen – und wenn dabei jede Menge Fehler passieren, hilft die beste Kryptografie nichts. Außerdem ist noch völlig offen, ob die Justiz kryptografische Beweise anerkennt. Compliance-Verantwortliche sehen lieber einen abgestempelten Bericht. Im Vergleich zum Reservenachweis von Chainlink ist dieser Ansatz flexibler: Man kann beliebige SQL-Abfragen ausführen, statt nur Guthaben zu addieren. Der Preis dafür ist, dass man den gesamten Aufwand für die Beweiserstellung selbst tragen muss. Ich glaube, dass RWA- und Verwahrstellen diesen Weg zuerst nutzen werden, denn sie brauchen am dringendsten genau diese Möglichkeit, etwas selbst nachzuweisen, ohne es offenzulegen. Wer es richtig ausbauen will, muss außerdem Bereichs- und Aggregationsbeweise kombinieren – zum Beispiel beweisen, dass das Gesamtengagement unter einem Grenzwert liegt und zugleich kein einzelner Kontrahent sein Limit überschreitet. Dafür gibt es derzeit keine fertigen Werkzeuge; man muss es selbst zusammenbauen. Wenn diese Ebene reibungslos funktioniert, wird sich auch die Vertriebssprache der Institutionen ändern: von „Unser Risikomanagement ist sehr streng“ zu „Du kannst es selbst überprüfen“. #sxt $SXT @SpaceandTime
Das Peinlichste für eine Institution, wenn sie in den Markt einsteigt: Sie möchte beweisen, dass sie sauber ist, aber ihre Kundenliste nicht herausgeben. Im Grunde gibt es bisher zwei Ansätze. Beim ersten überlässt man einer On-Chain-Analysefirma Adressen und Transaktionsverläufe zur Bewertung – damit legt man einem Dritten praktisch alle Karten auf den Tisch. Beim zweiten erstellt man eine Merkle-Whitelist. Damit lässt sich lediglich beweisen, dass eine bestimmte Adresse zur Menge gehört, nicht aber, dass die Menge selbst sauber ist. Auf dem privaten Datenpfad von SXT habe ich einen dritten Ansatz ausprobiert: Man speist die interne Liste und eine öffentliche Liste eingeschränkter Adressen in dieselbe Tabelle ein und lässt die Abfrage einen booleschen Wert samt Beweis zurückgeben. Nach außen wird nur dieses Ergebnis offengelegt, kein einziger Datensatz. Die Einsatzmöglichkeiten sind größer, als die meisten denken: So lassen sich Reservenachweise und Sanktionsprüfungen umsetzen, oder sogar feststellen, ob das Vermögen eines Kunden einen bestimmten Schwellenwert erreicht – stets mit einer bloßen Ja-oder-Nein-Antwort. Die eigentliche technische Herausforderung ist die Aktualität. Die Listen ändern sich täglich, und die Beweise müssen entsprechend neu erstellt werden. Sonst beweist man nur, dass man letzte Woche sauber war. Dabei bin ich einmal selbst auf die Nase gefallen: Ich habe einen alten Beweis für eine neue Liste verwendet, und der Smart Contract meldete, alles sei in Ordnung. Da wurde mir kurz ganz anders. Seitdem nehme ich den Hash der Datenversion in den Beweis auf; stimmt die Version nicht, wird er direkt abgelehnt. Der Engpass liegt nicht in der Kryptografie, sondern in der Liste selbst. Wer pflegt sie, wie oft wird sie aktualisiert, und lassen sich die Änderungen auditieren? Das sind operative Fragen – und wenn dabei jede Menge Fehler passieren, hilft die beste Kryptografie nichts. Außerdem ist noch völlig offen, ob die Justiz kryptografische Beweise anerkennt. Compliance-Verantwortliche sehen lieber einen abgestempelten Bericht. Im Vergleich zum Reservenachweis von Chainlink ist dieser Ansatz flexibler: Man kann beliebige SQL-Abfragen ausführen, statt nur Guthaben zu addieren. Der Preis dafür ist, dass man den gesamten Aufwand für die Beweiserstellung selbst tragen muss. Ich glaube, dass RWA- und Verwahrstellen diesen Weg zuerst nutzen werden, denn sie brauchen am dringendsten genau diese Möglichkeit, etwas selbst nachzuweisen, ohne es offenzulegen. Wer es richtig ausbauen will, muss außerdem Bereichs- und Aggregationsbeweise kombinieren – zum Beispiel beweisen, dass das Gesamtengagement unter einem Grenzwert liegt und zugleich kein einzelner Kontrahent sein Limit überschreitet. Dafür gibt es derzeit keine fertigen Werkzeuge; man muss es selbst zusammenbauen. Wenn diese Ebene reibungslos funktioniert, wird sich auch die Vertriebssprache der Institutionen ändern: von „Unser Risikomanagement ist sehr streng“ zu „Du kannst es selbst überprüfen“. #sxt $SXT @SpaceandTime
