IOTAは、v1.21.1リリースとプロトコルバージョン24を通じてStarfishコンセンサスをメインネットに移行しました。このアップグレードにより、検証者がノードの遅延、メッセージの遅延、または一部の参加者の不正行為があってもデータを動かし続ける必要がある現実の条件に適した新しいコンセンサス設計がネットワークに導入されました。

コンセンサスは通常、合意を中心としています。検証者はプレッシャー下でも同じ履歴に同意しなければなりません。しかし、Starfishは同期を同じ問題の一部とみなします。検証者は見ていないブロックに投票できません。また、再構築できない取引データを証明することもできません。そのため、Starfishはデータの移動をプロトコル内に組み込み、別個のネットワークタスクとして残しません。

「正直な行動はネットワークの進展を助けることです。」

StarfishはIOTAメインネットで稼働中です – そして私たちのリサーチチームの@NaitsabesMueが、技術的な設計決定、トレードオフ、そしてIOTAブログで示されるデータについて解説します。pic.twitter.com/78f0x5f8wz

— IOTA (@iota) 2026年5月7日

IOTAの有向非巡回グラフ（DAG）は、ブロックがどのように以前のブロックを参照しているかを記録します。これらのリンクは、検証者がすでに見たものと、ネットワークにまだギャップがある部分を示します。多くの検証者間で参照が現れると、共有された知識を示し、参照が失われると、同期の失敗箇所を明らかにします。

IOTAの以前のMysticetiコンセンサスモデルは、よりプル動作に依存していました。その仕組みでは、検証者はギャップを検出した後、ピアに欠落したブロックを要求しました。プルは静かな状態では帯域幅を節約しますが、ネットワークがストレス下にあると遅延を増加させます。欠落した項目ごとにリクエストと待機、回復のステップが増えます。

IOTAは、実世界の貿易インフラに結びついた3,500兆ドルのグローバル市場に対応するための推進の一環として、メインネットでStarfishコンセンサスのアップグレードを有効化しました。このアップグレードは、一部のノードが遅延または切断された場合でもネットワークの耐性を維持します。

IOTAのStarfishはプッシュを利用して回復遅延を短縮

Starfishは、そのパターンをプッシュベースのアプローチに変更します。検証者は、他者が要求する前に有用な情報を前倒しで送信します。これにより、遅れているノードは、重要な履歴の問題がクリティカルパスに達する前に必要なデータを受け取ることができます。IOTAのアウトバウンドリクエストグラフは、この変化を明確に示しており、StarfishはMysticetiと比較してプルリクエストを約一桁削減しています。

アウトバウンドリクエスト率 | Mysticeti対Starfish | 出典：IOTAブログ

この設計はすべてを完全にプッシュするわけではありません。Starfishはメタデータと取引ペイロードを分離します。ヘッダーには参照、投票、確認、タイミングの詳細、ペイロードのコミットメントが含まれます。取引データは別途移動します。これにより、コンセンサスの経路は軽量になりつつも、検証者に十分な情報を提供してDAGの健全性を保ちます。

リード・ソロモン符号化は、その構造をサポートします。Starfishはブロックの取引ペイロードを断片に分割し、各検証者に1つの断片を割り当てます。元のペイロードは、有効な断片の十分な部分集合から再構築可能です。Starfishでは、f+1の有効断片がペイロードを再構築でき、2f+1の確認はバイザンチン仮定下で安全性に必要な可用性条件を満たします。

したがって、Starfishはすべての検証者が同時に完全なペイロードを保持する必要はありません。代わりに、正直な検証者間で十分な検証済みの断片が存在し、データを再構築できることを証明します。DAGが成長するにつれて、後続のブロックは、以前のペイロードが回復可能である証拠を持ちます。

パフォーマンスデータは、なぜIOTAがそのトレードオフを受け入れたのかを説明します。Starfishはテスト期間中、Mysticetiよりも多くの帯域幅を使用しますが、その追加通信は早期に行われ、構造化された経路に従います。欠落したデータを検証者に要求させるのではなく、プロトコルは有用な情報を事前に送信し、後の回復コストを低減し、圧力下でもネットワークの整合性を維持します。