Le jalon 4a de @ShieldedLabs Crosslink a été réalisé : - correction de 2 bugs majeurs de ms3 - UX beaucoup plus facile, ~x3 participants sur la liste BFT - notre BFT sur mesure s'est avéré plus stable que l'ancien sdk - nous avons rencontré un échec de sécurité BFT dû à un écart de conception connu (pas un bug BFT) Accrochez-vous : 🧵

@ShieldedLabs En raison d'un décalage d'architecture de code entre un délai de synchronisation PoW et une faible difficulté des mineurs, notre réseau a connu de fréquentes longues divisions PoW. Plutôt que d'essayer de corriger cela avant l'atelier, nous avons mis l'accent sur l'amélioration de notre nouveau BFT, UX et visualiseur. Pourquoi ? …

@ShieldedLabs Pourquoi ne pas corriger le problème évident connu ? Parce que nous priorisons la résilience du protocole de test, les fonctionnalités de diagnostic et l'expérience utilisateur. C'est en fait un défaut parfait à conserver tout en prouvant la résilience BFT, l'utilité du visualiseur et les techniques de diagnostic.

@ShieldedLabs Le décalage d'architecture du code a essentiellement simulé un réseau "fortement partitionné", comme si les connexions Internet entre les mineurs et les nœuds BFT échouaient fréquemment, puis se réparaient occasionnellement. Cela a démontré la résilience de Crosslink, et cela s'est beaucoup mieux passé que je ne l'avais prévu.

@ShieldedLabs J'ai pris une capture d'écran de ce à quoi ressemblent de très longs forks PoW dans la structure Crosslink. Ici, vous voyez que bien qu'il y ait de très longs forks PoW, les attestations Crosslink sont cohérentes : elles ne sautent pas à travers les forks ; c'est-à-dire que la sécurité de finalité est préservée.

@ShieldedLabs Il y a eu une violation de sécurité en raison d'un écart d'implémentation connu : Zebra a une "finalité YOLO" de 100 blocs de style Bitcoin et nous n'avons pas encore garanti que la finalité BFT est suprême. Ajoutez une forte partition et nous atteignons la violation de sécurité après que certains nœuds étaient >100 blocs PoW hors synchronisation.

@ShieldedLabs D'accord, donc c'est une lacune de sécurité connue, dommage, réparons cela, n'est-ce pas ? Oui, mais il y avait un grand point positif. Nous aurions pu simplement dire "ok, bug enregistré, revenez la prochaine fois". Au lieu de cela : …

Nous avons improvisé une récupération de stall BFT en direct ! Nous avons pu redémarrer des nœuds BFT désynchronisés et reprendre le BFT (avec la liste inchangée) sans perturber le PoW, ce qui était une validation en direct d'un pilier de Crosslink : La sécurité est aussi forte que l'un ou l'autre sous-protocole : l'échec du BFT n'a pas déraillé le PoW.

Pour être clair, ce n'était pas un redémarrage BFT réaliste. Nous avons compté sur la nature éphémère actuelle de l'état BFT pour oublier les signatures conflictuelles. Cela dit, c'était un développement totalement improvisé et inattendu de l'atelier. Bonus XP pour ce processus général d'opérations et la validation Crosslink.

@ShieldedLabs Après cela (fin de MS5), nous passerons la majeure partie de 2026 à *réimplémenter* un nœud durci, prêt pour la production, en utilisant tous nos apprentissages en matière de conception et d'implémentation durant cette phase de prototype. 2026 = le parcours de la rigueur ! Qu'on se le dise. Les boucliers de fusée se lèvent ! 🚀🛡️