La plupart des personnes qui regardent le moteur Piecrust de Dusk vont se concentrer sur ce qu’il peut faire au lancement : smart contracts, WASM, calcul de la confidentialité. Je me retrouve pourtant bloqué sur un détail plus petit : Dusk choisit de rendre dès le premier jour permanents ses codes les plus ennuyeux et les plus critiques, ceux qui gèrent la validation des transactions et le staking, via des contrats Genesis. Pas de correctifs discrets, pas de « on réparera ça dans la v2 ». C’est ça qui mérite qu’on s’y attarde, plus que les schémas d’architecture.
Les contrats principaux immuables ne sont pas vraiment un exploit d’ingénierie : ce sont une décision de confiance. La logique semble être la suivante : si le code le plus important ne peut pas être modifié tranquillement plus tard, alors les utilisateurs n’ont pas à faire confiance aux intentions futures de l’équipe, mais uniquement au code déjà déployé. C’est une forme de vérification différente de celle que proposent la plupart des chaînes. Vous ne faites pas confiance à une feuille de route ou à un vote de gouvernance en ligne de mire : vous faites confiance à quelque chose que vous pouvez inspecter une fois, puis sur lequel vous pouvez compter. Détacher piecrust-uplink comme environnement de test avant que quoi que ce soit ne touche la production s’inscrit dans la même démarche : repousser l’incertitude avant le lancement, afin que le système en direct en porte le moins possible.
Mais la permanence est un compromis, pas un gain gratuit, et c’est le point que beaucoup ont tendance à sauter. Le code qu’on ne peut pas modifier discrètement, on ne peut aussi pas le corriger discrètement. Chaque chaîne ayant livré une logique de base finale a, tôt ou tard, été confrontée à quelque chose que les simulations n’avaient pas couvert : une hypothèse de coûts en gaz qui s’est révélée fausse sous une charge réelle, un paramètre de staking qui paraissait correct sur le papier et qui a été exploité dans la pratique. Donc, la vraie question avec Piecrust n’est pas « sécurité contre flexibilité » en tant que valeurs abstraites. C’est de savoir si Dusk a correctement réglé les contrats Genesis dès la première (et unique) tentative, car il n’y en aura peut-être pas de deuxième.
#dusk @Dusk $DUSK
Les contrats principaux immuables ne sont pas vraiment un exploit d’ingénierie : ce sont une décision de confiance. La logique semble être la suivante : si le code le plus important ne peut pas être modifié tranquillement plus tard, alors les utilisateurs n’ont pas à faire confiance aux intentions futures de l’équipe, mais uniquement au code déjà déployé. C’est une forme de vérification différente de celle que proposent la plupart des chaînes. Vous ne faites pas confiance à une feuille de route ou à un vote de gouvernance en ligne de mire : vous faites confiance à quelque chose que vous pouvez inspecter une fois, puis sur lequel vous pouvez compter. Détacher piecrust-uplink comme environnement de test avant que quoi que ce soit ne touche la production s’inscrit dans la même démarche : repousser l’incertitude avant le lancement, afin que le système en direct en porte le moins possible.
Mais la permanence est un compromis, pas un gain gratuit, et c’est le point que beaucoup ont tendance à sauter. Le code qu’on ne peut pas modifier discrètement, on ne peut aussi pas le corriger discrètement. Chaque chaîne ayant livré une logique de base finale a, tôt ou tard, été confrontée à quelque chose que les simulations n’avaient pas couvert : une hypothèse de coûts en gaz qui s’est révélée fausse sous une charge réelle, un paramètre de staking qui paraissait correct sur le papier et qui a été exploité dans la pratique. Donc, la vraie question avec Piecrust n’est pas « sécurité contre flexibilité » en tant que valeurs abstraites. C’est de savoir si Dusk a correctement réglé les contrats Genesis dès la première (et unique) tentative, car il n’y en aura peut-être pas de deuxième.
#dusk @Dusk $DUSK