Après un hard fork, les formats historiques des transactions sont morts.
Dusk ne les laisse pas disparaître aussi facilement.
Boreas a été activé à la reprise du mainnet au bloc 4,414,095, introduisant une gestion des transactions tenant compte de la version et séparant les données canoniques de la transaction de l’enveloppe de registre préservée dans l’historique.
Dites qu’un nœud rejoue un bloc enregistré avant la transition. Cette transaction historique a encore besoin de son chemin de décodage original pour reconstruire correctement le registre. Envoyez le même format historique dans l’admission en mempool en direct après la transition, et Dusk le rejette.
La partie étrange, c’est que les deux issues sont nécessaires.
La relecture demande ce que la chaîne a réellement enregistré. L’admission en direct demande quel format la chaîne accepte désormais. Dusk ne peut pas utiliser une seule règle pour les deux sans casser l’une de ces tâches.
Ainsi, un format historique peut être nécessaire pour reconstruire le passé tout en étant inacceptable pour entrer dans le réseau aujourd’hui. Sa signification n’a pas disparu. Son rôle a changé à la frontière.
Quelle part de la validité d’une transaction dépend vraiment de ce que le réseau accepte à la hauteur actuelle, et quelle part dépend de la préservation exacte de ce que la chaîne a déjà validé ?
@Dusk $DUSK #dusk
Dusk ne les laisse pas disparaître aussi facilement.
Boreas a été activé à la reprise du mainnet au bloc 4,414,095, introduisant une gestion des transactions tenant compte de la version et séparant les données canoniques de la transaction de l’enveloppe de registre préservée dans l’historique.
Dites qu’un nœud rejoue un bloc enregistré avant la transition. Cette transaction historique a encore besoin de son chemin de décodage original pour reconstruire correctement le registre. Envoyez le même format historique dans l’admission en mempool en direct après la transition, et Dusk le rejette.
La partie étrange, c’est que les deux issues sont nécessaires.
La relecture demande ce que la chaîne a réellement enregistré. L’admission en direct demande quel format la chaîne accepte désormais. Dusk ne peut pas utiliser une seule règle pour les deux sans casser l’une de ces tâches.
Ainsi, un format historique peut être nécessaire pour reconstruire le passé tout en étant inacceptable pour entrer dans le réseau aujourd’hui. Sa signification n’a pas disparu. Son rôle a changé à la frontière.
Quelle part de la validité d’une transaction dépend vraiment de ce que le réseau accepte à la hauteur actuelle, et quelle part dépend de la préservation exacte de ce que la chaîne a déjà validé ?
@Dusk $DUSK #dusk