Je réfléchissais à ce qui se passe lorsqu’une transaction atteint Dusk.

Au début, on a l’impression qu’il n’y a qu’une seule question :

**« Le réseau doit-il accepter cette transaction ? »**

Mais en regardant de plus près, il y a en réalité deux questions différentes.

D’abord, la transaction respecte-t-elle les règles du protocole ?

Ensuite, en supposant que oui, les participants s’accordent-ils sur l’état qui en résulte ?

Cette distinction est facile à manquer, parce que, de l’extérieur, les deux étapes conduisent au même résultat : un état accepté.

Mais, sur le plan architectural, ce sont des tâches différentes.

En cas de problème, les séparer facilite la tâche pour déterminer ce qui a réellement échoué. La transaction était-elle invalide ? Ou bien elle était valide, mais les participants n’étaient-ils pas d’accord sur l’état qui en découle ?

Je pense que cette séparation est un choix de conception solide.

Mais elle soulève aussi une nouvelle question.

Chaque frontière entre des responsabilités correspond à un nouveau relais. Et chaque relais doit fonctionner correctement quand quelque chose d’inattendu se produit.

Alors je reviens toujours à ceci :

**La séparation entre la validité et le consensus rend-elle Dusk plus facile à analyser en cas de défaillance, ou bien chaque frontière supplémentaire crée-t-elle un autre endroit où le système peut se briser ?**

#Dusk @Dusk $DUSK