#dusk $DUSK @Dusk
Cette semaine, je parcourais la documentation de consensus de Dusk, surtout pour vérifier si la « finalité rapide » tient vraiment sous contrainte, et pas seulement lors d’une journée réseau impeccable. L’Attestation concise fait passer chaque tour par trois étapes — proposition, validation, ratification — avec un générateur de blocs et deux comités choisis par une sortition déterministe, pondérés par la mise plutôt que par le nombre de validateurs. D’accord, cela explique les conditions normales.
Ce qui m’a surpris, c’est la clause « Emergency Mode », enfouie au-delà de la description du scénario heureux. Si les itérations continuent d’échouer, le protocole ne se contente pas de réessayer sur un minuteur : il désactive entièrement les timeouts et continue de tourner jusqu’à ce que le quorum soit réellement atteint. C’est un mode de défaillance sensiblement différent de celui de la plupart des chaînes PoS, qui attendent surtout que la panne passe et espèrent que les validateurs se reconnectent. Retirer le délai semble résilient sur le papier, mais cela signifie aussi que le temps de finalité devient non borné précisément dans le scénario où la certitude compte le plus : pendant une panne, et non après.
Pour un réseau qui se positionne pour la finance réglementée, ce compromis mérite qu’on s’y attarde plutôt que de le survoler. Un système de règlement qui garantit « finalement correct » n’est pas tout à fait la même promesse que « rapide », et je ne suis pas sûr que @Dusk ait entièrement réconcilié lequel il vend réellement. À quelle fréquence le mode d’urgence s’est-il effectivement déclenché sur le mainnet jusqu’à présent ?
$DUSK #DUSK
Cette semaine, je parcourais la documentation de consensus de Dusk, surtout pour vérifier si la « finalité rapide » tient vraiment sous contrainte, et pas seulement lors d’une journée réseau impeccable. L’Attestation concise fait passer chaque tour par trois étapes — proposition, validation, ratification — avec un générateur de blocs et deux comités choisis par une sortition déterministe, pondérés par la mise plutôt que par le nombre de validateurs. D’accord, cela explique les conditions normales.
Ce qui m’a surpris, c’est la clause « Emergency Mode », enfouie au-delà de la description du scénario heureux. Si les itérations continuent d’échouer, le protocole ne se contente pas de réessayer sur un minuteur : il désactive entièrement les timeouts et continue de tourner jusqu’à ce que le quorum soit réellement atteint. C’est un mode de défaillance sensiblement différent de celui de la plupart des chaînes PoS, qui attendent surtout que la panne passe et espèrent que les validateurs se reconnectent. Retirer le délai semble résilient sur le papier, mais cela signifie aussi que le temps de finalité devient non borné précisément dans le scénario où la certitude compte le plus : pendant une panne, et non après.
Pour un réseau qui se positionne pour la finance réglementée, ce compromis mérite qu’on s’y attarde plutôt que de le survoler. Un système de règlement qui garantit « finalement correct » n’est pas tout à fait la même promesse que « rapide », et je ne suis pas sûr que @Dusk ait entièrement réconcilié lequel il vend réellement. À quelle fréquence le mode d’urgence s’est-il effectivement déclenché sur le mainnet jusqu’à présent ?
$DUSK #DUSK