Je n’arrête pas de penser à deux types de transaction que Dusk a introduits dans Rusk : CanonicalTransaction et LedgerTransaction.
Ils représentent différentes couches de la même transaction. CanonicalTransaction est la forme avec laquelle Rusk travaille logiquement, tandis que LedgerTransaction encapsule cette transaction dans la représentation du registre requise pour une version particulière du protocole. La tension est que Dusk veut faire évoluer ces formats de stockage sans forcer le sens d’une transaction à évoluer avec eux, une propriété importante alors qu’il s’agit de porter les marchés financiers onchain avec des institutions agréées par l’UE. Ce que je ne sais pas encore, c’est si cette séparation permettra réellement de contenir les changements de version dans Rusk, ou si des changements de format finiront quand même par déborder vers les portefeuilles, les applications et la relecture historique.
Les détails à surveiller sont la manière dont Dusk normalise les transactions entrantes, sélectionne la représentation de registre correcte, et interprète les transactions plus anciennes après des mises à niveau du protocole.
Un portefeuille qui continue à soumettre des transactions après une mise à niveau est une preuve utile de compatibilité. Le test le plus solide est de savoir si Dusk peut modifier la représentation en dessous tout en préservant la même sémantique de transaction au-dessus.
J’évaluerais cette abstraction à la quantité minimale de complexité de versioning que les applications doivent connaître.
La question est de savoir si Dusk a véritablement séparé ce que signifie une transaction de la manière dont le registre la stocke, ou s’il a simplement déplacé la charge de gestion des versions ailleurs dans la pile.
Je surveille la solidité de cette frontière face à de futurs changements de format et à la relecture historique.
#dusk $DUSK @Dusk
Ils représentent différentes couches de la même transaction. CanonicalTransaction est la forme avec laquelle Rusk travaille logiquement, tandis que LedgerTransaction encapsule cette transaction dans la représentation du registre requise pour une version particulière du protocole. La tension est que Dusk veut faire évoluer ces formats de stockage sans forcer le sens d’une transaction à évoluer avec eux, une propriété importante alors qu’il s’agit de porter les marchés financiers onchain avec des institutions agréées par l’UE. Ce que je ne sais pas encore, c’est si cette séparation permettra réellement de contenir les changements de version dans Rusk, ou si des changements de format finiront quand même par déborder vers les portefeuilles, les applications et la relecture historique.
Les détails à surveiller sont la manière dont Dusk normalise les transactions entrantes, sélectionne la représentation de registre correcte, et interprète les transactions plus anciennes après des mises à niveau du protocole.
Un portefeuille qui continue à soumettre des transactions après une mise à niveau est une preuve utile de compatibilité. Le test le plus solide est de savoir si Dusk peut modifier la représentation en dessous tout en préservant la même sémantique de transaction au-dessus.
J’évaluerais cette abstraction à la quantité minimale de complexité de versioning que les applications doivent connaître.
La question est de savoir si Dusk a véritablement séparé ce que signifie une transaction de la manière dont le registre la stocke, ou s’il a simplement déplacé la charge de gestion des versions ailleurs dans la pile.
Je surveille la solidité de cette frontière face à de futurs changements de format et à la relecture historique.
#dusk $DUSK @Dusk