Ich habe mir die Datenschutzarchitektur von Dusk genauer angesehen, und ein Punkt, zu dem ich immer wieder zurückkomme, ist, wie stark alles davon abhängt, dass die einzelnen Komponenten zusammenspielen – statt von irgendeiner einzelnen kryptografischen Grundprimitive. Zunächst wirkte es wie sehr viel, BLS12-381, JubJub, Schnorr, Poseidon und PLONK gemeinsam zu überblicken. Aber nachdem ich mir angeschaut habe, was jede Komponente tatsächlich macht, wurde die Struktur deutlich leichter zu verstehen.
BLS12-381 liegt unter vielem aus Signatur- und ZK-Infrastruktur, während JubJub in der Phoenix-Privacy-Layer verwendet wird, weil sein Design gut mit SNARK-basierten Systemen funktioniert. Schnorr übernimmt Authentifizierung und Signaturen, und Poseidon kümmert sich um das Hashing innerhalb von ZK-Schaltkreisen, wo herkömmliches Hashing relativ teuer werden kann. Sparse Merkle Trees helfen anschließend bei Zustands- und Mitgliedschaftsbeweisen, während PLONK den Rahmen für das Prüfen und Verifizieren bereitstellt. BLS-Aggregation fügt noch eine praktische Ebene hinzu, indem sie mehrere Unterschriften von Komitees kombiniert und den Verifizierungsaufwand reduziert.
Trotzdem glaube ich nicht, dass mir die bloße Liste der Primitiven dafür allein genug sagt. Bei der Implementierung würde ich als Erstes anfangen, genauer hinzuschauen. Serialisierung, Subgruppen-Checks, Transcript-Bindung und Domain Separation können allesamt sicherheitsrelevante Details werden.
Meine Hauptfrage ist daher ganz einfach: Wie gut hält dieser sorgfältig entwickelte Stack stand, wenn bei realer Nutzung, bei Leistungsanforderungen und unter adversarialen Bedingungen mehr Druck auf ihn ausgeübt wird?
$PORTAL
$GPS
$DUSK
@Dusk_Foundation #dusk
BLS12-381 liegt unter vielem aus Signatur- und ZK-Infrastruktur, während JubJub in der Phoenix-Privacy-Layer verwendet wird, weil sein Design gut mit SNARK-basierten Systemen funktioniert. Schnorr übernimmt Authentifizierung und Signaturen, und Poseidon kümmert sich um das Hashing innerhalb von ZK-Schaltkreisen, wo herkömmliches Hashing relativ teuer werden kann. Sparse Merkle Trees helfen anschließend bei Zustands- und Mitgliedschaftsbeweisen, während PLONK den Rahmen für das Prüfen und Verifizieren bereitstellt. BLS-Aggregation fügt noch eine praktische Ebene hinzu, indem sie mehrere Unterschriften von Komitees kombiniert und den Verifizierungsaufwand reduziert.
Trotzdem glaube ich nicht, dass mir die bloße Liste der Primitiven dafür allein genug sagt. Bei der Implementierung würde ich als Erstes anfangen, genauer hinzuschauen. Serialisierung, Subgruppen-Checks, Transcript-Bindung und Domain Separation können allesamt sicherheitsrelevante Details werden.
Meine Hauptfrage ist daher ganz einfach: Wie gut hält dieser sorgfältig entwickelte Stack stand, wenn bei realer Nutzung, bei Leistungsanforderungen und unter adversarialen Bedingungen mehr Druck auf ihn ausgeübt wird?
$PORTAL
$GPS
$DUSK
@Dusk_Foundation #dusk