Ich möchte heute tiefer in Zero-Knowledge-Beweise eintauchen, weil frühere Beiträge die Idee nur skizziert haben.

Eine einfache Analogie: nachweisen, dass man über 18 ist, ohne das genaue Geburtsdatum offenzulegen. Man versteckt nicht, ob die Behauptung stimmt — man gibt einfach nicht mehr preis, als nötig ist, um sie zu belegen. Zero-Knowledge-Beweise ermöglichen es einem Computer, das Äquivalent mit Mathematik statt mit einer Ausweiskarte zu tun.

Technisch gesehen @Dusk basiert auf PLONK, einem Beweissystem, bei dem es seit seinen frühen Testnet-Tagen geholfen hat, es zu entwickeln, und das über die BLS12-381-Kurve läuft. PLONK ist das, was es dem Netzwerk erlaubt, zu bestätigen, dass eine Transaktion oder ein Vertrag die Regeln befolgt, ohne jemals die privaten Eingaben hinter dieser Behauptung zu sehen.

Aber es gibt einen Haken — und der ist recht neu und es lohnt sich, offen damit umzugehen. Im April deckten Sicherheitsforscher bei OtterSec eine Soundness-Schwäche in der PLONK-Implementierung von #dusk auf: Der Verifier prüfte nicht vier der Polynomial-Commitments des Provers. Eine Lücke, die theoretisch es jemandem erlaubt hätte, einen Beweis für eine geschützte Transaktion zu fälschen. Das Team von Dusk hat das behoben, indem es diese fehlenden Checks in den Verifikationsschritt ergänzt hat.

Ich erwähne das nicht, um irgendwen zu beunruhigen, sondern weil es eine nützliche Erinnerung ist: Die Kryptografie kann korrekt und stimmig sein, während der Code, der sie implementiert, trotzdem Bugs haben kann. Auch die Verifikation des Verifiers ist entscheidend.
$DUSK $HEMI $TUT