Ich habe das Whitepaper von @Dusk gelesen. Ganz ehrlich: Es ist irgendwie „zu gut“, dass es einen fesselt – aber es wirft auch ein paar Fragen auf.
Geht der große Wurf gut? Hat BTC noch eine Zukunft?
Dieser XSC-Standard zielt im Kern auf dieses „sowohl als auch“ ab: Man will sowohl Privatsphäre als auch Compliance. Klingt ziemlich perfekt – aber wenn man genauer darüber nachdenkt, ist das Ganze nicht so einfach. Im Whitepaper werden die technischen Details recht vage beschrieben; ständig heißt es sinngemäß „Details siehe das andere Paper“, und an den entscheidenden Stellen wird es eher übergangen.
Wer sich im Finanzsektor auskennt, weiß: Das Kniffligste ist nie, ob sich eine Technik umsetzen lässt, sondern wem die Berechtigungen am Ende wirklich gehören. Im Whitepaper von Dusk wird die Rolle des Auditors erwähnt: Angeblich werden die Transaktionsdaten so verschlüsselt, dass sie auf den öffentlichen Schlüssel des Auditors gelangen, damit die Aufsicht die Nachverfolgung erleichtern kann. Aber die Frage ist: Wer ist dieser Auditor? Ist es das Projekt selbst? Ein bestimmter Dritter? Oder die Aufsichtsbehörde selbst?
Der dahinterliegende Gedankengang ist fundamental anders. Wenn die Audit-Schlüssel beim Projektbetreiber liegen, was wäre dann der Unterschied zur traditionellen zentralisierten Verwahrung im Finanzwesen? Institutionelle Kunden legen ihre Assets ab, und am Ende sind Gegenpartei, Positionsgröße usw. für den Projektbetreiber jederzeit einsehbar – man nennt das nicht Privatsphäre, sondern einseitige Transparenz.
Im Whitepaper steht außerdem, dass der Auditor ein „m-aus-von-n“-Multi-Signature-Setup sein kann, das über Schwellenkryptografie gesteuert wird. Die Idee ist richtig: Macht verteilen. Aber ganz konkret bei der Umsetzung: Wer besitzt die Schlüsselbruchstücke? Wie stellt man sicher, dass der Audit-Prozess nicht missbraucht wird? Diese praktischen Punkte werden im Whitepaper tatsächlich nicht klar beantwortet.
Ein weiterer interessanter Punkt: Dusk hat später das Moonlight-Transaktionsmodell weiterentwickelt. Es soll in der Lage sein, die Absenderidentität einer Phoenix-Transaktion so zu erkennen, dass sie dem Empfänger angezeigt werden kann. Damit wird reine Anonymität zu „kontrollierter Privatsphäre“ – man weiß, von wem das Geld kommt, aber Passanten wissen es nicht. Das ist eigentlich der Zustand, den Compliance im Finanzmarkt wirklich braucht: Klarheit zwischen den Transaktionsparteien, aber keine Offenlegung von Geschäftsgeheimnissen auf dem öffentlichen Markt.
Kurz gesagt: Ob XSC durchstarten kann, hängt nicht davon ab, wie „hart“ das ZK-Beweisverfahren technisch ist, sondern davon, an welcher Wand diese Schlüssel letztlich hängen. Wenn das Design der Schlüsselverwaltung nicht streng genug ist, werden Privatsphäre und Compliance zu einer tödlichen Endlosschleife, in der sie sich gegenseitig ausbremsen – statt sich zu ergänzen.
Und die Zusammenarbeit von NPEX mit tokenisierten Wertpapieren im Umfang von @Dusk Euro bringt genau dieses Problem an die Oberfläche. $DUSK #dusk
Geht der große Wurf gut? Hat BTC noch eine Zukunft?
Dieser XSC-Standard zielt im Kern auf dieses „sowohl als auch“ ab: Man will sowohl Privatsphäre als auch Compliance. Klingt ziemlich perfekt – aber wenn man genauer darüber nachdenkt, ist das Ganze nicht so einfach. Im Whitepaper werden die technischen Details recht vage beschrieben; ständig heißt es sinngemäß „Details siehe das andere Paper“, und an den entscheidenden Stellen wird es eher übergangen.
Wer sich im Finanzsektor auskennt, weiß: Das Kniffligste ist nie, ob sich eine Technik umsetzen lässt, sondern wem die Berechtigungen am Ende wirklich gehören. Im Whitepaper von Dusk wird die Rolle des Auditors erwähnt: Angeblich werden die Transaktionsdaten so verschlüsselt, dass sie auf den öffentlichen Schlüssel des Auditors gelangen, damit die Aufsicht die Nachverfolgung erleichtern kann. Aber die Frage ist: Wer ist dieser Auditor? Ist es das Projekt selbst? Ein bestimmter Dritter? Oder die Aufsichtsbehörde selbst?
Der dahinterliegende Gedankengang ist fundamental anders. Wenn die Audit-Schlüssel beim Projektbetreiber liegen, was wäre dann der Unterschied zur traditionellen zentralisierten Verwahrung im Finanzwesen? Institutionelle Kunden legen ihre Assets ab, und am Ende sind Gegenpartei, Positionsgröße usw. für den Projektbetreiber jederzeit einsehbar – man nennt das nicht Privatsphäre, sondern einseitige Transparenz.
Im Whitepaper steht außerdem, dass der Auditor ein „m-aus-von-n“-Multi-Signature-Setup sein kann, das über Schwellenkryptografie gesteuert wird. Die Idee ist richtig: Macht verteilen. Aber ganz konkret bei der Umsetzung: Wer besitzt die Schlüsselbruchstücke? Wie stellt man sicher, dass der Audit-Prozess nicht missbraucht wird? Diese praktischen Punkte werden im Whitepaper tatsächlich nicht klar beantwortet.
Ein weiterer interessanter Punkt: Dusk hat später das Moonlight-Transaktionsmodell weiterentwickelt. Es soll in der Lage sein, die Absenderidentität einer Phoenix-Transaktion so zu erkennen, dass sie dem Empfänger angezeigt werden kann. Damit wird reine Anonymität zu „kontrollierter Privatsphäre“ – man weiß, von wem das Geld kommt, aber Passanten wissen es nicht. Das ist eigentlich der Zustand, den Compliance im Finanzmarkt wirklich braucht: Klarheit zwischen den Transaktionsparteien, aber keine Offenlegung von Geschäftsgeheimnissen auf dem öffentlichen Markt.
Kurz gesagt: Ob XSC durchstarten kann, hängt nicht davon ab, wie „hart“ das ZK-Beweisverfahren technisch ist, sondern davon, an welcher Wand diese Schlüssel letztlich hängen. Wenn das Design der Schlüsselverwaltung nicht streng genug ist, werden Privatsphäre und Compliance zu einer tödlichen Endlosschleife, in der sie sich gegenseitig ausbremsen – statt sich zu ergänzen.
Und die Zusammenarbeit von NPEX mit tokenisierten Wertpapieren im Umfang von @Dusk Euro bringt genau dieses Problem an die Oberfläche. $DUSK #dusk
