Ces derniers jours, en regardant les mises à jour de l’accord de Dusk, je suis resté bloqué par un changement assez facile à ignorer :
**Boreas commence à exiger que les transactions aient une notion de version.**
Cette phrase sonne très “ingénieur”.
Mais quand je l’ai décomposée, j’ai réalisé qu’elle résout un problème particulièrement concret :
Si une chaîne met à niveau les règles du protocole, une même transaction, vue par des nœuds de versions différentes, peut-elle encore être considérée comme “la même transaction” ?
Boreas introduit désormais un traitement des transactions canonical, version-aware, tout en ajustant la tarification et les règles de déploiement de la VM, et en redéfinissant aussi la sémantique des transitions d’état et des events reverted. Même la documentation officielle indique clairement que ces changements font partie intégrante du cœur d’un hard fork.
Quand je regardais L1, je surveillais surtout le TPS, la finalité et le Gas.
Maintenant, je me dis plutôt que **après une mise à niveau du protocole, peut-on conserver le fait que “tout le monde comprend la même série de règles”** est peut-être encore plus important.
Parce que le véritable problème, ce n’est pas la mise à niveau elle-même.
C’est plutôt :
Comment les nœuds l’interprètent ?
Comment la validation l’interprète ?
Comment on rejoue les transactions historiques ?
Et comment les applications l’interprètent ?
Dès qu’une seule couche n’a pas la même compréhension, la suite ne relève plus de la performance : c’est l’état entier qui finit par être reconnu par “qui”.
Du coup, Boreas m’a fait comprendre pour la première fois de manière assez concrète pourquoi une blockchain mûre passe autant de temps à gérer des règles qui semblent, en apparence, “peu passionnantes”.
Elle n’ajoute pas un nouveau fonctionnalité aux utilisateurs.
Elle trace des limites à l’avance pour les développeurs, les nœuds et les applications de demain.
Avant, j’aurais pensé qu’une mise à jour comme celle-ci est difficile à transformer en contenu, parce qu’il n’y a pas de jolis chiffres, pas de nouveau produit.
Mais maintenant, au contraire, je trouve que c’est justement là qu’on voit le mieux la maturité d’ingénierie d’une chaîne.
**Un protocole vraiment fiable ne se contente pas de gérer les transactions d’aujourd’hui : il doit aussi garantir qu’après la mise à niveau de demain, les transactions d’hier ne se verront pas soudain attribuer une autre interprétation.**
C’est peut-être ça, en fait, l’intérêt principal de Boreas.
#dusk $DUSK @Dusk
**Boreas commence à exiger que les transactions aient une notion de version.**
Cette phrase sonne très “ingénieur”.
Mais quand je l’ai décomposée, j’ai réalisé qu’elle résout un problème particulièrement concret :
Si une chaîne met à niveau les règles du protocole, une même transaction, vue par des nœuds de versions différentes, peut-elle encore être considérée comme “la même transaction” ?
Boreas introduit désormais un traitement des transactions canonical, version-aware, tout en ajustant la tarification et les règles de déploiement de la VM, et en redéfinissant aussi la sémantique des transitions d’état et des events reverted. Même la documentation officielle indique clairement que ces changements font partie intégrante du cœur d’un hard fork.
Quand je regardais L1, je surveillais surtout le TPS, la finalité et le Gas.
Maintenant, je me dis plutôt que **après une mise à niveau du protocole, peut-on conserver le fait que “tout le monde comprend la même série de règles”** est peut-être encore plus important.
Parce que le véritable problème, ce n’est pas la mise à niveau elle-même.
C’est plutôt :
Comment les nœuds l’interprètent ?
Comment la validation l’interprète ?
Comment on rejoue les transactions historiques ?
Et comment les applications l’interprètent ?
Dès qu’une seule couche n’a pas la même compréhension, la suite ne relève plus de la performance : c’est l’état entier qui finit par être reconnu par “qui”.
Du coup, Boreas m’a fait comprendre pour la première fois de manière assez concrète pourquoi une blockchain mûre passe autant de temps à gérer des règles qui semblent, en apparence, “peu passionnantes”.
Elle n’ajoute pas un nouveau fonctionnalité aux utilisateurs.
Elle trace des limites à l’avance pour les développeurs, les nœuds et les applications de demain.
Avant, j’aurais pensé qu’une mise à jour comme celle-ci est difficile à transformer en contenu, parce qu’il n’y a pas de jolis chiffres, pas de nouveau produit.
Mais maintenant, au contraire, je trouve que c’est justement là qu’on voit le mieux la maturité d’ingénierie d’une chaîne.
**Un protocole vraiment fiable ne se contente pas de gérer les transactions d’aujourd’hui : il doit aussi garantir qu’après la mise à niveau de demain, les transactions d’hier ne se verront pas soudain attribuer une autre interprétation.**
C’est peut-être ça, en fait, l’intérêt principal de Boreas.
#dusk $DUSK @Dusk
