Il y a quelques jours, j’ai vu dans un groupe de validation des gens demander : « Que faire si la chaîne n’arrive pas à sélectionner un bloc ? ». Sur le moment, j’ai répondu à la légère : « Quelqu’un finira bien par sortir un bloc ». Avec le recul, cette réponse était un peu trop hâtive.
La plupart des gens supposent que, sur une chaîne PoS, tant qu’il y a des validateurs en ligne, la finalité de la consensus finira par se faire, et au pire il faudra simplement attendre quelques tours de plus. Mais dans le livre blanc de Dusk, c’est dit très clairement : si le nombre d’itérations consécutives échouées atteint 16, le protocole désactive volontairement le mécanisme de timeout et passe en « mode d’urgence ». À ce moment-là, les options de vote « NoCandidate » et « NoQuorum » sont directement désactivées, ce qui signifie que le comité n’est plus autorisé à « ne rien choisir ».
Ce design, en soi, n’a rien de surprenant : il force le système à continuer d’avancer. Ce qui m’a vraiment laissé perplexe, c’est la phrase suivante : si, en mode d’urgence, même le timeout maximal de toutes les itérations est épuisé et qu’on n’arrive toujours pas à sélectionner un bloc candidat, que se passe-t-il ? La réponse est la suivante : une partie des provisioners peut initier une « demande de bloc d’urgence » (EBR). Tant que les personnes initiant la requête détiennent la majorité des mises (du total des tokens mis en jeu sur tout le réseau), elles peuvent directement produire un bloc vide ne contenant aucune transaction, uniquement pour permettre à la chaîne de continuer.
Je n’avais pas l’intention de le dire aussi frontalement, mais c’est essentiellement un canal légitime permettant aux parties détenant la majorité des mises de contourner le processus normal de production de blocs et de « rallumer la machine » de force.
Penchons-nous sur les intérêts : qui en profite ? Les gros détenteurs ayant la majorité des mises peuvent, dans des cas extrêmes, décider unilatéralement si la chaîne continue de fonctionner—c’est du pouvoir. Qui paie le prix ? Les utilisateurs ordinaires et les petits validateurs n’ont pas voix au chapitre dans ce type de scénario : ils doivent se contenter d’accepter un bloc « à vide » et attendre que le système reprenne un fonctionnement normal. En apparence, c’est un plan de secours technique ; mais en y regardant de plus près, cela revient à confier, dans le pire des cas, la « continuité de la chaîne » à la volonté combinée d’une petite poignée de gros détenteurs.
Le livre blanc ne précise pas non plus si ce mécanisme EBR a déjà été déclenché dans un réseau réel, ni n’offre une évaluation concrète de l’impact de « l’initiative conjointe de blocs vides par les détenteurs de la majorité des mises » sur le récit de la décentralisation. C’est une zone où, pour l’instant, je n’ai pas trouvé de réponse.
Un système visant à « empêcher l’arrêt complet » et à « confier la décision de l’arrêt aux détenteurs majoritaires des mises » : dans des cas extrêmes, ce sont en fait deux faces d’une même pièce. Vous trouvez ce compromis raisonnable ? #dusk $DUSK @Dusk
La plupart des gens supposent que, sur une chaîne PoS, tant qu’il y a des validateurs en ligne, la finalité de la consensus finira par se faire, et au pire il faudra simplement attendre quelques tours de plus. Mais dans le livre blanc de Dusk, c’est dit très clairement : si le nombre d’itérations consécutives échouées atteint 16, le protocole désactive volontairement le mécanisme de timeout et passe en « mode d’urgence ». À ce moment-là, les options de vote « NoCandidate » et « NoQuorum » sont directement désactivées, ce qui signifie que le comité n’est plus autorisé à « ne rien choisir ».
Ce design, en soi, n’a rien de surprenant : il force le système à continuer d’avancer. Ce qui m’a vraiment laissé perplexe, c’est la phrase suivante : si, en mode d’urgence, même le timeout maximal de toutes les itérations est épuisé et qu’on n’arrive toujours pas à sélectionner un bloc candidat, que se passe-t-il ? La réponse est la suivante : une partie des provisioners peut initier une « demande de bloc d’urgence » (EBR). Tant que les personnes initiant la requête détiennent la majorité des mises (du total des tokens mis en jeu sur tout le réseau), elles peuvent directement produire un bloc vide ne contenant aucune transaction, uniquement pour permettre à la chaîne de continuer.
Je n’avais pas l’intention de le dire aussi frontalement, mais c’est essentiellement un canal légitime permettant aux parties détenant la majorité des mises de contourner le processus normal de production de blocs et de « rallumer la machine » de force.
Penchons-nous sur les intérêts : qui en profite ? Les gros détenteurs ayant la majorité des mises peuvent, dans des cas extrêmes, décider unilatéralement si la chaîne continue de fonctionner—c’est du pouvoir. Qui paie le prix ? Les utilisateurs ordinaires et les petits validateurs n’ont pas voix au chapitre dans ce type de scénario : ils doivent se contenter d’accepter un bloc « à vide » et attendre que le système reprenne un fonctionnement normal. En apparence, c’est un plan de secours technique ; mais en y regardant de plus près, cela revient à confier, dans le pire des cas, la « continuité de la chaîne » à la volonté combinée d’une petite poignée de gros détenteurs.
Le livre blanc ne précise pas non plus si ce mécanisme EBR a déjà été déclenché dans un réseau réel, ni n’offre une évaluation concrète de l’impact de « l’initiative conjointe de blocs vides par les détenteurs de la majorité des mises » sur le récit de la décentralisation. C’est une zone où, pour l’instant, je n’ai pas trouvé de réponse.
Un système visant à « empêcher l’arrêt complet » et à « confier la décision de l’arrêt aux détenteurs majoritaires des mises » : dans des cas extrêmes, ce sont en fait deux faces d’une même pièce. Vous trouvez ce compromis raisonnable ? #dusk $DUSK @Dusk