À l'intérieur de Starfish : la consensus basée sur la poussée d'IOTA expliquée

• Publicité -

• Le Starfish d’IOTA envoie des données clés en avance, aidant les validateurs à éviter de longues attentes pour les blocs manquants lorsque le réseau est sous pression.

• IOTA utilise un codage Reed-Solomon et des vérifications DAG pour récupérer les charges utiles sans transmettre toutes les données de transaction à chaque validateur.

IOTA a intégré le consensus Starfish sur le Mainnet via la version v1.21.1 et la version du protocole 24. La mise à niveau offre au réseau une nouvelle conception de consensus adaptée aux conditions réelles, où les validateurs doivent faire avancer les données même lorsque les nœuds ralentissent, que les messages arrivent en retard ou que certains participants se comportent de manière incorrecte.

Le consensus se concentre généralement sur l’accord. Les validateurs doivent s’accorder sur le même historique, même sous pression. Cependant, Starfish considère la synchronisation comme faisant partie du même problème. Un validateur ne peut pas voter pour un bloc qu’il n’a pas vu. Il ne peut pas non plus certifier des données de transaction qu’il ne peut pas reconstruire. Pour cette raison, Starfish place le mouvement des données dans le protocole plutôt que de le laisser comme une tâche réseau séparée.

“Le mouvement honnête est d’aider le réseau à progresser.”

Starfish est en ligne sur le Mainnet d’IOTA – et @NaitsabesMue de notre équipe de recherche explique les décisions techniques de conception, les compromis, et ce que montrent les données sur le blog d’IOTA. pic.twitter.com/78f0x5f8wz

— IOTA (@iota) 7 mai 2026

Le graphe acyclique dirigé (DAG) d’IOTA enregistre comment les blocs se réfèrent à des blocs antérieurs. Ces liens montrent ce que les validateurs ont déjà vu et où le réseau a encore des lacunes. Lorsque des références apparaissent chez plusieurs validateurs, le réseau montre une connaissance partagée, et lorsqu’elles disparaissent, la structure révèle où la synchronisation a échoué.

Le modèle de consensus Mysticeti d’IOTA, plus ancien, reposait davantage sur un comportement de tirage. Dans cette configuration, un validateur demandait à ses pairs les blocs manquants après avoir détecté une lacune. Le tirage économise de la bande passante en conditions calmes mais ajoute de la latence lorsque le réseau est sous stress. Chaque élément manquant crée une nouvelle demande, une nouvelle attente, et une étape de récupération supplémentaire.

IOTA a activé sa mise à niveau de consensus Starfish sur le mainnet dans le cadre de sa volonté de soutenir une infrastructure commerciale réelle liée à un marché mondial de 35 trillions de dollars. La mise à niveau aide le réseau à rester résilient lorsque certains nœuds accusent du retard ou se déconnectent.

Starfish d’IOTA utilise le push pour réduire les délais de récupération

Starfish modifie ce schéma avec une approche basée sur le push. Les validateurs font avancer des informations utiles avant que d’autres ne les demandent. Cela donne aux nœuds en retard les données dont ils ont probablement besoin avant que le problème d’historique manquant n’atteigne le chemin critique. Le graphe de requête sortante d’IOTA montre clairement ce changement, avec Starfish réduisant les demandes de tirage d’environ un ordre de grandeur par rapport à Mysticeti.

Taux de requêtes sortantes | Mysticeti vs Starfish | Source : Blog d’IOTA

Ce design ne pousse pas tout en entier. Starfish sépare les métadonnées des charges utiles de transaction. Les en-têtes portent des références, des votes, des accusés de réception, des détails de synchronisation, et des engagements de charge utile. Les données de transaction se déplacent séparément. Cela maintient le chemin de consensus plus léger tout en fournissant aux validateurs suffisamment d’informations pour garder le DAG en bonne santé.

Le codage Reed-Solomon supporte cette structure. Starfish divise la charge utile de transaction d’un bloc en fragments, avec un fragment attribué à chaque validateur. La charge utile originale peut être reconstruite à partir de n’importe quel sous-ensemble suffisant de fragments valides. Dans Starfish, n’importe f+1 fragments valides peuvent reconstruire la charge utile, tandis que 2f+1 accusés de réception créent la condition de disponibilité nécessaire pour la sécurité sous des hypothèses byzantines.

Par conséquent, Starfish ne nécessite pas que chaque validateur détienne la charge utile complète en même temps. Au lieu de cela, il prouve que suffisamment de pièces vérifiées existent chez des validateurs honnêtes pour reconstruire les données. À mesure que le DAG se développe, les blocs ultérieurs portent la preuve que les charges utiles antérieures restent récupérables.

Les données de performance expliquent pourquoi IOTA a accepté ce compromis. Starfish utilise plus de bande passante que Mysticeti pendant la période de test, mais la communication supplémentaire se produit plus tôt et suit un chemin structuré. Au lieu d’attendre que les validateurs demandent des données manquantes, le protocole envoie des informations utiles à l’avance, ce qui réduit les coûts de récupération ultérieurement et aide le réseau à rester aligné sous pression.

Bande passante : Mysticeti vs Starfish | Source : Blog d’IOTA

Le tableau de performance concerne aussi la variance. Starfish ajoute une étape de disponibilité avant la séquence, ce qui peut légèrement augmenter la latence des transactions ordinaires. Cependant, les cas plus lents s’améliorent, et le réseau passe moins de temps à récupérer des informations manquantes.