#dusk $DUSK @Dusk
Ich habe den Proof-Generierungsprozess lokal laufen lassen, um die Circuit-Performance zu benchmarken, und dabei etwas bemerkt, das mich dazu gebracht hat, statt der Marketing-Seiten die eigenen Write-ups des Krypto-Teams noch einmal zu lesen.
PLONK sind die tatsächlichen Zahlen, die den Compliance-Fall tragen – nicht nur der Privacy-Aspekt. Die Verifikationszeit bleibt bei etwa 6–9 Millisekunden, unabhängig von der Circuit-Größe: Die Proof-Generierungszeit skaliert mit der Komplexität des Circuits (grob 5,46 Sekunden für einen 2^16-Gate-Circuit auf bescheidener Hardware), aber die Verifier-Seite bleibt schnell und konstant. Diese Asymmetrie ist für regulierte Finanzen viel entscheidender, als viele ihr zutrauen: Ein Auditor oder ein Geschäftspartner, der einen Proof prüft, verbrennt nicht jedes Mal bedeutende Rechenleistung – selbst wenn sich die zugrunde liegende Transaktionslogik weiter verkompliziert.
Was ich allerdings nicht erwartet hatte, war, dass PLONK selbst eine tatsächlich offengelegte Schwachstelle hatte, nicht nur ein theoretisches Risiko. Das Forschungsteam von Dusk fand ein kritisches Problem in der Umsetzung der Fiat-Shamir-Transformation – dem Baustein, der aus einem interaktiven Proof einen nicht-interaktiven macht, indem Herausforderungen gehasht werden, statt dass ein Live-Verifier sie sendet. In der ursprünglichen Implementierung wurden die öffentlichen Inputs nicht früh genug gehasht, wodurch die Soundness-Garantie geschwächt wurde. Trail of Bits koordinierte die Offenlegung, Dusk patchte sie noch vor dem Mainnet und machte den Fix öffentlich, statt ihn einfach liegen zu lassen.
Mit genau dieser Detailtiefe gehe ich gedanklich immer wieder mit: Eine compliance-fokussierte Chain, die auf einem kryptografischen Proof-System basiert, das in produktionsnahen Code tatsächlich einen Soundness-Bug hatte – entdeckt und behoben, bevor es wirklich relevant wurde. Ich weiß nicht, wie viele andere Implementierungen, die PLONK anderswo nutzen, noch verwundbar waren, als das öffentlich wurde, oder wie groß die Zeitspanne zwischen der Offenlegung und dem Patchen der eigenen Forks in anderen Projekten war.
Ich habe den Proof-Generierungsprozess lokal laufen lassen, um die Circuit-Performance zu benchmarken, und dabei etwas bemerkt, das mich dazu gebracht hat, statt der Marketing-Seiten die eigenen Write-ups des Krypto-Teams noch einmal zu lesen.
PLONK sind die tatsächlichen Zahlen, die den Compliance-Fall tragen – nicht nur der Privacy-Aspekt. Die Verifikationszeit bleibt bei etwa 6–9 Millisekunden, unabhängig von der Circuit-Größe: Die Proof-Generierungszeit skaliert mit der Komplexität des Circuits (grob 5,46 Sekunden für einen 2^16-Gate-Circuit auf bescheidener Hardware), aber die Verifier-Seite bleibt schnell und konstant. Diese Asymmetrie ist für regulierte Finanzen viel entscheidender, als viele ihr zutrauen: Ein Auditor oder ein Geschäftspartner, der einen Proof prüft, verbrennt nicht jedes Mal bedeutende Rechenleistung – selbst wenn sich die zugrunde liegende Transaktionslogik weiter verkompliziert.
Was ich allerdings nicht erwartet hatte, war, dass PLONK selbst eine tatsächlich offengelegte Schwachstelle hatte, nicht nur ein theoretisches Risiko. Das Forschungsteam von Dusk fand ein kritisches Problem in der Umsetzung der Fiat-Shamir-Transformation – dem Baustein, der aus einem interaktiven Proof einen nicht-interaktiven macht, indem Herausforderungen gehasht werden, statt dass ein Live-Verifier sie sendet. In der ursprünglichen Implementierung wurden die öffentlichen Inputs nicht früh genug gehasht, wodurch die Soundness-Garantie geschwächt wurde. Trail of Bits koordinierte die Offenlegung, Dusk patchte sie noch vor dem Mainnet und machte den Fix öffentlich, statt ihn einfach liegen zu lassen.
Mit genau dieser Detailtiefe gehe ich gedanklich immer wieder mit: Eine compliance-fokussierte Chain, die auf einem kryptografischen Proof-System basiert, das in produktionsnahen Code tatsächlich einen Soundness-Bug hatte – entdeckt und behoben, bevor es wirklich relevant wurde. Ich weiß nicht, wie viele andere Implementierungen, die PLONK anderswo nutzen, noch verwundbar waren, als das öffentlich wurde, oder wie groß die Zeitspanne zwischen der Offenlegung und dem Patchen der eigenen Forks in anderen Projekten war.