Ich habe heute Morgen Dusk’ Ausführungs-Pipeline aufgebrochen – und erkannt, dass die meisten Ketten im Grunde nur Datenschutz auf eine EVM-Grundlage „aufpflastern“, die für Transparenz gebaut wurde. Dusk hat den Stack vom Schaltkreis aufwärts neu aufgebaut.
DuskVM führt WASM-Bytecode aus, nicht EVM. Contracts werden zu WASM kompiliert und laufen durch einen 64-KB-Argumentpuffer. Ausführungsergebnisse müssen auf jedem Knoten identisch sein, sonst schlägt die Konsensvalidierung fehl. Das ist deterministische Ausführung, die auf Protokollebene erzwungen wird – nicht einfach vorausgesetzt.
Die Settlement-Pipeline führt zwei native Transaktionsmodelle parallel aus – Moonlight für öffentliche, kontobasierte Transfers, Phoenix für geschützte, UTXO-artige Transfers mit ZK-Beweisen. Beide werden über den Transfer Contract auf derselben Kette abgesetzt, der beide Payload-Typen akzeptiert, sie an die Verifikationslogik weiterleitet und doppelte Ausgaben verhindert. Zustandskoordination auf Protokollebene, nicht ein UI-Toggle.
Kryptografie-Stack: BLS12-381 für aggregierte Signaturen und BLS-Threshold, JubJub für effiziente ZK-Schaltkreise, Poseidon für schaltkreisoptimiertes Hashing, PLONK für wiederverwendbare, on-chain-validierbare Beweise. Alles in reinem Rust. Succinct Attestation wird in drei deterministischen Runden finalisiert – Vorschlag, Validierung, Ratifizierung – mit zufällig ausgewählten Provisionsgebern. Keine Reorgs. Keine probabilistische Finalität. Durchschnittliche Blockzeit: ~2 Sekunden.
Was nicht adressiert wird: Ob die WASM-Ausführungs-Pipeline mit integrierter ZK-Privacy auch bei institutionellen Handelsvolumina den Durchsatz hält oder ob der Schaltkreis-Overhead zur nächsten Engstelle wird.
Womit ich dastehe: Dusk hat keine Kette gesplittet. Es hat eine Ausführungsumgebung gebaut, in der Datenschutz, Compliance und Settlement dieselbe Ingenieursaufgabe sind – gelöst auf Schaltkreisebene, bevor jemals die erste Transaktion finalisiert wurde.
@Dusk #DUSK
#dusk $DUSK $WAL $ACE
DuskVM führt WASM-Bytecode aus, nicht EVM. Contracts werden zu WASM kompiliert und laufen durch einen 64-KB-Argumentpuffer. Ausführungsergebnisse müssen auf jedem Knoten identisch sein, sonst schlägt die Konsensvalidierung fehl. Das ist deterministische Ausführung, die auf Protokollebene erzwungen wird – nicht einfach vorausgesetzt.
Die Settlement-Pipeline führt zwei native Transaktionsmodelle parallel aus – Moonlight für öffentliche, kontobasierte Transfers, Phoenix für geschützte, UTXO-artige Transfers mit ZK-Beweisen. Beide werden über den Transfer Contract auf derselben Kette abgesetzt, der beide Payload-Typen akzeptiert, sie an die Verifikationslogik weiterleitet und doppelte Ausgaben verhindert. Zustandskoordination auf Protokollebene, nicht ein UI-Toggle.
Kryptografie-Stack: BLS12-381 für aggregierte Signaturen und BLS-Threshold, JubJub für effiziente ZK-Schaltkreise, Poseidon für schaltkreisoptimiertes Hashing, PLONK für wiederverwendbare, on-chain-validierbare Beweise. Alles in reinem Rust. Succinct Attestation wird in drei deterministischen Runden finalisiert – Vorschlag, Validierung, Ratifizierung – mit zufällig ausgewählten Provisionsgebern. Keine Reorgs. Keine probabilistische Finalität. Durchschnittliche Blockzeit: ~2 Sekunden.
Was nicht adressiert wird: Ob die WASM-Ausführungs-Pipeline mit integrierter ZK-Privacy auch bei institutionellen Handelsvolumina den Durchsatz hält oder ob der Schaltkreis-Overhead zur nächsten Engstelle wird.
Womit ich dastehe: Dusk hat keine Kette gesplittet. Es hat eine Ausführungsumgebung gebaut, in der Datenschutz, Compliance und Settlement dieselbe Ingenieursaufgabe sind – gelöst auf Schaltkreisebene, bevor jemals die erste Transaktion finalisiert wurde.
@Dusk #DUSK
#dusk $DUSK $WAL $ACE
