Je passais en revue les changements apportés au protocole par #Dusk et un détail dans Boreas a attiré mon attention.
Boreas n’était pas une fonctionnalité.
Boreas visait à s’assurer que le réseau interprète les transactions de la même manière.
Boreas a introduit des limites entre la façon dont les transactions acceptées des clients, représentées dans Rusk, sont stockées dans le registre.
Ça ressemble à de l’ingénierie.
Je pense que Boreas est plus important qu’il n’y paraît.
Une transaction passe par plusieurs étapes avant de faire partie des données de la chaîne historique : ingestion, traitement du mempool, production de blocs, validation par consensus puis, finalement, rejouement.
Si différentes parties du nœud interprètent les octets différemment, le problème n’est pas seulement une transaction échouée.
Cela peut devenir un problème de cohérence.
Boreas y répond en utilisant un décodage conscient de la version à la frontière réseau et en canonisant les transactions avant qu’elles ne soient engagées dans des blocs.
Le point intéressant, c’est que Dusk conserve aussi des décodeurs afin que les anciens blocs puissent toujours être rejoués correctement.
Donc la conception n’est pas simplement : « changer le format de la transaction ».
Elle ressemble plutôt à : « changer les règles sans rendre l’historique ancien ambigu ».
C’est une exigence pour un réseau destiné à gérer une infrastructure financière durable.
Cela me fait regarder les mises à niveau du protocole différemment.
Un hard fork réussi ne consiste pas uniquement à ajouter de nouvelles capacités.
Il s’agit aussi de s’assurer que chaque couche s’accorde sur la signification de la transaction.
Ce que je surveille maintenant, c’est de savoir si ce type de discipline de protocole reste robuste à mesure que Dusk ajoute des chemins d’exécution et des applications financières.
Parce que la complexité ne disparaît pas quand on modularise une blockchain.
Elle se déplace seulement vers les frontières, entre les modules.
#dusk $DUSK @Dusk
Boreas n’était pas une fonctionnalité.
Boreas visait à s’assurer que le réseau interprète les transactions de la même manière.
Boreas a introduit des limites entre la façon dont les transactions acceptées des clients, représentées dans Rusk, sont stockées dans le registre.
Ça ressemble à de l’ingénierie.
Je pense que Boreas est plus important qu’il n’y paraît.
Une transaction passe par plusieurs étapes avant de faire partie des données de la chaîne historique : ingestion, traitement du mempool, production de blocs, validation par consensus puis, finalement, rejouement.
Si différentes parties du nœud interprètent les octets différemment, le problème n’est pas seulement une transaction échouée.
Cela peut devenir un problème de cohérence.
Boreas y répond en utilisant un décodage conscient de la version à la frontière réseau et en canonisant les transactions avant qu’elles ne soient engagées dans des blocs.
Le point intéressant, c’est que Dusk conserve aussi des décodeurs afin que les anciens blocs puissent toujours être rejoués correctement.
Donc la conception n’est pas simplement : « changer le format de la transaction ».
Elle ressemble plutôt à : « changer les règles sans rendre l’historique ancien ambigu ».
C’est une exigence pour un réseau destiné à gérer une infrastructure financière durable.
Cela me fait regarder les mises à niveau du protocole différemment.
Un hard fork réussi ne consiste pas uniquement à ajouter de nouvelles capacités.
Il s’agit aussi de s’assurer que chaque couche s’accorde sur la signification de la transaction.
Ce que je surveille maintenant, c’est de savoir si ce type de discipline de protocole reste robuste à mesure que Dusk ajoute des chemins d’exécution et des applications financières.
Parce que la complexité ne disparaît pas quand on modularise une blockchain.
Elle se déplace seulement vers les frontières, entre les modules.
#dusk $DUSK @Dusk
