#dusk $DUSK @Dusk
Au début, je pensais que la limite de 50 itérations de Dusk n’était qu’un plafond technique. Plus je l’observais, plus cela me donnait l’impression de n’être qu’une petite fenêtre sur la manière dont le réseau gère le désaccord.
Le consensus de Dusk est conçu pour progresser à travers la proposition, la validation et la ratification, avec des provisioners sélectionnés via une sélection déterministe. Mais lorsque des messages arrivent en retard, que les provisioners disparaissent ou que la communication devient chaotique, le consensus ne renonce pas immédiatement. Il se donne davantage de chances de converger.
Cela a changé ma façon de lire ce nombre.
Ce n’est pas vraiment une question de « 50 tentatives ». Cela ressemble plutôt à une réserve de patience, destinée aux moments où le réseau cesse de se comporter normalement.
J’ai aussi trouvé intéressant le travail de Dusk qui consiste à court-circuiter les itérations qui ont expiré, puis à repropager des messages provenant d’itérations passées ou futures. Pour moi, cela pointe vers un problème moins évident : la reprise n’est pas seulement une question de réessayer ; il s’agit de rendre ces tentatives supplémentaires utiles.
Et c’est là que l’arbitrage devient vraiment intéressant.
Trop peu d’itérations peuvent faire passer une perturbation temporaire pour un échec. Trop d’itérations peuvent amener le réseau à passer du temps à poursuivre l’accord, tandis que la latence continue de s’accumuler.
Alors je reviens toujours à ceci :
Quelle quantité de désaccord Dusk peut-elle tolérer avant que le mécanisme conçu pour s’en remettre ne devienne lui-même une source de délai ?
@Dusk #dusk $DUSK
Au début, je pensais que la limite de 50 itérations de Dusk n’était qu’un plafond technique. Plus je l’observais, plus cela me donnait l’impression de n’être qu’une petite fenêtre sur la manière dont le réseau gère le désaccord.
Le consensus de Dusk est conçu pour progresser à travers la proposition, la validation et la ratification, avec des provisioners sélectionnés via une sélection déterministe. Mais lorsque des messages arrivent en retard, que les provisioners disparaissent ou que la communication devient chaotique, le consensus ne renonce pas immédiatement. Il se donne davantage de chances de converger.
Cela a changé ma façon de lire ce nombre.
Ce n’est pas vraiment une question de « 50 tentatives ». Cela ressemble plutôt à une réserve de patience, destinée aux moments où le réseau cesse de se comporter normalement.
J’ai aussi trouvé intéressant le travail de Dusk qui consiste à court-circuiter les itérations qui ont expiré, puis à repropager des messages provenant d’itérations passées ou futures. Pour moi, cela pointe vers un problème moins évident : la reprise n’est pas seulement une question de réessayer ; il s’agit de rendre ces tentatives supplémentaires utiles.
Et c’est là que l’arbitrage devient vraiment intéressant.
Trop peu d’itérations peuvent faire passer une perturbation temporaire pour un échec. Trop d’itérations peuvent amener le réseau à passer du temps à poursuivre l’accord, tandis que la latence continue de s’accumuler.
Alors je reviens toujours à ceci :
Quelle quantité de désaccord Dusk peut-elle tolérer avant que le mécanisme conçu pour s’en remettre ne devienne lui-même une source de délai ?
@Dusk #dusk $DUSK