In DuskEVMs eigenen Doks steckt ein Detail, das meine Denkweise über die Frage „Welche Schicht ist wofür gebaut?“ verändert: DuskEVM läuft derzeit ohne öffentliches Mempool — nur der Sequencer.
Das ist eine echte Architekturentscheidung, kein Rundungsfehler. Auf den meisten EVM-Ketten liegen ausstehende Transaktionen in einem sichtbaren Mempool, bevor sie aufgenommen werden — genau diese Angriffsfläche nutzen MEV-Bots und Frontrunner. DuskEVM überspringt das komplett: Es führt über einen einzelnen Sequencer aus und postet anschließend Batch-Daten zurück an DuskDS zur Abrechnung und Verfügbarkeit. DuskVM hingegen führt Dusk-nativen Rust/WASM-Verträgen direkt gegen die Phoenix/Moonlight-Transaktionsmodelle aus — kein EVM-Tooling, aber Privatsphäre ist hier von Haus aus integriert, nicht nachträglich angeflanscht.
Was mich tiefer gezogen hat: der Brücken-Vorfall vom 16. August. Eine teamverwaltete Wallet, die für Bridge-Operationen genutzt wurde, wurde als verdächtig markiert, Adressen wurden deaktiviert, und Bridge-Services pausiert — dieselbe Bridge, die DUSK zwischen DuskDS und DuskEVM für Gas bewegt. Das ist eine Erinnerung daran, dass die verbindende Schicht zwischen diesen beiden VMs weiterhin eine operative Abhängigkeit ist, nicht ein vollständig protokollzwischendurch erzwungener Übergabemechanismus.
Was ich nicht bestätigen kann: die tatsächlichen DuskEVM-Testnet-Transaktionszahlen oder das Vertrags-Deployment-Volumen diese Woche — Blockscout-Statistiken wurden nicht zurückgegeben, ohne eine per JS gerenderte Session, also gehe ich von dokumentierter Architektur aus, nicht von aktuellem Durchsatz.
Welche Schicht wählen Builder gerade tatsächlich, und warum?
@Dusk_Foundation $DUSK #dusk
Das ist eine echte Architekturentscheidung, kein Rundungsfehler. Auf den meisten EVM-Ketten liegen ausstehende Transaktionen in einem sichtbaren Mempool, bevor sie aufgenommen werden — genau diese Angriffsfläche nutzen MEV-Bots und Frontrunner. DuskEVM überspringt das komplett: Es führt über einen einzelnen Sequencer aus und postet anschließend Batch-Daten zurück an DuskDS zur Abrechnung und Verfügbarkeit. DuskVM hingegen führt Dusk-nativen Rust/WASM-Verträgen direkt gegen die Phoenix/Moonlight-Transaktionsmodelle aus — kein EVM-Tooling, aber Privatsphäre ist hier von Haus aus integriert, nicht nachträglich angeflanscht.
Was mich tiefer gezogen hat: der Brücken-Vorfall vom 16. August. Eine teamverwaltete Wallet, die für Bridge-Operationen genutzt wurde, wurde als verdächtig markiert, Adressen wurden deaktiviert, und Bridge-Services pausiert — dieselbe Bridge, die DUSK zwischen DuskDS und DuskEVM für Gas bewegt. Das ist eine Erinnerung daran, dass die verbindende Schicht zwischen diesen beiden VMs weiterhin eine operative Abhängigkeit ist, nicht ein vollständig protokollzwischendurch erzwungener Übergabemechanismus.
Was ich nicht bestätigen kann: die tatsächlichen DuskEVM-Testnet-Transaktionszahlen oder das Vertrags-Deployment-Volumen diese Woche — Blockscout-Statistiken wurden nicht zurückgegeben, ohne eine per JS gerenderte Session, also gehe ich von dokumentierter Architektur aus, nicht von aktuellem Durchsatz.
Welche Schicht wählen Builder gerade tatsächlich, und warum?
@Dusk_Foundation $DUSK #dusk