Au départ, je voyais Dusk surtout comme une couche 1 axée sur la confidentialité. Mais en regardant plus en profondeur l’architecture, j’ai changé d’avis. Le réseau ne repose pas sur un seul environnement pour tout faire. Au lieu de cela, DuskDS gère le consensus, la finalité et la disponibilité des données, tandis que Dusk fournit différents environnements d’exécution selon les besoins.
La partie que je trouve la plus intéressante, c’est DuskEVM.
Il est conçu comme un environnement d’exécution compatible avec l’EVM qui s’appuie sur DuskDS pour s’achever. Cela signifie que les développeurs peuvent travailler avec les outils Ethereum familiers, tandis que la couche de règlement sous-jacente de Dusk gère les fondations.
Au début, je me demandais pourquoi cette séparation était nécessaire. Ne serait-il pas plus simple d’avoir un seul environnement d’exécution ?
Plus j’y réfléchis, plus cela me paraît logique dans le contexte de la finance réglementée. Les différentes applications peuvent avoir des exigences différentes. Certaines peuvent avoir besoin d’un développement EVM familier, tandis que d’autres peuvent nécessiter un accès direct aux actifs natifs de Dusk, à ses fonctionnalités de confidentialité ou à ses capacités de preuve à connaissance nulle.
Cela donne à l’architecture une impression moins de “forcer” chaque cas d’usage dans un seul système, et davantage de confier à chaque partie un rôle spécifique.
Mais il y a encore quelque chose que je veux mieux comprendre.
À mesure que l’écosystème grandit, quelle complexité cette approche modulaire introduit-elle ? Des couches distinctes peuvent offrir de la flexibilité, mais cela signifie aussi que les connexions entre ces couches deviennent extrêmement importantes.
Pour moi, la question intéressante avec Dusk, c’est actuellement celle-ci : la modularité peut-elle rendre l’infrastructure blockchain réglementée plus pratique, sans la rendre plus difficile à comprendre et à utiliser ?
C’est quelque chose que je suivrai de près.
@Dusk_Foundation _Foundation $DUSK #DUSK
La partie que je trouve la plus intéressante, c’est DuskEVM.
Il est conçu comme un environnement d’exécution compatible avec l’EVM qui s’appuie sur DuskDS pour s’achever. Cela signifie que les développeurs peuvent travailler avec les outils Ethereum familiers, tandis que la couche de règlement sous-jacente de Dusk gère les fondations.
Au début, je me demandais pourquoi cette séparation était nécessaire. Ne serait-il pas plus simple d’avoir un seul environnement d’exécution ?
Plus j’y réfléchis, plus cela me paraît logique dans le contexte de la finance réglementée. Les différentes applications peuvent avoir des exigences différentes. Certaines peuvent avoir besoin d’un développement EVM familier, tandis que d’autres peuvent nécessiter un accès direct aux actifs natifs de Dusk, à ses fonctionnalités de confidentialité ou à ses capacités de preuve à connaissance nulle.
Cela donne à l’architecture une impression moins de “forcer” chaque cas d’usage dans un seul système, et davantage de confier à chaque partie un rôle spécifique.
Mais il y a encore quelque chose que je veux mieux comprendre.
À mesure que l’écosystème grandit, quelle complexité cette approche modulaire introduit-elle ? Des couches distinctes peuvent offrir de la flexibilité, mais cela signifie aussi que les connexions entre ces couches deviennent extrêmement importantes.
Pour moi, la question intéressante avec Dusk, c’est actuellement celle-ci : la modularité peut-elle rendre l’infrastructure blockchain réglementée plus pratique, sans la rendre plus difficile à comprendre et à utiliser ?
C’est quelque chose que je suivrai de près.
@Dusk_Foundation _Foundation $DUSK #DUSK