#dusk $DUSK
Aujourd’hui, je continue de regarder les mises à jour de Boreas associées à @Dusk . Ce qui m’inquiète le plus n’est ni le retrait de Phoenix, ni le fait qu’on ait ajouté quelques règles de fork.
Ce qui m’intrigue, c’est plutôt un problème plus profond :
Après une mise à niveau du protocole, pourquoi une transaction passée peut-elle conserver indéfiniment le même sens ?
À première vue, ça ressemble à une évidence.
Mais après un hard fork, les nœuds tournent bien avec les nouvelles règles, alors que, dans les blocs historiques, on trouve toujours d’anciennes versions de transactions, de vieux vérificateurs et de vieilles sémantiques d’exécution.
Si aujourd’hui un nœud réinterprète les bytes d’hier avec le nouvel ensemble de règles, le replay historique peut alors poser problème.
C’est pour cela que, cette fois, Boreas rend la frontière de version pour la gestion des transactions beaucoup plus explicite.
L’ingress live suit les règles actuelles du protocole.
L’ancien envelope peut être identifié et normalisé à l’entrée.
Avant d’entrer dans le ledger, il est alors transformé en transaction canonique.
Et pour les blocs historiques, on continue à décoder et rejouer en appliquant les règles de l’époque.
Je pense que ce qui est vraiment important ici n’est pas seulement « l’unification du format ».
C’est plutôt :
Une transaction, ce n’est pas uniquement son contenu — c’est aussi l’ère du protocole à laquelle elle appartient.
Aegis, ce sont les règles d’Aegis.
Boreas, ce sont les règles de Boreas.
Un hard fork peut changer l’avenir, mais il ne doit pas réinterpréter le passé « par-dessus », de manière involontaire.
C’est aussi la raison pour laquelle, lorsque je regarde une mise à niveau de la chaîne, je ne me contente pas de regarder « ce qui est ajouté ».
Ce qui m’intéresse, c’est :
Après le déploiement de la nouvelle version, est-ce que les nœuds d’aujourd’hui peuvent comprendre correctement ce qui s’est passé sur la chaîne il y a plusieurs années ?
Pour un réseau qui vise à être une infrastructure de marché réglementée, cette continuité historique est en fait fondamentale.
Les livres peuvent évoluer.
Mais le passé dans le livre ne peut pas être mis à niveau en même temps.
Aujourd’hui, je continue de regarder les mises à jour de Boreas associées à @Dusk . Ce qui m’inquiète le plus n’est ni le retrait de Phoenix, ni le fait qu’on ait ajouté quelques règles de fork.
Ce qui m’intrigue, c’est plutôt un problème plus profond :
Après une mise à niveau du protocole, pourquoi une transaction passée peut-elle conserver indéfiniment le même sens ?
À première vue, ça ressemble à une évidence.
Mais après un hard fork, les nœuds tournent bien avec les nouvelles règles, alors que, dans les blocs historiques, on trouve toujours d’anciennes versions de transactions, de vieux vérificateurs et de vieilles sémantiques d’exécution.
Si aujourd’hui un nœud réinterprète les bytes d’hier avec le nouvel ensemble de règles, le replay historique peut alors poser problème.
C’est pour cela que, cette fois, Boreas rend la frontière de version pour la gestion des transactions beaucoup plus explicite.
L’ingress live suit les règles actuelles du protocole.
L’ancien envelope peut être identifié et normalisé à l’entrée.
Avant d’entrer dans le ledger, il est alors transformé en transaction canonique.
Et pour les blocs historiques, on continue à décoder et rejouer en appliquant les règles de l’époque.
Je pense que ce qui est vraiment important ici n’est pas seulement « l’unification du format ».
C’est plutôt :
Une transaction, ce n’est pas uniquement son contenu — c’est aussi l’ère du protocole à laquelle elle appartient.
Aegis, ce sont les règles d’Aegis.
Boreas, ce sont les règles de Boreas.
Un hard fork peut changer l’avenir, mais il ne doit pas réinterpréter le passé « par-dessus », de manière involontaire.
C’est aussi la raison pour laquelle, lorsque je regarde une mise à niveau de la chaîne, je ne me contente pas de regarder « ce qui est ajouté ».
Ce qui m’intéresse, c’est :
Après le déploiement de la nouvelle version, est-ce que les nœuds d’aujourd’hui peuvent comprendre correctement ce qui s’est passé sur la chaîne il y a plusieurs années ?
Pour un réseau qui vise à être une infrastructure de marché réglementée, cette continuité historique est en fait fondamentale.
Les livres peuvent évoluer.
Mais le passé dans le livre ne peut pas être mis à niveau en même temps.