#dusk $DUSK @Dusk J’étais à moitié de mon premier café ce matin quand une pensée sur l’immutabilité de la blockchain a commencé à me déranger. L’historique reste On-chain, mais les règles utilisées pour traiter les nouveaux blocs continuent d’évoluer.
Cela m’a amené à regarder les mises à niveau de Dusk différemment. J’associe habituellement une mise à jour de protocole à de nouvelles capacités. Boreas m’a fait remarquer l’exigence moins visible. Les nouvelles règles de transaction doivent évoluer sans modifier la façon dont les anciens blocs sont interprétés selon les règles qui les ont produits.
Boreas a introduit une gestion distincte pour les transactions côté client, les données de transaction canoniques et le format du registre engagé dans les blocs. Rusk conserve aussi les décodeurs historiques nécessaires pour rejouer les blocs Pré-Aegis et Pré-Boreas. Aegis fait quelque chose de similaire avec la vérification des preuves. Rusk choisit le vérificateur en fonction de la hauteur du bloc, en conservant les règles PLONK V1/V2 pour les blocs historiques tout en utilisant V3 pour les preuves plus récentes.
C’est ce détail qui m’a fait comprendre. Conserver une ancienne transaction On-chain préserve la trace, mais ne préserve pas automatiquement la capacité de reproduire pourquoi cette transaction était valide.
Ainsi, je vois les sémantiques historiques comme une véritable part de l’immutabilité. La chaîne doit préserver non seulement ce qui s’est passé, mais aussi suffisamment de contexte de protocole pour reproduire comment cet état historique a été validé.
Il y a toutefois un compromis. Conserver les anciens décodeurs et chemins de vérification signifie porter davantage de complexité de protocole dans le futur. Mais les supprimer reporte un risque différent sur les logiciels à venir : décider eux-mêmes comment interpréter les enregistrements historiques.
C’est là que, pour moi, cela devient plus qu’un simple problème de maintenance logicielle.
Dans les marchés réglementés, l’auditabilité doit répondre à plus que “montre-moi la transaction”. Elle doit aussi répondre : Quelles règles ont rendu cette transaction valide à ce moment précis de la chaîne ?
Plus j’explore l’évolution du protocole, plus je pense que l’immutabilité a une deuxième exigence au-delà de la conservation de l’historique.
Si l’enregistrement survit mais que les règles nécessaires pour en reproduire la signification ne survivent pas, à quel point cette histoire est-elle réellement immuable ? 🧩
$FF $P
Cela m’a amené à regarder les mises à niveau de Dusk différemment. J’associe habituellement une mise à jour de protocole à de nouvelles capacités. Boreas m’a fait remarquer l’exigence moins visible. Les nouvelles règles de transaction doivent évoluer sans modifier la façon dont les anciens blocs sont interprétés selon les règles qui les ont produits.
Boreas a introduit une gestion distincte pour les transactions côté client, les données de transaction canoniques et le format du registre engagé dans les blocs. Rusk conserve aussi les décodeurs historiques nécessaires pour rejouer les blocs Pré-Aegis et Pré-Boreas. Aegis fait quelque chose de similaire avec la vérification des preuves. Rusk choisit le vérificateur en fonction de la hauteur du bloc, en conservant les règles PLONK V1/V2 pour les blocs historiques tout en utilisant V3 pour les preuves plus récentes.
C’est ce détail qui m’a fait comprendre. Conserver une ancienne transaction On-chain préserve la trace, mais ne préserve pas automatiquement la capacité de reproduire pourquoi cette transaction était valide.
Ainsi, je vois les sémantiques historiques comme une véritable part de l’immutabilité. La chaîne doit préserver non seulement ce qui s’est passé, mais aussi suffisamment de contexte de protocole pour reproduire comment cet état historique a été validé.
Il y a toutefois un compromis. Conserver les anciens décodeurs et chemins de vérification signifie porter davantage de complexité de protocole dans le futur. Mais les supprimer reporte un risque différent sur les logiciels à venir : décider eux-mêmes comment interpréter les enregistrements historiques.
C’est là que, pour moi, cela devient plus qu’un simple problème de maintenance logicielle.
Dans les marchés réglementés, l’auditabilité doit répondre à plus que “montre-moi la transaction”. Elle doit aussi répondre : Quelles règles ont rendu cette transaction valide à ce moment précis de la chaîne ?
Plus j’explore l’évolution du protocole, plus je pense que l’immutabilité a une deuxième exigence au-delà de la conservation de l’historique.
Si l’enregistrement survit mais que les règles nécessaires pour en reproduire la signification ne survivent pas, à quel point cette histoire est-elle réellement immuable ? 🧩
$FF $P
