Je relis encore une fois l’architecture de Dusk et je reste bloqué sur la raison pour laquelle le règlement est traité comme un travail distinct de l’exécution.

DuskDS est la couche de règlement et de disponibilité des données du L1. Elle gère le consensus et la finalité, tandis que DuskVM exécute directement les contrats Rust/WASM sur le L1. DuskEVM prend l’autre voie : il offre les outils Solidity et EVM tout en utilisant DuskDS pour le règlement et la disponibilité des données.

Cette séparation a davantage de sens quand j’arrête de considérer l’exécution comme étant toute la transaction.

Un contrat peut calculer ce qui doit se produire. Quelqu’un doit encore établir que l’état résultant fait désormais partie de la chaîne partagée et qu’il a atteint la finalité. Dusk maintient ces responsabilités distinctes sans pour autant en faire des systèmes indépendants qui flottent chacun de leur côté.

Cela semble particulièrement pertinent pour l’infrastructure financière. Une application peut avoir besoin d’une exécution EVM familière, mais la couche de règlement sous-jacente doit quand même fournir le consensus et la finalité sur lesquels le flux de travail s’appuie. DuskEVM peut changer l’environnement d’exécution sans changer d’où vient ce règlement.

Il y a toutefois une partie avec laquelle je ne suis pas encore tout à fait à l’aise. La séparation sonne propre sur le plan architectural, mais le chemin d’exécution et DuskDS doivent quand même évoluer comme un seul système. Plus de modularité ne signifie pas moins de coordination.

Et je ne dispose pas encore de suffisamment de données publiques de benchmark pour dire où la contrainte pratique apparaît en premier sous une charge soutenue.

Je voudrais mesurer une chose avant d’avancer des affirmations plus grandes : lorsque l’exécution de DuskEVM est fortement sollicitée, comment cette charge de travail affecte-t-elle réellement la latence de règlement et de finalité sur DuskDS ?

#dusk $DUSK @Dusk $PORTAL $GPS