Tout à l’heure, en descendant prendre de la soupe à minuit, j’ai vu l’écran de l’ascenseur s’allumer trop tôt avec “Arrivé”, mais la porte a traîné et n’a fini par s’ouvrir qu’au bout de deux secondes. Ça m’a immédiatement remis en tête un vieux travers d’hier soir : couché dans la salle serveurs à bricoler le débogage des nœuds. À force de passer des années à grimper et tomber dans ce milieu, je garde une méfiance instinctive envers le “transaction réussie” vert côté front-end.
Ces jours-ci, pendant que je faisais tourner des scripts, j’ai relu une fois de plus le livre blanc de Dusk. J’y ai découvert qu’au-delà de leur moteur de confidentialité phare, les détails vraiment hardcore se cachent dans le mécanisme de consensus de Succinct Attestation, notamment cette logique de “finalité glissante” (Rolling Finality).
Le raisonnement est vraiment intéressant. À chaque tour de production de blocs, on désigne d’abord un proposant via un tirage déterministe, puis on doit encore passer deux étapes côté comité : la validation et l’approbation. Les deux étapes exigent d’obtenir les deux tiers des votes valides, et les signatures BLS sont ensuite agrégées pour former la preuve finale. Ça ressemble à tamponner deux fois un dossier de bureau… mais que se passe-t-il si on tombe sur un cas extrême comme un retard réseau ? Dans un même tour, il est tout à fait possible que surgissent des blocs candidats issus d’itérations différentes ; dans ce cas, le nœud doit alors déclencher un repli local en se basant sur ces preuves.
Donc, ne prenez jamais les indications du front-end pour des ordres. Dans l’état interne de base de Dusk, Accepted ne veut dire que : le réseau a bien reçu le message. Attested signifie qu’on a obtenu une preuve initiale. Il faut attendre que les blocs suivants fassent avancer l’état jusqu’à Confirmed, voire que même le bloc parent soit enfin totalement Final — et seulement là, la “facture” est réellement ancrée sur la chaîne, impossible à modifier par qui que ce soit.
C’est aussi pour ça que je me donne toujours du mal à écouter toutes ces chaînes publiques qui ne jurent que par le TPS. Si l’on veut vraiment mettre sur la chaîne des titres financiers de plusieurs centaines de millions d’euros, ce que les institutions redoutent ce n’est pas simplement d’attendre trois ou cinq secondes de plus : c’est le fait que les deux parties se chamaillent sur “la livraison, c’était fait ou pas”. Dusk découpe cette incertitude en états de code bien définis. Les acteurs financiers traditionnels peuvent alors regarder ces marqueurs de bas niveau précis pour décider quand libérer le prêt et quand procéder au transfert, au lieu d’ouvrir une bouteille de champagne aveuglément sur une simple valeur de hachage.
Mais ma règle “sauver d’abord sa peau” ne doit pas être brisée. Même si le protocole de base est parfaitement écrit, au final, tout dépend de savoir si ces institutions dûment agréées accepteront vraiment d’intégrer leurs systèmes métiers essentiels à ces interfaces RPC. Réussir techniquement ne me donne qu’un billet d’entrée ; ça ne signifie pas que je vais sans réfléchir reprendre le risque associé au pari $DUSK .
#dusk #BTC @Dusk $DUSK
Ces jours-ci, pendant que je faisais tourner des scripts, j’ai relu une fois de plus le livre blanc de Dusk. J’y ai découvert qu’au-delà de leur moteur de confidentialité phare, les détails vraiment hardcore se cachent dans le mécanisme de consensus de Succinct Attestation, notamment cette logique de “finalité glissante” (Rolling Finality).
Le raisonnement est vraiment intéressant. À chaque tour de production de blocs, on désigne d’abord un proposant via un tirage déterministe, puis on doit encore passer deux étapes côté comité : la validation et l’approbation. Les deux étapes exigent d’obtenir les deux tiers des votes valides, et les signatures BLS sont ensuite agrégées pour former la preuve finale. Ça ressemble à tamponner deux fois un dossier de bureau… mais que se passe-t-il si on tombe sur un cas extrême comme un retard réseau ? Dans un même tour, il est tout à fait possible que surgissent des blocs candidats issus d’itérations différentes ; dans ce cas, le nœud doit alors déclencher un repli local en se basant sur ces preuves.
Donc, ne prenez jamais les indications du front-end pour des ordres. Dans l’état interne de base de Dusk, Accepted ne veut dire que : le réseau a bien reçu le message. Attested signifie qu’on a obtenu une preuve initiale. Il faut attendre que les blocs suivants fassent avancer l’état jusqu’à Confirmed, voire que même le bloc parent soit enfin totalement Final — et seulement là, la “facture” est réellement ancrée sur la chaîne, impossible à modifier par qui que ce soit.
C’est aussi pour ça que je me donne toujours du mal à écouter toutes ces chaînes publiques qui ne jurent que par le TPS. Si l’on veut vraiment mettre sur la chaîne des titres financiers de plusieurs centaines de millions d’euros, ce que les institutions redoutent ce n’est pas simplement d’attendre trois ou cinq secondes de plus : c’est le fait que les deux parties se chamaillent sur “la livraison, c’était fait ou pas”. Dusk découpe cette incertitude en états de code bien définis. Les acteurs financiers traditionnels peuvent alors regarder ces marqueurs de bas niveau précis pour décider quand libérer le prêt et quand procéder au transfert, au lieu d’ouvrir une bouteille de champagne aveuglément sur une simple valeur de hachage.
Mais ma règle “sauver d’abord sa peau” ne doit pas être brisée. Même si le protocole de base est parfaitement écrit, au final, tout dépend de savoir si ces institutions dûment agréées accepteront vraiment d’intégrer leurs systèmes métiers essentiels à ces interfaces RPC. Réussir techniquement ne me donne qu’un billet d’entrée ; ça ne signifie pas que je vais sans réfléchir reprendre le risque associé au pari $DUSK .
#dusk #BTC @Dusk $DUSK