#dusk $DUSK
Ich habe diese Woche durch die Schlüsselstruktur von Phoenix gearbeitet, weil ich verstehen wollte, was ein View Key einem wirklich gibt – und wie er sich davon unterscheidet, einfach nur Zugang weiterzugeben.
Phoenix-View-Keys: Das Whitepaper definiert den View Key als (a, B) – ein partielles Geheimnis, das es einer dritten Partei erlaubt, das Netzwerk zu scannen, um zu erkennen, welche Transaktionen an dich adressiert sind. Sie können sehen, was eingeht. Sie können den Note-Secret-Key nicht berechnen, also können sie nichts ausgeben. Scannen ohne auszugeben.
Die Generierung von ZK-Beweisen ist separat delegierbar. Für eine Transaktion ist ein Zero-Knowledge-Proof erforderlich. Diese Beweiserstellung ist rechnerisch aufwendig und kann an eine vertrauenswürdige Partei ausgelagert werden, indem Signaturen verwendet werden – ohne ihr Zugriff auf deinen vollständigen privaten Schlüssel zu geben. Die Integrität der Transaktion wird nicht beeinträchtigt, weil die Signatur sie an deinen Schlüssel bindet, selbst wenn der Beweis woanders generiert wurde.
Das ist solide. Zwei Delegationsstufen, klar getrennt: eine für Audit-Zugriff im Stil von Audits, eine für die Auslagerung von Berechnungen.
Was schwerer zu durchdenken ist, sind die Datenschutzkosten jeder Stufe. Der View-Key-Delegate weiß, welche Transaktionen deine sind. „Nicht ausgeben können“ heißt nicht „nichts wissen“ – es bedeutet, dass sie ein Bild deiner gesamten Empfangshistorie erstellen können. Für einen Compliance-Use-Case ist das möglicherweise genau das, was benötigt wird. Für einen einzelnen Nutzer ist die Übergabe eines View Keys an einen Dienst eine bedeutende Offenlegung, auch wenn keine Gelder fließen.
Ich denke sogar, dass die Delegation der Beweise aus Datenschutzsicht sauberer ist – der Beweisersteller erfährt nichts über den Inhalt der Transaktion, wenn das Protokoll korrekt strukturiert ist. Der View Key ist derjenige, der die eigentliche Information trägt.
Was mir noch nicht klar ist, ist, ob Audit-Use-Cases für Phoenix den View Key tatsächlich direkt verwenden, oder ob es Mechanismen zur selektiven Offenlegung gibt, sodass nur bestimmte Transaktionen statt der gesamten Empfangshistorie offengelegt werden. @Dusk
$DUSK #dusk
Ich habe diese Woche durch die Schlüsselstruktur von Phoenix gearbeitet, weil ich verstehen wollte, was ein View Key einem wirklich gibt – und wie er sich davon unterscheidet, einfach nur Zugang weiterzugeben.
Phoenix-View-Keys: Das Whitepaper definiert den View Key als (a, B) – ein partielles Geheimnis, das es einer dritten Partei erlaubt, das Netzwerk zu scannen, um zu erkennen, welche Transaktionen an dich adressiert sind. Sie können sehen, was eingeht. Sie können den Note-Secret-Key nicht berechnen, also können sie nichts ausgeben. Scannen ohne auszugeben.
Die Generierung von ZK-Beweisen ist separat delegierbar. Für eine Transaktion ist ein Zero-Knowledge-Proof erforderlich. Diese Beweiserstellung ist rechnerisch aufwendig und kann an eine vertrauenswürdige Partei ausgelagert werden, indem Signaturen verwendet werden – ohne ihr Zugriff auf deinen vollständigen privaten Schlüssel zu geben. Die Integrität der Transaktion wird nicht beeinträchtigt, weil die Signatur sie an deinen Schlüssel bindet, selbst wenn der Beweis woanders generiert wurde.
Das ist solide. Zwei Delegationsstufen, klar getrennt: eine für Audit-Zugriff im Stil von Audits, eine für die Auslagerung von Berechnungen.
Was schwerer zu durchdenken ist, sind die Datenschutzkosten jeder Stufe. Der View-Key-Delegate weiß, welche Transaktionen deine sind. „Nicht ausgeben können“ heißt nicht „nichts wissen“ – es bedeutet, dass sie ein Bild deiner gesamten Empfangshistorie erstellen können. Für einen Compliance-Use-Case ist das möglicherweise genau das, was benötigt wird. Für einen einzelnen Nutzer ist die Übergabe eines View Keys an einen Dienst eine bedeutende Offenlegung, auch wenn keine Gelder fließen.
Ich denke sogar, dass die Delegation der Beweise aus Datenschutzsicht sauberer ist – der Beweisersteller erfährt nichts über den Inhalt der Transaktion, wenn das Protokoll korrekt strukturiert ist. Der View Key ist derjenige, der die eigentliche Information trägt.
Was mir noch nicht klar ist, ist, ob Audit-Use-Cases für Phoenix den View Key tatsächlich direkt verwenden, oder ob es Mechanismen zur selektiven Offenlegung gibt, sodass nur bestimmte Transaktionen statt der gesamten Empfangshistorie offengelegt werden. @Dusk
$DUSK #dusk