Enfoui dans les propres docs de DuskEVM, un détail change la façon dont je pense à la question « quelle couche est conçue pour quoi » : actuellement, DuskEVM fonctionne sans mempool public — seul le séquenceur.
C’est un vrai choix d’architecture, pas une simple approximation. Sur la plupart des chaînes EVM, les transactions en attente restent dans un mempool visible avant d’être incluses : c’est exactement la surface que les bots MEV et les frontrunners exploitent. DuskEVM contourne cela entièrement : exécution via un unique séquenceur, puis publication des données de lots vers DuskDS pour le règlement et la disponibilité. DuskVM, à l’inverse, exécute directement les contrats natifs Rust/WASM de Dusk contre des modèles de transaction Phoenix/Moonlight — pas d’outillage EVM, mais la confidentialité est intrinsèque plutôt qu’ajoutée.
Ce qui m’a entraîné plus loin : l’incident de pont du 16 août. Un portefeuille géré par l’équipe, utilisé pour les opérations de pont, a été signalé ; des adresses ont été désactivées et les services de pont ont été mis en pause — le même pont qui transfère DUSK entre DuskDS et DuskEVM pour le gaz. Un rappel que la couche connectrice entre ces deux machines virtuelles reste une dépendance opérationnelle, et non une transition entièrement imposée par le protocole.
Ce que je ne peux pas confirmer : les volumes réels de transactions sur le testnet DuskEVM cette semaine, ni le volume de déploiement de contrats — les statistiques de Blockscout ne sont pas revenues sans une session rendue en JS ; je m’appuie donc sur l’architecture documentée, pas sur le débit en direct.
Quelle couche les builders choisissent-ils réellement en ce moment, et pourquoi ?

@Dusk_Foundation $DUSK #dusk