J’ai vu un validateur DUSK être retiré de l’ensemble actif sur le testnet. Pas piraté. Pas slashté. Simplement retiré. La raison était la vivacité : trop de votes de finalité manqués dans une fenêtre de 28 heures.
Le système a fonctionné exactement comme prévu. C’est ça qui m’a troublé.
Le validateur n’a pas perdu sa mise mise en gage. Aucune punition cryptographique. Aucune clé privée exposée. Juste une sortie silencieuse du tour de consensus. Et voici la partie qui est restée avec moi : la fenêtre de mise à l’écart (jailing) est mesurée par rapport à une valeur StartHeight qui se réinitialise à chaque fois que le fournisseur se réintègre. Partir brièvement, revenir, réinitialiser l’horloge, répéter. Un opérateur chroniquement peu fiable peut éviter indéfiniment la suppression permanente en ne restant jamais hors ligne assez longtemps pour déclencher la pleine pénalité. Le chemin d’application en douceur (soft enforcement) est celui qui comporte la faille.
Je n’ai cessé d’y penser en regardant la communauté DUSK débattre pour savoir si les fournisseurs de finalité devraient être traités comme une infrastructure ou comme des partenaires. Quelqu’un dans le chat a dit : « Si la punition pour l’absence de fiabilité est un délai d’attente, alors l’absence de fiabilité n’est qu’une stratégie avec des étapes en plus. » Personne n’a ri. Parce que tout le monde connaissait un validateur qui réinitialise sa propre horloge de mise à l’écart : il ne transgresse pas les règles. Il joue simplement avec le rythme de l’application des sanctions.
C’est l’écart entre la sécurité technique et la sécurité pratique. Le déclencheur cryptographique du double-signing est absolu, impitoyable, automatique. Le déclencheur social de la négligence est une machine à états avec un bouton de réinitialisation. L’un protège le réseau de la malveillance. L’autre le protège de l’abandon. Et à l’heure actuelle, le bouton de réinitialisation appartient à l’opérateur même qu’il est censé contraindre.
#dusk $DUSK @Dusk $EDEN $AKE
Le système a fonctionné exactement comme prévu. C’est ça qui m’a troublé.
Le validateur n’a pas perdu sa mise mise en gage. Aucune punition cryptographique. Aucune clé privée exposée. Juste une sortie silencieuse du tour de consensus. Et voici la partie qui est restée avec moi : la fenêtre de mise à l’écart (jailing) est mesurée par rapport à une valeur StartHeight qui se réinitialise à chaque fois que le fournisseur se réintègre. Partir brièvement, revenir, réinitialiser l’horloge, répéter. Un opérateur chroniquement peu fiable peut éviter indéfiniment la suppression permanente en ne restant jamais hors ligne assez longtemps pour déclencher la pleine pénalité. Le chemin d’application en douceur (soft enforcement) est celui qui comporte la faille.
Je n’ai cessé d’y penser en regardant la communauté DUSK débattre pour savoir si les fournisseurs de finalité devraient être traités comme une infrastructure ou comme des partenaires. Quelqu’un dans le chat a dit : « Si la punition pour l’absence de fiabilité est un délai d’attente, alors l’absence de fiabilité n’est qu’une stratégie avec des étapes en plus. » Personne n’a ri. Parce que tout le monde connaissait un validateur qui réinitialise sa propre horloge de mise à l’écart : il ne transgresse pas les règles. Il joue simplement avec le rythme de l’application des sanctions.
C’est l’écart entre la sécurité technique et la sécurité pratique. Le déclencheur cryptographique du double-signing est absolu, impitoyable, automatique. Le déclencheur social de la négligence est une machine à états avec un bouton de réinitialisation. L’un protège le réseau de la malveillance. L’autre le protège de l’abandon. Et à l’heure actuelle, le bouton de réinitialisation appartient à l’opérateur même qu’il est censé contraindre.
#dusk $DUSK @Dusk $EDEN $AKE