\J’ai mis en panne la finalité des états du bloc de Dusk cette semaine, car « final » est utilisé trop librement dans la documentation blockchain et je voulais savoir exactement ce que chaque état signifie dans le livre blanc, qui utilise quatre termes distincts.
Quatre choses suivent.
On accepte un bloc avec une attestation de succès, mais l’itération I > 0 et toutes les itérations précédentes n’ont pas d’attestations d’échec. Il a été intégré à la chaîne. Il peut encore être remplacé par un bloc concurrent provenant d’un numéro d’itération inférieur. Pas définitivement réglé.
Attesté : soit I = 0 (le plus bas possible, aucune itération inférieure pour le remplacer), soit toutes les itérations précédentes ont des attestations d’échec. Le bloc ne peut pas être remplacé par un bloc d’itération inférieure. C’est l’état le plus fort qu’un bloc unique puisse atteindre par lui-même, en se basant uniquement sur les propriétés de sa propre attestation.
Confirmé : le bloc est soit accepté, soit attesté, et les règles de finalité ont été respectées par ce qui vient après lui. Les blocs acceptés deviennent confirmés après 2n successeurs attestés ou confirmés consécutifs, où n est le nombre d’itérations précédentes non attestées. Les blocs attestés deviennent confirmés lorsqu’ils ont un seul successeur attesté ou confirmé.
Final : confirmé, et son parent est également final. Ne peut être remplacé dans aucune circonstance. C’est la seule vraie garantie absolue.
Je pense que cela compte surtout pour les applications qui doivent savoir quand une transaction est réellement réglée — pas seulement incluse. Utiliser « accepté » comme substitut de « réglé » laisse ouverte la possibilité d’un remplacement. Le bon déclencheur est « confirmé » au minimum, et « final » pour toute chose à enjeux élevés.
La question est de savoir si les développeurs d’applications construisant sur Dusk obtiennent un signal API clair pour chaque état — ou s’ils doivent interroger (poll) le statut des blocs et implémenter leur propre machine à états pour suivre quand un bloc spécifique passe à « final ». @Dusk
$DUSK #dusk
Quatre choses suivent.
On accepte un bloc avec une attestation de succès, mais l’itération I > 0 et toutes les itérations précédentes n’ont pas d’attestations d’échec. Il a été intégré à la chaîne. Il peut encore être remplacé par un bloc concurrent provenant d’un numéro d’itération inférieur. Pas définitivement réglé.
Attesté : soit I = 0 (le plus bas possible, aucune itération inférieure pour le remplacer), soit toutes les itérations précédentes ont des attestations d’échec. Le bloc ne peut pas être remplacé par un bloc d’itération inférieure. C’est l’état le plus fort qu’un bloc unique puisse atteindre par lui-même, en se basant uniquement sur les propriétés de sa propre attestation.
Confirmé : le bloc est soit accepté, soit attesté, et les règles de finalité ont été respectées par ce qui vient après lui. Les blocs acceptés deviennent confirmés après 2n successeurs attestés ou confirmés consécutifs, où n est le nombre d’itérations précédentes non attestées. Les blocs attestés deviennent confirmés lorsqu’ils ont un seul successeur attesté ou confirmé.
Final : confirmé, et son parent est également final. Ne peut être remplacé dans aucune circonstance. C’est la seule vraie garantie absolue.
Je pense que cela compte surtout pour les applications qui doivent savoir quand une transaction est réellement réglée — pas seulement incluse. Utiliser « accepté » comme substitut de « réglé » laisse ouverte la possibilité d’un remplacement. Le bon déclencheur est « confirmé » au minimum, et « final » pour toute chose à enjeux élevés.
La question est de savoir si les développeurs d’applications construisant sur Dusk obtiennent un signal API clair pour chaque état — ou s’ils doivent interroger (poll) le statut des blocs et implémenter leur propre machine à états pour suivre quand un bloc spécifique passe à « final ». @Dusk
$DUSK #dusk