#dusk $DUSK @Dusk
Ich habe zunächst DUSKs kryptografische Architektur als die Frage betrachtet, welche Primitive sie verwendet.
Dann begann ich, einen Merkle-Pfad und Hedgers Transaktionsablauf nachzuverfolgen, und es zeigte sich ein interessanteres Muster:
DUSK versucht nicht, weniger Kryptografie zu verwenden. Es versucht, unterschiedliche Kryptografie dort zu platzieren, wo sie am meisten Sinn ergibt.
BLS12-381 für Proof- und Signaturoperationen. Jubjub für datenschutzorientierte Circuit-Arbeit. Poseidon für Hashing in ZK-Umgebungen.
Diese Unterscheidung ist wichtig, weil normale Berechnung und ZK-Berechnung sehr unterschiedliche Kostenstrukturen haben. Ein Hash, der in einem herkömmlichen System effizient ist, kann teuer werden, sobald er in Circuit-Constraints übersetzt wird.
BLS-Aggregation fügt noch eine weitere Ebene hinzu: Mehrere Attestierungen können aggregiert werden, wodurch der Verifizierungsaufwand und der Daten-druck sinken.
Zunächst wirkt das wie eine einfache Effizienzgeschichte.
Aber es gibt einen Widerspruch, den ich spannender finde:
Je stärker man Kryptografie spezialisiert, desto effizienter können einzelne Operationen werden, während die Gesamtarchitektur zugleich schwerer zu durchschauen sein kann.
Ich sehe dasselbe Problem, wenn ich über Hedgers Wirtschaftlichkeit nachdenke.
Eine vertrauliche Transaktion ist nicht einfach „Gas + Kryptografie“. Ihre Kosten können aus HE, ZK-Proving/Verifikation, DuskEVM-Ausführung und DuskDS-Datenverfügbarkeit stammen:
Ctotal = CHE + CZK + CEVM + CDA
Daher macht es selbst dann nicht unbedingt Privatsphäre 2x günstiger, wenn ZK 2x schneller wird.
Darum glaube ich, dass DUSKs eigentliches Skalierbarkeitstesten nicht nur darin besteht, wie schnell seine Kryptografie wird.
Es ist die Frage, ob spezialisierte Kryptografie, Ausführung und Datenverfügbarkeit gemeinsam skaliieren können, ohne dass die Architektur selbst zum Engpass wird.
Diesen Benchmark werde ich im Blick behalten.
Ich habe zunächst DUSKs kryptografische Architektur als die Frage betrachtet, welche Primitive sie verwendet.
Dann begann ich, einen Merkle-Pfad und Hedgers Transaktionsablauf nachzuverfolgen, und es zeigte sich ein interessanteres Muster:
DUSK versucht nicht, weniger Kryptografie zu verwenden. Es versucht, unterschiedliche Kryptografie dort zu platzieren, wo sie am meisten Sinn ergibt.
BLS12-381 für Proof- und Signaturoperationen. Jubjub für datenschutzorientierte Circuit-Arbeit. Poseidon für Hashing in ZK-Umgebungen.
Diese Unterscheidung ist wichtig, weil normale Berechnung und ZK-Berechnung sehr unterschiedliche Kostenstrukturen haben. Ein Hash, der in einem herkömmlichen System effizient ist, kann teuer werden, sobald er in Circuit-Constraints übersetzt wird.
BLS-Aggregation fügt noch eine weitere Ebene hinzu: Mehrere Attestierungen können aggregiert werden, wodurch der Verifizierungsaufwand und der Daten-druck sinken.
Zunächst wirkt das wie eine einfache Effizienzgeschichte.
Aber es gibt einen Widerspruch, den ich spannender finde:
Je stärker man Kryptografie spezialisiert, desto effizienter können einzelne Operationen werden, während die Gesamtarchitektur zugleich schwerer zu durchschauen sein kann.
Ich sehe dasselbe Problem, wenn ich über Hedgers Wirtschaftlichkeit nachdenke.
Eine vertrauliche Transaktion ist nicht einfach „Gas + Kryptografie“. Ihre Kosten können aus HE, ZK-Proving/Verifikation, DuskEVM-Ausführung und DuskDS-Datenverfügbarkeit stammen:
Ctotal = CHE + CZK + CEVM + CDA
Daher macht es selbst dann nicht unbedingt Privatsphäre 2x günstiger, wenn ZK 2x schneller wird.
Darum glaube ich, dass DUSKs eigentliches Skalierbarkeitstesten nicht nur darin besteht, wie schnell seine Kryptografie wird.
Es ist die Frage, ob spezialisierte Kryptografie, Ausführung und Datenverfügbarkeit gemeinsam skaliieren können, ohne dass die Architektur selbst zum Engpass wird.
Diesen Benchmark werde ich im Blick behalten.