Bitte blättert mit mir weiter zum 6. Kapitel des Whitepapers
Der Titel ist sehr schlicht: Cryptographic Primitives. Dieses Kapitel ist wirklich die Grundlage hinter der Privatsphäre—@Dusk
Was wir vorher über Konsens und das Transaktionsmodell gesprochen haben, sind im Grunde nur Häuser, die auf dieser Fundamentebene stehen.
Ich habe ein sehr klares Muster erkannt: Fast jedes einzelne Bauteil ist in einer „Dual-Track-Konfiguration“ aufgebaut.
Für Hashes läuft erst einmal Blake2b für allgemeine Berechnungen, dazu kommt noch ein Poseidon, das speziell für Zero-Knowledge-Beweise zuständig ist; Signaturen werden für den Alltag mit Schnorr abgewickelt und anschließend mit BLS für aggregierbare Signaturen ergänzt; sogar die Kurven sind zweigeteilt—JubJub übernimmt die normalen Operationen, BLS12-381 ist für Pairings zuständig.
Meine Einschätzung: Das ist kein „Haufen Zeug“, sondern so gewählt, weil die Anforderungen an Hashes in ZK-Szenarien und in normalen Anwendungsfällen völlig unterschiedlich sind. Man könnte zwar etwas zusammenwürfeln, aber das wäre an beiden Enden unbequem. Also hat man einfach jeweils ein eigenes Setup.
Am meisten beeindruckt mich die Stealth-Adresse: Sie gibt dir nicht eine feste Adresse, die du bis zum Ende immer wieder verwendest, sondern erzeugt für jede Transaktion direkt eine einmalige Public Key—basierend auf einem Diffie-Hellman-Schlüsselaustausch.
Der Empfänger zeigt nur den „public spend key“. Der Sender nimmt dann eine Zufallszahl r, berechnet daraus den einmaligen Public Key und überweist das Geld. Der Empfänger scannt anschließend mit seinem view key die Transaktion, um zu erkennen: „Diese Zahlung ist für mich“. Wenn man das Geld wirklich ausgeben will, muss man dann den secret spend key verwenden.
Schauen, empfangen, ausgeben—drei Schlüssel, jeweils für einen Teil verantwortlich. Ich finde, das ist deutlich klüger als „eine Adresse bis ans Ende aller Tage verwenden“. So kann niemand auf der Kette deine vielen einzelnen Zahlungen in eine einzige zusammenhängende Linie verknüpfen.
Beim Commitmentscheme nutzt man Pedersen: c = v·G + b·H. G und H sind zwei Generatoren mit unbekannter Beziehung. So lassen sich Beträge verbergen, und außerdem kann man nachträglich nicht betrügerisch einen anderen Wert behaupten.
Auch bei der Verschlüsselung gibt es Zweck-Werkzeuge: ElGamal ist für asymmetrische Fälle zuständig, während Poseidon-SpongeWrap für symmetrische Anwendungen verwendet wird.
Sogar bei Merkle-Bäumen wird nicht faul gemacht: Die generische Struktur verwendet Blake2b für das Hashing, und alle Strukturen, die man für ZK-Beweise „füttern“ muss, werden konsequent durch Poseidon ersetzt. Die gleiche Denkweise wird bis zum Schluss durchgezogen.
Ehrlich gesagt hat mich dieses Maß an Detailaufteilung ein wenig überrascht.
Die meisten Whitepapers kommen in diesem Abschnitt nur mit einem Satz: „Wir übernehmen etablierte, branchenübliche Lösungen“—#dusk $DUSK @Dusk
Der Titel ist sehr schlicht: Cryptographic Primitives. Dieses Kapitel ist wirklich die Grundlage hinter der Privatsphäre—@Dusk
Was wir vorher über Konsens und das Transaktionsmodell gesprochen haben, sind im Grunde nur Häuser, die auf dieser Fundamentebene stehen.
Ich habe ein sehr klares Muster erkannt: Fast jedes einzelne Bauteil ist in einer „Dual-Track-Konfiguration“ aufgebaut.
Für Hashes läuft erst einmal Blake2b für allgemeine Berechnungen, dazu kommt noch ein Poseidon, das speziell für Zero-Knowledge-Beweise zuständig ist; Signaturen werden für den Alltag mit Schnorr abgewickelt und anschließend mit BLS für aggregierbare Signaturen ergänzt; sogar die Kurven sind zweigeteilt—JubJub übernimmt die normalen Operationen, BLS12-381 ist für Pairings zuständig.
Meine Einschätzung: Das ist kein „Haufen Zeug“, sondern so gewählt, weil die Anforderungen an Hashes in ZK-Szenarien und in normalen Anwendungsfällen völlig unterschiedlich sind. Man könnte zwar etwas zusammenwürfeln, aber das wäre an beiden Enden unbequem. Also hat man einfach jeweils ein eigenes Setup.
Am meisten beeindruckt mich die Stealth-Adresse: Sie gibt dir nicht eine feste Adresse, die du bis zum Ende immer wieder verwendest, sondern erzeugt für jede Transaktion direkt eine einmalige Public Key—basierend auf einem Diffie-Hellman-Schlüsselaustausch.
Der Empfänger zeigt nur den „public spend key“. Der Sender nimmt dann eine Zufallszahl r, berechnet daraus den einmaligen Public Key und überweist das Geld. Der Empfänger scannt anschließend mit seinem view key die Transaktion, um zu erkennen: „Diese Zahlung ist für mich“. Wenn man das Geld wirklich ausgeben will, muss man dann den secret spend key verwenden.
Schauen, empfangen, ausgeben—drei Schlüssel, jeweils für einen Teil verantwortlich. Ich finde, das ist deutlich klüger als „eine Adresse bis ans Ende aller Tage verwenden“. So kann niemand auf der Kette deine vielen einzelnen Zahlungen in eine einzige zusammenhängende Linie verknüpfen.
Beim Commitmentscheme nutzt man Pedersen: c = v·G + b·H. G und H sind zwei Generatoren mit unbekannter Beziehung. So lassen sich Beträge verbergen, und außerdem kann man nachträglich nicht betrügerisch einen anderen Wert behaupten.
Auch bei der Verschlüsselung gibt es Zweck-Werkzeuge: ElGamal ist für asymmetrische Fälle zuständig, während Poseidon-SpongeWrap für symmetrische Anwendungen verwendet wird.
Sogar bei Merkle-Bäumen wird nicht faul gemacht: Die generische Struktur verwendet Blake2b für das Hashing, und alle Strukturen, die man für ZK-Beweise „füttern“ muss, werden konsequent durch Poseidon ersetzt. Die gleiche Denkweise wird bis zum Schluss durchgezogen.
Ehrlich gesagt hat mich dieses Maß an Detailaufteilung ein wenig überrascht.
Die meisten Whitepapers kommen in diesem Abschnitt nur mit einem Satz: „Wir übernehmen etablierte, branchenübliche Lösungen“—#dusk $DUSK @Dusk