Un dépôt DUSK finalisé est automatiquement sûr à créditer.
La finalité n’a pas fini le travail
J’ai supposé qu’une fois qu’un dépôt Moonlight atteignait la finalité, une plateforme d’échange pouvait écrire en toute sécurité le crédit du client et passer à autre chose.
La documentation de Dusk sépare deux choses.
Le scanner lit l’historique Moonlight finalisé, mais la garde doit faire avancer ensemble le crédit et son point de contrôle (block checkpoint). Chaque crédit utilise l’ID de transaction Dusk comme clé unique, et `next_block` n’avance qu’après que le crédit est durable.
Prenons maintenant un exemple construit : le scanner termine une plage finalisée jusqu’au bloc 12 000. Il écrit un dépôt de 5 DUSK pour Alice, puis plante avant que `next_block` n’avance.
Quand il redémarre, il relit cette plage.
Le dépôt est toujours finalisé. Le second scan est toujours sûr. L’ID de transaction empêche le même dépôt de devenir un second crédit.
Mais inversez l’ordre.
Si `next_block` a avancé avant que le crédit ne soit durable, un crash pourrait amener le scanner à penser que la plage était terminée sans que le dépôt du client ait jamais été enregistré. Les documents de Dusk avertissent explicitement contre cet ordre.
Ainsi, la finalité répond à une question : « Ce mouvement DUSK est-il réglé ? »
La garde répond à une autre : « Avons-nous enregistré exactement une seule fois ce mouvement réglé ? »
Les deux doivent être corrects pour que le solde de l’échange soit correct.
Quelle part d’un « dépôt sûr » provient de la finalité de Dusk, et quelle part provient de la mécanique comptable qui fait qu’un événement finalisé survit aux pannes sans être perdu ni crédité deux fois ?
@Dusk #dusk $DUSK
La finalité n’a pas fini le travail
J’ai supposé qu’une fois qu’un dépôt Moonlight atteignait la finalité, une plateforme d’échange pouvait écrire en toute sécurité le crédit du client et passer à autre chose.
La documentation de Dusk sépare deux choses.
Le scanner lit l’historique Moonlight finalisé, mais la garde doit faire avancer ensemble le crédit et son point de contrôle (block checkpoint). Chaque crédit utilise l’ID de transaction Dusk comme clé unique, et `next_block` n’avance qu’après que le crédit est durable.
Prenons maintenant un exemple construit : le scanner termine une plage finalisée jusqu’au bloc 12 000. Il écrit un dépôt de 5 DUSK pour Alice, puis plante avant que `next_block` n’avance.
Quand il redémarre, il relit cette plage.
Le dépôt est toujours finalisé. Le second scan est toujours sûr. L’ID de transaction empêche le même dépôt de devenir un second crédit.
Mais inversez l’ordre.
Si `next_block` a avancé avant que le crédit ne soit durable, un crash pourrait amener le scanner à penser que la plage était terminée sans que le dépôt du client ait jamais été enregistré. Les documents de Dusk avertissent explicitement contre cet ordre.
Ainsi, la finalité répond à une question : « Ce mouvement DUSK est-il réglé ? »
La garde répond à une autre : « Avons-nous enregistré exactement une seule fois ce mouvement réglé ? »
Les deux doivent être corrects pour que le solde de l’échange soit correct.
Quelle part d’un « dépôt sûr » provient de la finalité de Dusk, et quelle part provient de la mécanique comptable qui fait qu’un événement finalisé survit aux pannes sans être perdu ni crédité deux fois ?
@Dusk #dusk $DUSK