#dusk $DUSK @Dusk Le 26 août, aujourd’hui, j’ai appris qu’au point de passage de Kuala Lumpur, suite à des glissements de terrain côté Népal, il y avait eu de lourdes pertes humaines et des personnes portées disparues ; la route, les communications et l’électricité ont été interrompues. Je suis assez abattu. Face à la nature, l’être humain est bien fragile : lors d’un choc extrême, tout peut cesser de fonctionner en même temps. Les infrastructures financières, c’est pareil : après une déconnexion, ce n’est qu’une vraie compétence que de pouvoir rétablir la situation. $BNB
J’ai lancé une synchronisation et une recherche d’archivage rapides à partir des données des nœuds de DUSK. Le problème ne vient pas du téléchargement : il réside dans le fait que, une fois la restauration à partir d’une image (snapshot) réussie, Rusk reste à l’arrêt. Il faut l’activer manuellement, puis vérifier si les peers et la hauteur de bloc augmentent. Le plus important : le snapshot ne restaure que l’état, il ne reconstitue pas les index d’archivage antérieurs. Si on le met directement en place pour un nœud d’audit, moonlightHistory et finalizedEvents risquent de ne pas permettre de retrouver l’historique complet. La synchronisation des nœuds ne signifie pas que le grand livre d’audit est intégralement à jour.
Ce design, je l’approuve. DuskDS assure la disponibilité des données et le règlement déterministe ; Rusk conserve l’état de la chaîne et fournit des interfaces HTTP et d’événements. DuskEVM prend le relais pour les applications Solidity ; Hedger fournit une confidentialité vérifiable via le chiffrement homomorphe et des preuves à zéro connaissance. Pour des valeurs mobilières soumises à réglementation, la finalité et la possibilité de restaurer un historique complet sont plus importantes que l’histoire du TPS.
Mais ce qui me préoccupe vraiment, ce sont les scénarios extrêmes : en cas de coupure de courant du data center ou de partition réseau, si le nœud d’archivage n’a jamais pu restaurer un snapshot complet, qui détectera d’abord le manque dans l’historique ? Si l’auditeur ne retrouve pas les anciens événements, faut-il suspendre les transactions ou continuer ? La hauteur de nœud est-elle rattrapée, et peut-on démontrer que l’index l’est aussi ? En cas de catastrophe, le plus grand risque n’est pas l’arrêt : c’est, après la restauration, d’obtenir une réponse normale, mais incomplète.
Le deuxième risque, ce sont les coûts. Un archivage complet exige une synchronisation depuis la genèse ou une restauration à partir d’une sauvegarde fiable ; tout cela coûte : stockage, bande passante, supervision, et personnel. Un plan d’actifs de plus de 300 millions d’euros, avec la collaboration de Chainlink et d’entités autorisées de l’UE, ne peut prouver que l’entrée ; quand la taille du réseau est petite et qu’il y a peu de règlements réels, les particuliers ne pourront peut-être pas capter de la valeur via DUSK.
Je vais surveiller les nœuds d’archivage, les exercices de restauration, le taux d’exhaustivité des requêtes historiques et les émissions réelles. La direction Dusk mérite d’être reconnue, mais dans des environnements extrêmes, le nombre de fois où l’on tient face aux interruptions compte davantage que l’architecture idéale décrite dans le livre blanc. $BTC
J’ai lancé une synchronisation et une recherche d’archivage rapides à partir des données des nœuds de DUSK. Le problème ne vient pas du téléchargement : il réside dans le fait que, une fois la restauration à partir d’une image (snapshot) réussie, Rusk reste à l’arrêt. Il faut l’activer manuellement, puis vérifier si les peers et la hauteur de bloc augmentent. Le plus important : le snapshot ne restaure que l’état, il ne reconstitue pas les index d’archivage antérieurs. Si on le met directement en place pour un nœud d’audit, moonlightHistory et finalizedEvents risquent de ne pas permettre de retrouver l’historique complet. La synchronisation des nœuds ne signifie pas que le grand livre d’audit est intégralement à jour.
Ce design, je l’approuve. DuskDS assure la disponibilité des données et le règlement déterministe ; Rusk conserve l’état de la chaîne et fournit des interfaces HTTP et d’événements. DuskEVM prend le relais pour les applications Solidity ; Hedger fournit une confidentialité vérifiable via le chiffrement homomorphe et des preuves à zéro connaissance. Pour des valeurs mobilières soumises à réglementation, la finalité et la possibilité de restaurer un historique complet sont plus importantes que l’histoire du TPS.
Mais ce qui me préoccupe vraiment, ce sont les scénarios extrêmes : en cas de coupure de courant du data center ou de partition réseau, si le nœud d’archivage n’a jamais pu restaurer un snapshot complet, qui détectera d’abord le manque dans l’historique ? Si l’auditeur ne retrouve pas les anciens événements, faut-il suspendre les transactions ou continuer ? La hauteur de nœud est-elle rattrapée, et peut-on démontrer que l’index l’est aussi ? En cas de catastrophe, le plus grand risque n’est pas l’arrêt : c’est, après la restauration, d’obtenir une réponse normale, mais incomplète.
Le deuxième risque, ce sont les coûts. Un archivage complet exige une synchronisation depuis la genèse ou une restauration à partir d’une sauvegarde fiable ; tout cela coûte : stockage, bande passante, supervision, et personnel. Un plan d’actifs de plus de 300 millions d’euros, avec la collaboration de Chainlink et d’entités autorisées de l’UE, ne peut prouver que l’entrée ; quand la taille du réseau est petite et qu’il y a peu de règlements réels, les particuliers ne pourront peut-être pas capter de la valeur via DUSK.
Je vais surveiller les nœuds d’archivage, les exercices de restauration, le taux d’exhaustivité des requêtes historiques et les émissions réelles. La direction Dusk mérite d’être reconnue, mais dans des environnements extrêmes, le nombre de fois où l’on tient face aux interruptions compte davantage que l’architecture idéale décrite dans le livre blanc. $BTC