#dusk $DUSK @Dusk Ich höre Dusk schon lange den Begriff „programmierbarer Datenschutz“ erwähnen, aber jedes Mal, wenn er ihn anspricht, werden mehrere Eigenschaften durcheinandergeworfen. Diesmal möchte ich mir speziell nur „selektive Offenlegung“ herausgreifen, um klarzustellen, was genau damit gemeint ist – der Rest ist erst mal egal.
So wie ich es verstanden habe, löst „selektive Offenlegung“ folgendes Szenario: Bei einer Transaktion ist für Außenstehende normalerweise weder der Betrag noch die Beteiligten sichtbar – das ist der Teil, der unter Datenschutz fällt. Wenn jedoch Aufsichtsbehörden oder Auditoren die Transaktion prüfen müssen, sollten Nutzer oder Institutionen eine Möglichkeit haben, dass eine bestimmte, autorisierte Partei die relevanten Informationen sieht, ohne sie allen öffentlich zu machen. Das ist nicht dieses alte Denkmuster „entweder alles offenlegen oder alles verbergen“, sondern man hat inmitten dieser beiden Extreme einen kontrollierbaren Kanal geschaffen.
Am Anfang dachte ich, dass dieses „selektiv“ durch manuelle Schritte außerhalb der Kette (off-chain) erreicht wird – also wenn etwas passiert, dann über einen Offline-Prozess die Transaktionsprotokolle exportieren, damit die Aufsicht sie sehen kann. Nachdem ich aber erst recherchiert habe, stellte sich heraus, dass es nicht so ist. Die offizielle Darstellung lautet vielmehr, dass diese Fähigkeit direkt über kryptografische Werkzeuge im Protokoll umgesetzt ist: Nutzer oder Institutionen entscheiden selbst, ob sie ein Zertifikat/Attest erzeugen wollen, das nur bestimmten Objekten zur Einsicht bereitsteht. Man muss sich nicht nachträglich bei irgendjemandem anpingen, damit er „im Backend“ eine Datenbankabfrage durchführt. Diese Fehlannahme habe ich erst nach zweimaligem Lesen der Erklärungen korrigiert – am Anfang war sie tatsächlich zu simpel.
Aber ich muss auch offen sagen: In den offiziellen Unterlagen werden die Ausführungsdetails zu „wer die Anfrage für diese Offenlegung stellen darf“ sowie „wie detailliert diese Bescheinigung/der Nachweis eingesehen werden kann“ recht allgemein gehalten. Es gibt keine konkrete Schritt-für-Schritt-Anleitung, der man einfach folgen könnte. Das bedeutet: „Selektive Offenlegung“ ist aktuell eher eine Fähigkeit auf Protokollebene, die zwar vorhanden ist, aber wie man sie in einem konkreten echten Szenario anwendet, wer den Auslöser setzt und wie lange der Genehmigungsprozess dauert – das hängt vermutlich davon ab, wie das später mit Kooperationspartnern wie NPEX in Produkten tatsächlich umgesetzt wird. In dieser Runde konnte ich kein bereits durchgeführtes konkretes Beispiel finden. Ich kann daher erst mal nur bestätigen, dass die Fähigkeit existiert, und nicht beurteilen, ob sie sich in der Praxis gut oder umständlich bedienen lässt.
So wie ich es verstanden habe, löst „selektive Offenlegung“ folgendes Szenario: Bei einer Transaktion ist für Außenstehende normalerweise weder der Betrag noch die Beteiligten sichtbar – das ist der Teil, der unter Datenschutz fällt. Wenn jedoch Aufsichtsbehörden oder Auditoren die Transaktion prüfen müssen, sollten Nutzer oder Institutionen eine Möglichkeit haben, dass eine bestimmte, autorisierte Partei die relevanten Informationen sieht, ohne sie allen öffentlich zu machen. Das ist nicht dieses alte Denkmuster „entweder alles offenlegen oder alles verbergen“, sondern man hat inmitten dieser beiden Extreme einen kontrollierbaren Kanal geschaffen.
Am Anfang dachte ich, dass dieses „selektiv“ durch manuelle Schritte außerhalb der Kette (off-chain) erreicht wird – also wenn etwas passiert, dann über einen Offline-Prozess die Transaktionsprotokolle exportieren, damit die Aufsicht sie sehen kann. Nachdem ich aber erst recherchiert habe, stellte sich heraus, dass es nicht so ist. Die offizielle Darstellung lautet vielmehr, dass diese Fähigkeit direkt über kryptografische Werkzeuge im Protokoll umgesetzt ist: Nutzer oder Institutionen entscheiden selbst, ob sie ein Zertifikat/Attest erzeugen wollen, das nur bestimmten Objekten zur Einsicht bereitsteht. Man muss sich nicht nachträglich bei irgendjemandem anpingen, damit er „im Backend“ eine Datenbankabfrage durchführt. Diese Fehlannahme habe ich erst nach zweimaligem Lesen der Erklärungen korrigiert – am Anfang war sie tatsächlich zu simpel.
Aber ich muss auch offen sagen: In den offiziellen Unterlagen werden die Ausführungsdetails zu „wer die Anfrage für diese Offenlegung stellen darf“ sowie „wie detailliert diese Bescheinigung/der Nachweis eingesehen werden kann“ recht allgemein gehalten. Es gibt keine konkrete Schritt-für-Schritt-Anleitung, der man einfach folgen könnte. Das bedeutet: „Selektive Offenlegung“ ist aktuell eher eine Fähigkeit auf Protokollebene, die zwar vorhanden ist, aber wie man sie in einem konkreten echten Szenario anwendet, wer den Auslöser setzt und wie lange der Genehmigungsprozess dauert – das hängt vermutlich davon ab, wie das später mit Kooperationspartnern wie NPEX in Produkten tatsächlich umgesetzt wird. In dieser Runde konnte ich kein bereits durchgeführtes konkretes Beispiel finden. Ich kann daher erst mal nur bestätigen, dass die Fähigkeit existiert, und nicht beurteilen, ob sie sich in der Praxis gut oder umständlich bedienen lässt.