Je regardais encore une fois l’architecture modulaire de Dusk et le schéma devient plus clair dès lors qu’on cesse de le considérer comme trois chaînes distinctes.
En réalité, il s’agit de trois fonctions différentes réparties dans l’ensemble de la pile.
1. DuskDS — la couche de base
C’est la fondation.
DuskDS est responsable des fonctions réseau sous-jacentes autour de :
* le consensus
* la disponibilité des données
* le règlement
Ainsi, au lieu de confier toutes les responsabilités d’exécution à la couche de base, DuskDS se concentre sur le fait de maintenir le système sous-jacent coordonné et réglé.
2. DuskEVM — la couche de compatibilité
C’est ici qu’intervient l’exécution EVM.
La partie intéressante ne se limite pas à « Dusk prend en charge l’EVM ».
C’est le fait que l’exécution EVM dispose de sa propre couche au sein de l’architecture modulaire, offrant aux développeurs un environnement plus familier tout en conservant la couche DuskDS sous-jacente séparée.
Cette séparation peut réduire la quantité de travail d’intégration nécessaire lors de la création d’applications.
3. DuskVM — la couche d’exécution orientée confidentialité
Puis il y a DuskVM.
Son rôle est encore différent : une exécution axée sur la confidentialité.
Ainsi, l’architecture ne force pas une exécution de style public de type EVM et une exécution orientée confidentialité dans exactement le même environnement.
Elles sont séparées en leurs propres parcours d’exécution.
Et ensuite, il y a deux éléments qui relient l’ensemble de la conception.
4. Un seul DUSK sur toute la pile
L’architecture conserve un jeton DUSK unique à travers les couches.
C’est important, car l’exécution modulaire ne signifie pas automatiquement une économie fragmentée.
Les environnements d’exécution peuvent être séparés tandis que l’économie du jeton reste unifiée.
5. Un pont natif entre DuskDS et DuskEVM
Les couches ne sont pas non plus censées se comporter comme des îlots isolés.
L’architecture décrit un concept de pont natif entre DuskDS et DuskEVM, offrant à la couche d’exécution un chemin de retour vers le système Dusk sous-jacent.
C’est la partie que je trouve la plus intéressante, plus que le schéma lui-même.
En gros, l’architecture dit :
DuskDS s’occupe de la fondation.
DuskEVM s’occupe de l’exécution EVM.
DuskVM s’occupe de l’exécution orientée confidentialité.$DUSK #dusk @Dusk
En réalité, il s’agit de trois fonctions différentes réparties dans l’ensemble de la pile.
1. DuskDS — la couche de base
C’est la fondation.
DuskDS est responsable des fonctions réseau sous-jacentes autour de :
* le consensus
* la disponibilité des données
* le règlement
Ainsi, au lieu de confier toutes les responsabilités d’exécution à la couche de base, DuskDS se concentre sur le fait de maintenir le système sous-jacent coordonné et réglé.
2. DuskEVM — la couche de compatibilité
C’est ici qu’intervient l’exécution EVM.
La partie intéressante ne se limite pas à « Dusk prend en charge l’EVM ».
C’est le fait que l’exécution EVM dispose de sa propre couche au sein de l’architecture modulaire, offrant aux développeurs un environnement plus familier tout en conservant la couche DuskDS sous-jacente séparée.
Cette séparation peut réduire la quantité de travail d’intégration nécessaire lors de la création d’applications.
3. DuskVM — la couche d’exécution orientée confidentialité
Puis il y a DuskVM.
Son rôle est encore différent : une exécution axée sur la confidentialité.
Ainsi, l’architecture ne force pas une exécution de style public de type EVM et une exécution orientée confidentialité dans exactement le même environnement.
Elles sont séparées en leurs propres parcours d’exécution.
Et ensuite, il y a deux éléments qui relient l’ensemble de la conception.
4. Un seul DUSK sur toute la pile
L’architecture conserve un jeton DUSK unique à travers les couches.
C’est important, car l’exécution modulaire ne signifie pas automatiquement une économie fragmentée.
Les environnements d’exécution peuvent être séparés tandis que l’économie du jeton reste unifiée.
5. Un pont natif entre DuskDS et DuskEVM
Les couches ne sont pas non plus censées se comporter comme des îlots isolés.
L’architecture décrit un concept de pont natif entre DuskDS et DuskEVM, offrant à la couche d’exécution un chemin de retour vers le système Dusk sous-jacent.
C’est la partie que je trouve la plus intéressante, plus que le schéma lui-même.
En gros, l’architecture dit :
DuskDS s’occupe de la fondation.
DuskEVM s’occupe de l’exécution EVM.
DuskVM s’occupe de l’exécution orientée confidentialité.$DUSK #dusk @Dusk