Plus je scrute Dusk, moins je trouve que son idée est intéressante—simplement des « couches d’exécution multiples ».
Ce qui ressort le plus, c’est ce que Dusk choisit de garder en dessous.
DuskEVM peut offrir aux développeurs l’environnement qu’ils comprennent déjà. DuskVM peut gérer des applications qui ont besoin d’un accès plus direct au L1 et à ses capacités natives. Mais aucune des deux ne devient l’autorité finale. Ce rôle revient à DuskDS, qui gère le consensus, la disponibilité des données et le règlement.
Je pense que ce choix de conception compte davantage qu’il n’y paraît au premier abord.
Cela signifie que Dusk peut modifier la manière dont les applications s’exécutent sans devoir changer la couche chargée de décider ce qui est finalement considéré comme réglé.
On peut d’ailleurs observer cette relation à travers le pont. Déplacer DUSK dans DuskEVM puis le ramener n’est pas seulement un transfert de jeton entre deux interfaces. Les dépôts et retraits passent par des étapes distinctes de confirmation, de preuve et de finalisation avant que l’actif ne soit considéré comme réglé de l’autre côté.
Et il y a une leçon que je trouve facile à manquer.
L’incident du pont plus tôt cette année a montré qu’un protocole de base fonctionnel ne rend pas automatiquement toutes les couches qui l’entourent tout aussi sûres. Le pont peut devenir une partie de la véritable frontière de sécurité de l’actif.
Donc mon point de vue actuel sur Dusk tient moins à l’idée de « blockchain de confidentialité » qu’à cette question :
Peut-on conserver un règlement stable tout en laissant l’environnement d’exécution évoluer autour ?
#dusk $DUSK @Dusk
Ce qui ressort le plus, c’est ce que Dusk choisit de garder en dessous.
DuskEVM peut offrir aux développeurs l’environnement qu’ils comprennent déjà. DuskVM peut gérer des applications qui ont besoin d’un accès plus direct au L1 et à ses capacités natives. Mais aucune des deux ne devient l’autorité finale. Ce rôle revient à DuskDS, qui gère le consensus, la disponibilité des données et le règlement.
Je pense que ce choix de conception compte davantage qu’il n’y paraît au premier abord.
Cela signifie que Dusk peut modifier la manière dont les applications s’exécutent sans devoir changer la couche chargée de décider ce qui est finalement considéré comme réglé.
On peut d’ailleurs observer cette relation à travers le pont. Déplacer DUSK dans DuskEVM puis le ramener n’est pas seulement un transfert de jeton entre deux interfaces. Les dépôts et retraits passent par des étapes distinctes de confirmation, de preuve et de finalisation avant que l’actif ne soit considéré comme réglé de l’autre côté.
Et il y a une leçon que je trouve facile à manquer.
L’incident du pont plus tôt cette année a montré qu’un protocole de base fonctionnel ne rend pas automatiquement toutes les couches qui l’entourent tout aussi sûres. Le pont peut devenir une partie de la véritable frontière de sécurité de l’actif.
Donc mon point de vue actuel sur Dusk tient moins à l’idée de « blockchain de confidentialité » qu’à cette question :
Peut-on conserver un règlement stable tout en laissant l’environnement d’exécution évoluer autour ?
#dusk $DUSK @Dusk