Etwas in den Dokumenten hat mich heute mitten im Scrollen aufgehalten.
Dusk Network, $DUSK , #dusk , @Dusk — der EVM-Kompatibilitätsaspekt ist es, über den die meisten Menschen dieses Projekt finden. Portiere deine Solidity-Verträge, nutze vertraute Tools und bestehende EVM-Wallets. Das duskevm-genesis-Repo auf GitHub wurde zuletzt am 8. August aktualisiert und zeigt aktive Arbeiten an der Rollup-Konfiguration. Die Maschinerie läuft also. Aber das tiefere Detail, das ich nicht loswerden konnte, steckt direkt in den Architektur-Dokumenten selbst, verborgen unter einer einzigen Zeile: „Transaktionsinclusion ist schnell, aber Inclusion und Settlement sind unterschiedliche Phasen.“
Das ist der Hinweis. DuskEVM läuft auf OP Stack — im Wesentlichen op-geth als Sequencer, der Transaktionsdaten bündelt und sie als Blobs an DuskDS zurückspielt. Standardmäßiges Rollup-Verhalten. Aber DuskDS, der eigentliche Zweckbau darunter — deterministisches Settlement, ZK-Smart-Contracts, native Privacy — ist eine völlig separate Ausführungsumgebung. Die Doku ist da eindeutig: Baue auf DuskEVM für Solidity und vertraute Tooling-Setups, oder baue nativ auf DuskDS mit Rust und WASM für echte Privacy auf Protokoll-Ebene und benutzerdefinierte Marktlogik. Zwei Wege. Nicht eine einheitliche Sache.
hmm… Ich habe eine Weile zu lange angenommen, dass hier mit EVM-Kompatibilität gemeint sei, dass Solidity-Code automatisch Dusk’ finanzielle Infrastruktur „mitbekommt“. Das tut er nicht. Die Verbindung zwischen diesen beiden Ebenen ist bewusst und optional, nicht automatisch.
Das lässt mich fragen — wie viele Entwickler, die zu DuskEVM portieren, gehen tatsächlich wieder zurück und re-architektieren für DuskDS, sobald sie merken, was ihnen entgangen ist?
Dusk Network, $DUSK , #dusk , @Dusk — der EVM-Kompatibilitätsaspekt ist es, über den die meisten Menschen dieses Projekt finden. Portiere deine Solidity-Verträge, nutze vertraute Tools und bestehende EVM-Wallets. Das duskevm-genesis-Repo auf GitHub wurde zuletzt am 8. August aktualisiert und zeigt aktive Arbeiten an der Rollup-Konfiguration. Die Maschinerie läuft also. Aber das tiefere Detail, das ich nicht loswerden konnte, steckt direkt in den Architektur-Dokumenten selbst, verborgen unter einer einzigen Zeile: „Transaktionsinclusion ist schnell, aber Inclusion und Settlement sind unterschiedliche Phasen.“
Das ist der Hinweis. DuskEVM läuft auf OP Stack — im Wesentlichen op-geth als Sequencer, der Transaktionsdaten bündelt und sie als Blobs an DuskDS zurückspielt. Standardmäßiges Rollup-Verhalten. Aber DuskDS, der eigentliche Zweckbau darunter — deterministisches Settlement, ZK-Smart-Contracts, native Privacy — ist eine völlig separate Ausführungsumgebung. Die Doku ist da eindeutig: Baue auf DuskEVM für Solidity und vertraute Tooling-Setups, oder baue nativ auf DuskDS mit Rust und WASM für echte Privacy auf Protokoll-Ebene und benutzerdefinierte Marktlogik. Zwei Wege. Nicht eine einheitliche Sache.
hmm… Ich habe eine Weile zu lange angenommen, dass hier mit EVM-Kompatibilität gemeint sei, dass Solidity-Code automatisch Dusk’ finanzielle Infrastruktur „mitbekommt“. Das tut er nicht. Die Verbindung zwischen diesen beiden Ebenen ist bewusst und optional, nicht automatisch.
Das lässt mich fragen — wie viele Entwickler, die zu DuskEVM portieren, gehen tatsächlich wieder zurück und re-architektieren für DuskDS, sobald sie merken, was ihnen entgangen ist?
