$DUSK #dusk — DuskEVM zeigt eine Bestätigung, bevor Dusk tatsächlich irgendetwas erledigt hat. In den eigenen Entwicklerdokumenten von @Dusk heißt es ganz eindeutig: Die Aufnahme von Transaktionen geht schnell, aber Aufnahme und Settlement sind unterschiedliche Phasen. Apps, die Werte zwischen DuskEVM und der L1 übertragen, sollen den Protokoll- oder Wallet-Status prüfen – nicht die verstrichene Zeit –, um zu wissen, was final ist. Der Sequencer führt sofort aus, der Batcher postet die Daten an DuskDS als Blobs, der Proposer postet anschließend ein State-Commitment. Drei Akteure, drei Momente — du siehst immer nur den ersten.
Zur Einordnung habe ich bei GitHub nachgesehen: dusk-network/duskevm-genesis, das Repo mit dem eigentlichen Genesis-Block und der Rollup-Konfiguration von DuskEVM, wurde zuletzt am 8. August aktualisiert. Zwei Tage später beschrieb ein datiertes Update vom 10. August DuskEVM noch immer als Testnet — Deploy-and-Test mit Hardhat und Solidity — obwohl es anderswo bereits Januar-Posts gab, die es als „mainnet launch“ bezeichneten. Dass die Genesis-Konfiguration noch im August angepasst wurde, passt eher zu einer Testnet-Phase als zu einer Mainnet-Phase.
Die doppelte Gebühr (L2-Ausführung plus eine separate DuskDS Data-Availability-Fees) macht die Staging-Phase greifbar — du zahlst zwei Ebenen für eine sequentielle Arbeit, nicht nur eine. Genau diese Schichtung benennen sowohl das Genesis-Repo als auch die Doku: Settlement ist ein eigenständiges, späteres Ereignis — auf Code-Ebene wie auch auf Ankündigungs-Ebene.
Was sich für mich geändert hat: DuskEVM vs DuskVM ist keine Sprachentscheidung, Solidity vs. Rust. Es geht darum, an welcher Finalitätsphase eine Anwendung tatsächlich gebaut ist. DuskVMs Ausführung und Settlement sind dasselbe Ereignis. DuskEVMs nicht. Wer jetzt DuskEVM integriert — liest deine App Settlement-Status, oder wartest du nur auf Aufnahme?
Als Nächstes: duskevm-genesis nach dem ersten Commit durchsuchen, der nicht mehr an der Rollup-Konfiguration herumfasst — das ist ein klareres Signal für Mainnet-Readiness als jede Ankündigung.
#dusk $DUSK @Dusk
Zur Einordnung habe ich bei GitHub nachgesehen: dusk-network/duskevm-genesis, das Repo mit dem eigentlichen Genesis-Block und der Rollup-Konfiguration von DuskEVM, wurde zuletzt am 8. August aktualisiert. Zwei Tage später beschrieb ein datiertes Update vom 10. August DuskEVM noch immer als Testnet — Deploy-and-Test mit Hardhat und Solidity — obwohl es anderswo bereits Januar-Posts gab, die es als „mainnet launch“ bezeichneten. Dass die Genesis-Konfiguration noch im August angepasst wurde, passt eher zu einer Testnet-Phase als zu einer Mainnet-Phase.
Die doppelte Gebühr (L2-Ausführung plus eine separate DuskDS Data-Availability-Fees) macht die Staging-Phase greifbar — du zahlst zwei Ebenen für eine sequentielle Arbeit, nicht nur eine. Genau diese Schichtung benennen sowohl das Genesis-Repo als auch die Doku: Settlement ist ein eigenständiges, späteres Ereignis — auf Code-Ebene wie auch auf Ankündigungs-Ebene.
Was sich für mich geändert hat: DuskEVM vs DuskVM ist keine Sprachentscheidung, Solidity vs. Rust. Es geht darum, an welcher Finalitätsphase eine Anwendung tatsächlich gebaut ist. DuskVMs Ausführung und Settlement sind dasselbe Ereignis. DuskEVMs nicht. Wer jetzt DuskEVM integriert — liest deine App Settlement-Status, oder wartest du nur auf Aufnahme?
Als Nächstes: duskevm-genesis nach dem ersten Commit durchsuchen, der nicht mehr an der Rollup-Konfiguration herumfasst — das ist ein klareres Signal für Mainnet-Readiness als jede Ankündigung.
#dusk $DUSK @Dusk