In letzter Zeit wurden viele Leute von den @Dusk beworbenen 2,8-Millisekunden-On-Chain-Verifizierungen reingelegt. Auf den ersten Blick wirkt die ganze Kette unglaublich schnell – in Wahrheit ist das ein sehr typischer Blickfallen-Trick. Alle starren auf den vorderen Bereich, der glasklar wirkt; tatsächlich drehen im Hintergrund die Serverlüfter schon so stark, dass sie fast durchbrennen.
Der PLONK-Algorithmus bringt die On-Chain-Verification tatsächlich bis an die Grenze, und die Proof-Größe lässt sich auch festhalten. Aber wenn du nur auf die paar armen Bytes schaust, die ein Blockchain-Explorer anzeigt, wirkt das Ganze schnell wie eine Feder.
Ich hatte vor ein paar Tagen Lust, das Projekt mit meinem M1-Computer kurz selbst zu testen – die Feder, die du umdrehst, ist am Ende ein echter Eisenklotz. Nehmen wir zum Beispiel das Citadel-Identity-Circuit bei $DUSK : Wenn man nur eine einzige License laufen lässt, braucht man 34.861 Constraints. Auf dem lokalen Rechner hat der Prover das mit viel Mühe 16,232 Sekunden gekaut, bis es fertig war; beim Verifier dauert es dagegen nur 0,007 Sekunden. Diese 16 Sekunden bei einer Spanne von 7 Millisekunden zeigen: Je „glatter“ sich die On-Chain-Erfahrung anfühlt, desto schwerer wird die Last, die Off-Chain getragen werden muss. Wer schon mal an Low-Level-Entwicklung gearbeitet hat, weiß: Der Rechenaufwand-Overhead von ZK-Proofs liegt ungefähr genau bei dem Zehntausendfachen der ursprünglichen Rechenoperationen. Diese angebliche Effizienz verlagert den gesamten Rechenstress einfach auf lokale Geräte.$BTC
Viele glauben, dass „On-Chain-effizient“, wie es offiziell gesagt wird, bedeutet, dass das Gesamtsystem leichtgewichtig ist. Doch in Wahrheit steigt die Proving-Last mit der Größe des Schaltkreises drastisch an – und damit werden die Zugangshürden für Nodes künstlich höher geschoben. Das ist ein ziemlich brutales Spiel zur Ressourcen-Auslese.
Noch entscheidender ist die Geschichte mit Privacy-Compliance, die man mit beiden Händen gleichzeitig schaffen will. DUSK macht mit ZK KYC und nutzt selektive Offenlegung – aber das hat einen logischen Knoten: On-Chain braucht es außerhalb der Kette eine Instanz, die von der Aufsicht anerkannt ist, um das Siegel bzw. die Stempelung rechtlich zu bekräftigen. Compliance-Geschäft an einen Dritten auszulagern, steht im Grunde im Widerspruch zur Idee der Dezentralität bzw. Trustlessness.$ETH
Und vergiss nicht den Aufreger am Anfang des Jahres: Es wurde aufgedeckt, dass PLONK eine Schwachstelle in der Soundness besitzt. Ein böswilliger Prover kann die „selector evaluation“ fälschen und den Verifier reihenweise durcheinanderbringen. Dass On-Chain so schnell läuft, heißt nicht automatisch, dass es absolut sicher ist.
Mein Fazit:#dusk bekommt tatsächlich den Verification-Vorteil ab – aber mit klaren doppelten Kosten: Die Rechenkosten werden Off-Chain auf den Prover abgewälzt, und die Compliance-Kosten landen außerhalb der Kette bei den Identitäts-Infrastrukturen. Anstatt nur zu schauen, wie klein die On-Chain-Daten sind, stellt lieber diese Fragen: Wie viele Nodes sind bereit, 16 Sekunden Proving-Zeit hart zu stemmen? Wie viele Aufsichtsbehörden sind bereit, Citadel offiziell zu unterstützen? Genau das ist der Kern, um die echten Kosten zu bewerten.
Der PLONK-Algorithmus bringt die On-Chain-Verification tatsächlich bis an die Grenze, und die Proof-Größe lässt sich auch festhalten. Aber wenn du nur auf die paar armen Bytes schaust, die ein Blockchain-Explorer anzeigt, wirkt das Ganze schnell wie eine Feder.
Ich hatte vor ein paar Tagen Lust, das Projekt mit meinem M1-Computer kurz selbst zu testen – die Feder, die du umdrehst, ist am Ende ein echter Eisenklotz. Nehmen wir zum Beispiel das Citadel-Identity-Circuit bei $DUSK : Wenn man nur eine einzige License laufen lässt, braucht man 34.861 Constraints. Auf dem lokalen Rechner hat der Prover das mit viel Mühe 16,232 Sekunden gekaut, bis es fertig war; beim Verifier dauert es dagegen nur 0,007 Sekunden. Diese 16 Sekunden bei einer Spanne von 7 Millisekunden zeigen: Je „glatter“ sich die On-Chain-Erfahrung anfühlt, desto schwerer wird die Last, die Off-Chain getragen werden muss. Wer schon mal an Low-Level-Entwicklung gearbeitet hat, weiß: Der Rechenaufwand-Overhead von ZK-Proofs liegt ungefähr genau bei dem Zehntausendfachen der ursprünglichen Rechenoperationen. Diese angebliche Effizienz verlagert den gesamten Rechenstress einfach auf lokale Geräte.$BTC
Viele glauben, dass „On-Chain-effizient“, wie es offiziell gesagt wird, bedeutet, dass das Gesamtsystem leichtgewichtig ist. Doch in Wahrheit steigt die Proving-Last mit der Größe des Schaltkreises drastisch an – und damit werden die Zugangshürden für Nodes künstlich höher geschoben. Das ist ein ziemlich brutales Spiel zur Ressourcen-Auslese.
Noch entscheidender ist die Geschichte mit Privacy-Compliance, die man mit beiden Händen gleichzeitig schaffen will. DUSK macht mit ZK KYC und nutzt selektive Offenlegung – aber das hat einen logischen Knoten: On-Chain braucht es außerhalb der Kette eine Instanz, die von der Aufsicht anerkannt ist, um das Siegel bzw. die Stempelung rechtlich zu bekräftigen. Compliance-Geschäft an einen Dritten auszulagern, steht im Grunde im Widerspruch zur Idee der Dezentralität bzw. Trustlessness.$ETH
Und vergiss nicht den Aufreger am Anfang des Jahres: Es wurde aufgedeckt, dass PLONK eine Schwachstelle in der Soundness besitzt. Ein böswilliger Prover kann die „selector evaluation“ fälschen und den Verifier reihenweise durcheinanderbringen. Dass On-Chain so schnell läuft, heißt nicht automatisch, dass es absolut sicher ist.
Mein Fazit:#dusk bekommt tatsächlich den Verification-Vorteil ab – aber mit klaren doppelten Kosten: Die Rechenkosten werden Off-Chain auf den Prover abgewälzt, und die Compliance-Kosten landen außerhalb der Kette bei den Identitäts-Infrastrukturen. Anstatt nur zu schauen, wie klein die On-Chain-Daten sind, stellt lieber diese Fragen: Wie viele Nodes sind bereit, 16 Sekunden Proving-Zeit hart zu stemmen? Wie viele Aufsichtsbehörden sind bereit, Citadel offiziell zu unterstützen? Genau das ist der Kern, um die echten Kosten zu bewerten.