La semaine dernière, j’ai envoyé un colis en me trompant de quelque chose ; après avoir contacté le service client, celui-ci m’a expliqué : l’état du transport n’est pas seulement « expédié » ou « non expédié », en noir et blanc. Entre les deux, il y a « expédié », « en transit » et « livré / signé ». À chaque étape, peut-on intercepter, rappeler ? Les règles ne sont pas du tout les mêmes. Après avoir raccroché, je me suis soudain rappelé que la « confirmation » sur la blockchain suit aussi cette logique : ce n’est pas simplement « confirmé » ou « pas confirmé ».
Ici, côté Dusk, les statuts de bloc sont répartis en quatre niveaux. Un bloc tout juste créé, s’il passe dès le premier tour de vote, s’appelle « attested » (déjà attesté). S’il y a eu des échecs aux tours précédents, et qu’il passe seulement maintenant, il s’appelle « accepted » (accepté) — et il pourrait encore être remplacé par un bloc à un tour inférieur. Ensuite, en avançant : un bloc « attested » devient « confirmed » (confirmé) dès qu’il est raccordé par des blocs suivants. Un bloc « accepted » doit, lui, attendre qu’un nombre suffisamment spécifique de blocs suivants tienne bon pour pouvoir monter à « confirmed ». Enfin, dernière étape : un bloc « confirmed » ne peut passer à « final » (final / indépassable) que si son « bloc parent » est lui-même déjà en état final. Une fois ce statut atteint, il devient définitivement irréversible.
Cette conception par niveaux répond au problème « à quelle vitesse peut-on être rassuré ? » — tous les blocs ne doivent pas attendre le niveau le plus élevé pour être utilisables. Dans les scénarios légers, on peut agir dès qu’on « attested ». Dans les scénarios à gros enjeux, il faut attendre jusqu’à « final » pour être totalement rassuré. Des seuils de confirmation différents correspondent à différents niveaux de tolérance au risque ; cette flexibilité est vraiment utile.
Le revers, c’est la complexité : pour l’utilisateur lambda, il est difficile de savoir directement à quel niveau est parvenue sa transaction. Pour l’instant, cela dépend principalement des affichages côté logiciel des nœuds et côté portefeuille — et la qualité de l’expérience dépendra de la mise en œuvre réelle.
$DUSK
#dusk @Dusk
Ici, côté Dusk, les statuts de bloc sont répartis en quatre niveaux. Un bloc tout juste créé, s’il passe dès le premier tour de vote, s’appelle « attested » (déjà attesté). S’il y a eu des échecs aux tours précédents, et qu’il passe seulement maintenant, il s’appelle « accepted » (accepté) — et il pourrait encore être remplacé par un bloc à un tour inférieur. Ensuite, en avançant : un bloc « attested » devient « confirmed » (confirmé) dès qu’il est raccordé par des blocs suivants. Un bloc « accepted » doit, lui, attendre qu’un nombre suffisamment spécifique de blocs suivants tienne bon pour pouvoir monter à « confirmed ». Enfin, dernière étape : un bloc « confirmed » ne peut passer à « final » (final / indépassable) que si son « bloc parent » est lui-même déjà en état final. Une fois ce statut atteint, il devient définitivement irréversible.
Cette conception par niveaux répond au problème « à quelle vitesse peut-on être rassuré ? » — tous les blocs ne doivent pas attendre le niveau le plus élevé pour être utilisables. Dans les scénarios légers, on peut agir dès qu’on « attested ». Dans les scénarios à gros enjeux, il faut attendre jusqu’à « final » pour être totalement rassuré. Des seuils de confirmation différents correspondent à différents niveaux de tolérance au risque ; cette flexibilité est vraiment utile.
Le revers, c’est la complexité : pour l’utilisateur lambda, il est difficile de savoir directement à quel niveau est parvenue sa transaction. Pour l’instant, cela dépend principalement des affichages côté logiciel des nœuds et côté portefeuille — et la qualité de l’expérience dépendra de la mise en œuvre réelle.
$DUSK
#dusk @Dusk