#dusk $DUSK @Dusk
Lies mehr zu Dusk, ich glaube immer stärker, dass das Thema „Privatsphäre“ nicht nur Phoenix und ZK-Beweise (Zero-Knowledge-Proofs) zu verdanken ist – im Whitepaper steckt eine leicht zu übersehende Schutzschicht, die direkt aus der P2P-Netzwerkschicht selbst kommt und überhaupt nichts mit den Kryptografie-Algorithmen zu tun hat.
Das von Dusk verwendete P2P-Protokoll heißt Kadcast und basiert auf der Kademlia-Struktur für verteilte Hash-Tabellen. In Section 2.3 des Whitepapers gibt es einen Detailpunkt, der sich lohnt, genauer anzuschauen: Die Broadcast-Mechanik von Kadcast versendet Nachrichten nicht auf einmal an alle Nachbarknoten, sondern leitet sie nur an eine bestimmte Gruppe von Knoten weiter – basierend auf der XOR-Distanz zwischen den Knoten. Diese Knoten leiten die Nachrichten anschließend weiter nach außen, stufenweise kaskadenartig. Diese Struktur hat einen Nebeneffekt: Da eine Nachricht nicht direkt vom Absender an jeden Empfänger gelangt, sondern über mehrere „Zwischenstationen“ umgeleitet wird, steigt die Schwierigkeit, zurückzuverfolgen, von welchem Knoten die Nachricht ursprünglich gesendet wurde, deutlich. Eigentlich ist das so entworfen, um die Bandbreiteneffizienz zu optimieren, und verwischt dabei ganz nebenbei auch die Herkunft der Nachricht.
Das bringt mich dazu, noch einmal darüber nachzudenken, wie man die „Privacy Chain“ (Privatsphärenkette) eigentlich bewerten sollte. Wenn nur die Phoenix-Schicht Privatsphäre gewährleistet, sind die Transaktionsinhalte zwar wirklich vertraulich. Aber das Broadcast-Verhalten zwischen den Knoten: Wenn die Netzwerkschicht so etwas wie „One-to-Many“-direktes Gruppenversenden ist, könnte man theoretisch von den beobachtenden Knoten Standorte und Muster nutzen, um Traffic-Analysen zu machen und indirekt Informationen abzuleiten – wer wann was ausgesendet hat. Selbst wenn man den Inhalt nicht versteht, ist das Verhalten selbst schon eine Informationsabgabe. Die geschichtete Weiterleitungsstruktur von Kadcast fügt neben der kryptografischen Privatsphäre noch eine zusätzliche Netzwerkebene der Vermischung hinzu; zwei Schichten überlagern sich so. Wenn man nur eine der Schichten einzeln durchbricht, reicht das nicht aus, um die Quelle wirklich zu lokalisieren.
Wenn Leute über Privacy Chains sprechen, schauen sie üblicherweise automatisch nur darauf, welche Verschlüsselungslösung und welches zk-SNARK oder Beweissystem verwendet wird. Nur selten fragt jemand noch eine Ebene tiefer nach, wie die P2P-Schicht gestaltet ist – diese Ebene wird im Alltag kaum wahrgenommen, aber gerade dort setzen Angriffe wie Traffic-Analysen am ehesten an.
Was denkt ihr: Bei der Bewertung einer Privacy Chain sollte man das Netzwerkdesign als eigenen, separaten Kennwert herausziehen und separat berücksichtigen?
Lies mehr zu Dusk, ich glaube immer stärker, dass das Thema „Privatsphäre“ nicht nur Phoenix und ZK-Beweise (Zero-Knowledge-Proofs) zu verdanken ist – im Whitepaper steckt eine leicht zu übersehende Schutzschicht, die direkt aus der P2P-Netzwerkschicht selbst kommt und überhaupt nichts mit den Kryptografie-Algorithmen zu tun hat.
Das von Dusk verwendete P2P-Protokoll heißt Kadcast und basiert auf der Kademlia-Struktur für verteilte Hash-Tabellen. In Section 2.3 des Whitepapers gibt es einen Detailpunkt, der sich lohnt, genauer anzuschauen: Die Broadcast-Mechanik von Kadcast versendet Nachrichten nicht auf einmal an alle Nachbarknoten, sondern leitet sie nur an eine bestimmte Gruppe von Knoten weiter – basierend auf der XOR-Distanz zwischen den Knoten. Diese Knoten leiten die Nachrichten anschließend weiter nach außen, stufenweise kaskadenartig. Diese Struktur hat einen Nebeneffekt: Da eine Nachricht nicht direkt vom Absender an jeden Empfänger gelangt, sondern über mehrere „Zwischenstationen“ umgeleitet wird, steigt die Schwierigkeit, zurückzuverfolgen, von welchem Knoten die Nachricht ursprünglich gesendet wurde, deutlich. Eigentlich ist das so entworfen, um die Bandbreiteneffizienz zu optimieren, und verwischt dabei ganz nebenbei auch die Herkunft der Nachricht.
Das bringt mich dazu, noch einmal darüber nachzudenken, wie man die „Privacy Chain“ (Privatsphärenkette) eigentlich bewerten sollte. Wenn nur die Phoenix-Schicht Privatsphäre gewährleistet, sind die Transaktionsinhalte zwar wirklich vertraulich. Aber das Broadcast-Verhalten zwischen den Knoten: Wenn die Netzwerkschicht so etwas wie „One-to-Many“-direktes Gruppenversenden ist, könnte man theoretisch von den beobachtenden Knoten Standorte und Muster nutzen, um Traffic-Analysen zu machen und indirekt Informationen abzuleiten – wer wann was ausgesendet hat. Selbst wenn man den Inhalt nicht versteht, ist das Verhalten selbst schon eine Informationsabgabe. Die geschichtete Weiterleitungsstruktur von Kadcast fügt neben der kryptografischen Privatsphäre noch eine zusätzliche Netzwerkebene der Vermischung hinzu; zwei Schichten überlagern sich so. Wenn man nur eine der Schichten einzeln durchbricht, reicht das nicht aus, um die Quelle wirklich zu lokalisieren.
Wenn Leute über Privacy Chains sprechen, schauen sie üblicherweise automatisch nur darauf, welche Verschlüsselungslösung und welches zk-SNARK oder Beweissystem verwendet wird. Nur selten fragt jemand noch eine Ebene tiefer nach, wie die P2P-Schicht gestaltet ist – diese Ebene wird im Alltag kaum wahrgenommen, aber gerade dort setzen Angriffe wie Traffic-Analysen am ehesten an.
Was denkt ihr: Bei der Bewertung einer Privacy Chain sollte man das Netzwerkdesign als eigenen, separaten Kennwert herausziehen und separat berücksichtigen?
A. 该单独算,经常被忽略
100%
B. 不用,加密层够了
0%
C. 看具体资产敏感度
0%
1 Stimmen • Abstimmung beendet