Au début, je pensais que la seule chose pouvant faire perdre à un fournisseur de finalité sa position était un comportement malveillant pur : signer deux blocs contradictoires, être pris, être pénalisé, le binaire classique « honnête ou malhonnête ». En lisant la documentation du module de finalité de Babylon, j’ai découvert qu’il existe un deuxième chemin d’échec, plus silencieux, qui n’a rien à voir avec l’honnêteté. Avant qu’un fournisseur de finalité puisse même voter sur un bloc, il doit s’engager proactivement à fournir une aléa public EOTS pour cette hauteur future spécifique, à l’avance, avant même que le bloc ne soit proposé. Le système de Babylon suit séparément deux catégories de fournisseurs problématiques : ceux qui s’équivoquent et qui sont pris en train de signer des messages contradictoires, et ceux qui sont lents et qui, tout simplement, ne se présentent pas à temps. Être lent n’est pas la même violation qu’être malhonnête, mais cela est tout de même suivi et pénalisé en tant que catégorie distincte. Concrètement, cela signifie qu’un fournisseur peut être totalement honnête, ne jamais signer quoi que ce soit de contradictoire, ne jamais tenter quelque chose de manière adversariale, et pourtant perdre la capacité de voter pour une hauteur donnée uniquement parce que son engagement d’aléa n’a pas suivi le rythme du sommet (tip) de la chaîne. S’engager sur un aléa n’est pas une étape unique : c’est un travail continu de prévision, qui consiste à rester en avance sur une chaîne qui continue de bouger que vous soyez prêt ou non. Ainsi, le modèle de sécurité réellement décrit n’oppose pas seulement les comportements honnêtes aux comportements malveillants. Il oppose « honnête et ponctuel » à tout le reste, y compris les fournisseurs honnêtes qui ont simplement pris du retard sur une exigence de planification que la plupart des personnes qui misent sur eux ne penseront probablement jamais à vérifier.
@BabylonLabs_io #baby $BABY