J’ai découvert un mode de défaillance plus sournois sur DUSK qu’un rejet de transaction : les mêmes octets de transaction sont acceptés, puis interprétés différemment selon la partie de Rusk qui les touche.

C’est le désordre que Boreas a dû résoudre. Les transactions en direct sont décodées selon la version active du protocole. Les anciennes enveloppes Aegis peuvent encore arriver au bord du réseau, mais Rusk les normalise avant qu’elles ne pénètrent plus profondément. Les transactions scellées localement sont à nouveau canoniquement traitées avant d’être validées dans le registre.

Le point gênant, c’est l’historique. DUSK ne peut pas simplement supprimer les anciennes règles après une mise à niveau, car les nœuds doivent encore rejouer les blocs antérieurs à Aegis et à Boreas. Le nœud actuel doit donc comprendre les formats d’hier, sans laisser les règles d’hier se répercuter dans la production des blocs d’aujourd’hui.

Pour un opérateur, la conséquence est brutalement simple. Un redémarrage, une reconstruction de l’archive ou une exécution complète de rejouement doivent reconstituer le même état de chaîne que le nœud en direct a atteint. Si le mempool donne un sens et que le rejouement historique en donne un autre, tout peut sembler sain jusqu’à ce qu’un index, un solde ou une transition d’état diverge.

Je me soucie moins du fait qu’une mise à niveau modifie des règles de transaction que de savoir si DUSK peut les modifier sans modifier le passé.

#dusk $DUSK @Dusk