Bedeutet ein Zero-Knowledge-Beweis automatisch 100% „trustless“?
Es klingt so, als sollte es so sein. Niemand sieht das Geheimnis, und die Mathematik verifiziert den Beweis.
Aber Dusk’s eigenes Citadel-Paper weist auf eine weniger angenehme Schicht unter PLONK hin: das „trusted setup“.
Dusk’s PLONK-Implementierung läuft über BLS12-381 und nutzt KZG10 als Standard-Schema für den polynomialen Commitments. KZG benötigt eine Common Reference String, die aus geheimer Zufallszahlgenerierung entsteht. Wenn dieses „toxische Abfallmaterial“ überlebt und zu einem Angreifer gelangt, kann die Annahme der Schlüssigkeit (Soundness) brechen.
Das Citadel-Paper sagt das ganz offen: kompromittierte Setup-Zufallsdaten könnten falsche Transaktionen ermöglichen und „enorme Geldverluste“ verursachen. Für Citadel heißt das: die Konsequenz wären Nutzer-Impersonationen und die Nutzung von Lizenzen anderer Leute.
Was bedeutet „trusted setup“ also tatsächlich?
Nicht darauf vertrauen, dass ein einzelnes Unternehmen einen Master-Password hat.
Eine Zeremonie erlaubt es mehreren Teilnehmenden, nacheinander ihre eigene Zufallsanbindung hinzuzufügen. Jeder zerstört danach seinen privaten Beitrag. Die entscheidende Eigenschaft ist, dass das Setup weiterhin sicher bleibt, wenn auch nur ein Teilnehmer ehrlich war und sein Geheimnis dauerhaft verworfen hat.
Das ließ mich fragen: Wer hat an Dusk’s Zeremonie teilgenommen?
Das ist tatsächlich besser dokumentiert, als ich erwartet hätte.
Das öffentliche Repository für Dusk’s „trusted setup“ sagt, es startete mit der verifizierten Zcash Powers-of-Tau-Antwort #87 und fügte dann 15 aufgelistete Dusk-Mitwirkende hinzu. Das Repo legt Beitragsaufzeichnungen und Verifikationsschritte offen, während Dusk sagte, dass die Ergebnisse öffentlich sein würden, damit andere sie überprüfen können.
Das beweist jedoch nicht jede operative Annahme für immer. Ich würde trotzdem gern wissen, ob die Produktionsparameter mit dem veröffentlichten Transkript übereinstimmen und wie unabhängig diese Verknüpfung heute in der Praxis geprüft wurde.
Also wird die faire Frage etwas konkreter: Kann ich die Live-kryptografischen Parameter bis auf die öffentlich verifizierbare Zeremonie zurückverfolgen?
Wenn ein Projekt offen eine kryptografische Schwäche in seinem eigenen Paper zugibt, schafft das mehr Vertrauen durch Transparenz — oder macht es dich nur noch mehr dazu, wissen zu wollen, wie real dieses Risiko tatsächlich noch ist?
#dusk $DUSK @Dusk
Es klingt so, als sollte es so sein. Niemand sieht das Geheimnis, und die Mathematik verifiziert den Beweis.
Aber Dusk’s eigenes Citadel-Paper weist auf eine weniger angenehme Schicht unter PLONK hin: das „trusted setup“.
Dusk’s PLONK-Implementierung läuft über BLS12-381 und nutzt KZG10 als Standard-Schema für den polynomialen Commitments. KZG benötigt eine Common Reference String, die aus geheimer Zufallszahlgenerierung entsteht. Wenn dieses „toxische Abfallmaterial“ überlebt und zu einem Angreifer gelangt, kann die Annahme der Schlüssigkeit (Soundness) brechen.
Das Citadel-Paper sagt das ganz offen: kompromittierte Setup-Zufallsdaten könnten falsche Transaktionen ermöglichen und „enorme Geldverluste“ verursachen. Für Citadel heißt das: die Konsequenz wären Nutzer-Impersonationen und die Nutzung von Lizenzen anderer Leute.
Was bedeutet „trusted setup“ also tatsächlich?
Nicht darauf vertrauen, dass ein einzelnes Unternehmen einen Master-Password hat.
Eine Zeremonie erlaubt es mehreren Teilnehmenden, nacheinander ihre eigene Zufallsanbindung hinzuzufügen. Jeder zerstört danach seinen privaten Beitrag. Die entscheidende Eigenschaft ist, dass das Setup weiterhin sicher bleibt, wenn auch nur ein Teilnehmer ehrlich war und sein Geheimnis dauerhaft verworfen hat.
Das ließ mich fragen: Wer hat an Dusk’s Zeremonie teilgenommen?
Das ist tatsächlich besser dokumentiert, als ich erwartet hätte.
Das öffentliche Repository für Dusk’s „trusted setup“ sagt, es startete mit der verifizierten Zcash Powers-of-Tau-Antwort #87 und fügte dann 15 aufgelistete Dusk-Mitwirkende hinzu. Das Repo legt Beitragsaufzeichnungen und Verifikationsschritte offen, während Dusk sagte, dass die Ergebnisse öffentlich sein würden, damit andere sie überprüfen können.
Das beweist jedoch nicht jede operative Annahme für immer. Ich würde trotzdem gern wissen, ob die Produktionsparameter mit dem veröffentlichten Transkript übereinstimmen und wie unabhängig diese Verknüpfung heute in der Praxis geprüft wurde.
Also wird die faire Frage etwas konkreter: Kann ich die Live-kryptografischen Parameter bis auf die öffentlich verifizierbare Zeremonie zurückverfolgen?
Wenn ein Projekt offen eine kryptografische Schwäche in seinem eigenen Paper zugibt, schafft das mehr Vertrauen durch Transparenz — oder macht es dich nur noch mehr dazu, wissen zu wollen, wie real dieses Risiko tatsächlich noch ist?
#dusk $DUSK @Dusk
