Il y a quelques jours, je me suis surpris à réfléchir à un aspect des performances de la blockchain dont on parle rarement : que se passe-t-il lorsque le réseau ne peut plus supposer que tout fonctionne normalement ?
La plupart des projets sont faciles à admirer quand les validateurs sont en ligne, que les messages circulent et que les blocs sont produits exactement comme prévu. La question la plus difficile est de savoir ce qui se passe lorsqu’une grande partie du réseau disparaît soudainement.
Je pensais autrefois que ce n’était qu’une question d’attendre que le système se rétablisse. Mais en regardant de plus près Dusk, j’ai réalisé que la partie la plus intéressante est la manière dont le protocole est conçu pour réagir lorsque le fonctionnement normal commence à se dégrader.
La conception du consensus de Dusk prend en compte une participation dégradée. Si un nombre significatif de Provisioners se mettent hors ligne ou sont isolés, le protocole ne se contente pas de supposer que l’ensemble de validateurs attendu continuera à fonctionner normalement. Lorsque des itérations répétées du consensus n’atteignent pas le résultat requis, le protocole dispose de mécanismes lui permettant d’ajuster son comportement et de continuer à gérer l’évolution des conditions du réseau.
Cette distinction est plus importante qu’elle n’y paraît.
Une blockchain peut fonctionner extrêmement bien dans des conditions idéales. Le véritable test, c’est sa capacité à prendre des décisions sensées quand la participation diminue, que la communication devient peu fiable, ou que l’ensemble de validateurs attendu ne peut pas être constitué.
Mais il y a une autre question que je pense tout aussi importante : à quelle fréquence ces mécanismes de reprise sont-ils testés dans des conditions réalistes ?
Un protocole peut avoir, sur le papier, une stratégie de défaillance bien conçue, mais la confiance réelle vient de l’implémentation, des tests, et de l’observation du comportement du réseau quand quelque chose tourne mal.
C’est pourquoi je pense que la résilience d’une blockchain ne devrait pas être mesurée uniquement par le TPS ou les temps de bloc. Le test le plus profond est bien plus simple :
Quand quelque chose se brise, le protocole sait-il comment réagir ?
@Dusk #dusk $DUSK
$TUT $UAI
La plupart des projets sont faciles à admirer quand les validateurs sont en ligne, que les messages circulent et que les blocs sont produits exactement comme prévu. La question la plus difficile est de savoir ce qui se passe lorsqu’une grande partie du réseau disparaît soudainement.
Je pensais autrefois que ce n’était qu’une question d’attendre que le système se rétablisse. Mais en regardant de plus près Dusk, j’ai réalisé que la partie la plus intéressante est la manière dont le protocole est conçu pour réagir lorsque le fonctionnement normal commence à se dégrader.
La conception du consensus de Dusk prend en compte une participation dégradée. Si un nombre significatif de Provisioners se mettent hors ligne ou sont isolés, le protocole ne se contente pas de supposer que l’ensemble de validateurs attendu continuera à fonctionner normalement. Lorsque des itérations répétées du consensus n’atteignent pas le résultat requis, le protocole dispose de mécanismes lui permettant d’ajuster son comportement et de continuer à gérer l’évolution des conditions du réseau.
Cette distinction est plus importante qu’elle n’y paraît.
Une blockchain peut fonctionner extrêmement bien dans des conditions idéales. Le véritable test, c’est sa capacité à prendre des décisions sensées quand la participation diminue, que la communication devient peu fiable, ou que l’ensemble de validateurs attendu ne peut pas être constitué.
Mais il y a une autre question que je pense tout aussi importante : à quelle fréquence ces mécanismes de reprise sont-ils testés dans des conditions réalistes ?
Un protocole peut avoir, sur le papier, une stratégie de défaillance bien conçue, mais la confiance réelle vient de l’implémentation, des tests, et de l’observation du comportement du réseau quand quelque chose tourne mal.
C’est pourquoi je pense que la résilience d’une blockchain ne devrait pas être mesurée uniquement par le TPS ou les temps de bloc. Le test le plus profond est bien plus simple :
Quand quelque chose se brise, le protocole sait-il comment réagir ?
@Dusk #dusk $DUSK
$TUT $UAI
