竹竹看#Dusk 的密碼選型,最直覺的感受 ist, dass es nicht der „neuesten“ Entwicklung hinterherjagt, sondern die „am besten passende“ auswählt.
BLS12-381 wird in Moonlight und der Konsensschicht verwendet, Jubjub für Phoenix; diese Aufteilung ist bemerkenswert zurückhaltend. BLS12-381s aggregierbare Signaturen passen sich natürlich gut zu Szenarien für Konsensabstimmungen an: Hunderte von Knotensignaturen lassen sich zu einer einzigen zusammenfassen, und die Verifikationskosten sind extrem niedrig. Jubjub ist eine Kurve, die speziell für Zero-Knowledge-Schaltkreise entworfen wurde; bei der Erstellung von ZK-Beweisen im Phoenix-UTXO-Modell ist sie effizienter. Beide Kurven haben ihre klare Aufgabe und es wurde nichts „als Einheitslösung“ erzwungen.
Beim Hashing wurde Poseidon gewählt, und diese Entscheidung ist sehr treffend.
Poseidon ist ein algebraischer Hash, der speziell für ZK-Schaltkreise optimiert wurde; verglichen mit SHA-256 sind in Schaltkreisen nur wenige Größenordnungen der Gates nötig. Das bestimmt direkt die Geschwindigkeit und die Kosten der Beweiserstellung. Für Finanzszenarien ist wichtiger, wie viele vertrauliche Transaktionen pro Sekunde verarbeitet werden können, als wie „klassisch“ der Hash-Algorithmus an sich ist.
Auch das Abwägen zwischen Plonk und Groth16 ist erwähnenswert.
Groth16 hat kurze Beweise und schnelle Verifikation, benötigt aber eine vertrauenswürdige Initialisierung; Plonk kommt ohne vertrauenswürdige Einrichtung aus und ist universeller, dafür sind die Beweise etwas größer.
Dusk nutzt beides—sehr wahrscheinlich abhängig von den unterschiedlichen Anforderungen der jeweiligen Szenarien: Wo maximale Verifikationseffizienz gebraucht wird, wird Groth16 eingesetzt; wo Flexibilität und Prüfbarkeit wichtig sind, Plonk.
Beim Signatursystem gilt ebenfalls: In der Konsensschicht wird BLS aggregiert, in der Transaktionsschicht Schnorr—auch hier ist es szenariengetrieben. Schnorr ist für Transaktionssignaturen kompakter und unterstützt Multi-Signature-Aggregation, was gut zu Nutzer-Transfer-Szenarien passt.
Insgesamt betrachtet hat Dusk bei der Kryptografieauswahl keinen Spieltrieb mit „Showeffekten“: Jede Auswahl adressiert eine konkrete Performance-Engstelle, einen Sicherheitsbedarf oder regulatorische Vorgaben. Diese Haltung „Genug ist gut“ wirkt eher vertrauenswürdiger als das bloße Zusammenschrauben von Frontend-Algorithmen.
#dusk $DUSK @Dusk
Frage: Welche Kurve, die speziell für Zero-Knowledge-Schaltkreise entworfen wurde, verwendet das Phoenix-Modell von Dusk?
BLS12-381 wird in Moonlight und der Konsensschicht verwendet, Jubjub für Phoenix; diese Aufteilung ist bemerkenswert zurückhaltend. BLS12-381s aggregierbare Signaturen passen sich natürlich gut zu Szenarien für Konsensabstimmungen an: Hunderte von Knotensignaturen lassen sich zu einer einzigen zusammenfassen, und die Verifikationskosten sind extrem niedrig. Jubjub ist eine Kurve, die speziell für Zero-Knowledge-Schaltkreise entworfen wurde; bei der Erstellung von ZK-Beweisen im Phoenix-UTXO-Modell ist sie effizienter. Beide Kurven haben ihre klare Aufgabe und es wurde nichts „als Einheitslösung“ erzwungen.
Beim Hashing wurde Poseidon gewählt, und diese Entscheidung ist sehr treffend.
Poseidon ist ein algebraischer Hash, der speziell für ZK-Schaltkreise optimiert wurde; verglichen mit SHA-256 sind in Schaltkreisen nur wenige Größenordnungen der Gates nötig. Das bestimmt direkt die Geschwindigkeit und die Kosten der Beweiserstellung. Für Finanzszenarien ist wichtiger, wie viele vertrauliche Transaktionen pro Sekunde verarbeitet werden können, als wie „klassisch“ der Hash-Algorithmus an sich ist.
Auch das Abwägen zwischen Plonk und Groth16 ist erwähnenswert.
Groth16 hat kurze Beweise und schnelle Verifikation, benötigt aber eine vertrauenswürdige Initialisierung; Plonk kommt ohne vertrauenswürdige Einrichtung aus und ist universeller, dafür sind die Beweise etwas größer.
Dusk nutzt beides—sehr wahrscheinlich abhängig von den unterschiedlichen Anforderungen der jeweiligen Szenarien: Wo maximale Verifikationseffizienz gebraucht wird, wird Groth16 eingesetzt; wo Flexibilität und Prüfbarkeit wichtig sind, Plonk.
Beim Signatursystem gilt ebenfalls: In der Konsensschicht wird BLS aggregiert, in der Transaktionsschicht Schnorr—auch hier ist es szenariengetrieben. Schnorr ist für Transaktionssignaturen kompakter und unterstützt Multi-Signature-Aggregation, was gut zu Nutzer-Transfer-Szenarien passt.
Insgesamt betrachtet hat Dusk bei der Kryptografieauswahl keinen Spieltrieb mit „Showeffekten“: Jede Auswahl adressiert eine konkrete Performance-Engstelle, einen Sicherheitsbedarf oder regulatorische Vorgaben. Diese Haltung „Genug ist gut“ wirkt eher vertrauenswürdiger als das bloße Zusammenschrauben von Frontend-Algorithmen.
#dusk $DUSK @Dusk
Frage: Welche Kurve, die speziell für Zero-Knowledge-Schaltkreise entworfen wurde, verwendet das Phoenix-Modell von Dusk?
A: Jubjub
90%
B: BLS12-381
10%
C: Secp256k1
0%
10 Stimmen • Abstimmung beendet