Auparavant, pour mieux voir le “vrai visage” sous le capot de certaines blockchains, j’ai eu le courage de louer un serveur “bare metal” haut de gamme avec double EPYC et 2 To de RAM, afin d’exécuter un nœud complet. Résultat : un jour, au milieu de la nuit, l’interface RPC s’est mise à renvoyer des erreurs d’un coup et m’a déconnecté pendant plusieurs heures. Le lendemain, en regardant le panneau de contrôle, j’ai constaté que j’avais raté plusieurs rounds de production de blocs à la perfection.
En tant que personne qui a gravé dans le cerveau le principe “priorité à la survie”, cet incident m’a complètement ouvert les yeux : jouer une consensus PoS, ce n’est vraiment pas juste “mettre des tokens en staking et se reposer pour toucher des loyers”. Si les nœuds des particuliers se mettent en grève, ça veut simplement dire gagner un peu moins de coins ; mais si, sur cette chaîne, on exécute de vrais actifs financiers conformes, alors si le nœud ne parvient pas à confirmer les transactions pendant longtemps, toute la suite du processus de compensation et de distribution des dividendes reste bloquée, et tout le monde fixe le vide.
Du coup, il faut que je parle du réseau Dusk sur lequel je me suis récemment acharné en fouillant le code. En parcourant sa conception de base autour du “Succinct Attestation”, force est de constater que cette approche a vraiment quelque chose. Les nœuds qui participent au staking s’appellent des provisioners, et, à chaque tour, ils sont sélectionnés directement comme proposants et comité de vote via un algorithme déterministe. Ça ne repose pas sur des nœuds centralisés qui donnent des ordres, mais sur une communication ultra “geek” pour verrouiller le bloc.
Beaucoup de débutants pensent que la “finalité (Finality)” est juste un mot académique un peu prétentieux. Dit simplement, c’est : quand vous voyez dans votre portefeuille que le transfert a réussi, est-ce que cette opération peut réellement être considérée comme définitivement “clos” ? Si c’est une blockchain où des réorganisations de blocs sont fréquentes, même les exchanges n’osent pas créditer vos fonds en un temps record. Puisque Dusk s’accroche à l’idée de viser les applications financières régulées, ce qu’il lui faut n’est pas seulement un TPS qui fait joli lors d’un pump occasionnel, mais un mécanisme de confirmation solide, stable comme le roc.
Et en plus, sa couche de base utilise le protocole Kadcast pour transmettre les messages : les nœuds ne font passer les données qu’à des voisins précis, sans jamais envoyer une rafale généralisée sur tout le réseau. Cela évite la congestion et brouille aussi, au passage, l’origine des messages.
Après avoir bricolé dans ce milieu pendant un moment, pour savoir si une chaîne tient la route, je ne pose qu’une seule question : quand le réseau subit de fortes secousses, avec une partie des nœuds hors ligne, est-ce que ce système peut encore assurer une remise de service et une production de blocs fiables, sans broncher ? Les infrastructures financières vraiment “hardcore” ne consistent pas à exiger que chaque serveur ne fasse jamais d’erreur ; elles consistent à ce que, quand quelqu’un rame, le grand livre avance quand même, à l’heure. L’architecture de Dusk, c’est une façon de traiter ce point douloureux.
@Dusk_Foundation #dusk $DUSK
En tant que personne qui a gravé dans le cerveau le principe “priorité à la survie”, cet incident m’a complètement ouvert les yeux : jouer une consensus PoS, ce n’est vraiment pas juste “mettre des tokens en staking et se reposer pour toucher des loyers”. Si les nœuds des particuliers se mettent en grève, ça veut simplement dire gagner un peu moins de coins ; mais si, sur cette chaîne, on exécute de vrais actifs financiers conformes, alors si le nœud ne parvient pas à confirmer les transactions pendant longtemps, toute la suite du processus de compensation et de distribution des dividendes reste bloquée, et tout le monde fixe le vide.
Du coup, il faut que je parle du réseau Dusk sur lequel je me suis récemment acharné en fouillant le code. En parcourant sa conception de base autour du “Succinct Attestation”, force est de constater que cette approche a vraiment quelque chose. Les nœuds qui participent au staking s’appellent des provisioners, et, à chaque tour, ils sont sélectionnés directement comme proposants et comité de vote via un algorithme déterministe. Ça ne repose pas sur des nœuds centralisés qui donnent des ordres, mais sur une communication ultra “geek” pour verrouiller le bloc.
Beaucoup de débutants pensent que la “finalité (Finality)” est juste un mot académique un peu prétentieux. Dit simplement, c’est : quand vous voyez dans votre portefeuille que le transfert a réussi, est-ce que cette opération peut réellement être considérée comme définitivement “clos” ? Si c’est une blockchain où des réorganisations de blocs sont fréquentes, même les exchanges n’osent pas créditer vos fonds en un temps record. Puisque Dusk s’accroche à l’idée de viser les applications financières régulées, ce qu’il lui faut n’est pas seulement un TPS qui fait joli lors d’un pump occasionnel, mais un mécanisme de confirmation solide, stable comme le roc.
Et en plus, sa couche de base utilise le protocole Kadcast pour transmettre les messages : les nœuds ne font passer les données qu’à des voisins précis, sans jamais envoyer une rafale généralisée sur tout le réseau. Cela évite la congestion et brouille aussi, au passage, l’origine des messages.
Après avoir bricolé dans ce milieu pendant un moment, pour savoir si une chaîne tient la route, je ne pose qu’une seule question : quand le réseau subit de fortes secousses, avec une partie des nœuds hors ligne, est-ce que ce système peut encore assurer une remise de service et une production de blocs fiables, sans broncher ? Les infrastructures financières vraiment “hardcore” ne consistent pas à exiger que chaque serveur ne fasse jamais d’erreur ; elles consistent à ce que, quand quelqu’un rame, le grand livre avance quand même, à l’heure. L’architecture de Dusk, c’est une façon de traiter ce point douloureux.
@Dusk_Foundation #dusk $DUSK