IOTAの合意プロトコルを高速化するStarfish-Speedは、2026年9月にメインネットへ導入されました。要点は、条件が整った通常時に、データ可用性を別工程で待つ時間を省き、取引の最終確定を基礎Starfishより1ラウンド早めることです。ただし、常に短縮されるわけではありません。必要な強投票が集まらないときは、耐障害性を重視した従来経路へ戻ります。
この記事の主題は、Starfish-Speedの導入状況と1ラウンド短縮の仕組みです。基礎Starfishと工程を比べ、StrongQC、フォールバック、約15％という試験値の読み方を一般〜技術初心者向けに整理します。末尾には、バリデータ運用者向けの要点だけをチェックリストとしてまとめます。
Starfish-Speedは2026年9月にIOTAメインネットへ導入
IOTA Foundationが2026年10月13日に公開したQ3進捗報告によると、Starfish-Speedは7月にdevnet、8月にtestnet、9月にmainnetという順序で展開されました。いきなり本番ネットワークへ投入したのではなく、環境を段階的に移しながら動作を確かめた形です。Q3報告は「9月に稼働した」という事後確認に当たり、導入を伝える中心資料です。
導入の流れ：
devnetは開発段階の挙動を試す場、testnetは本番に近い条件で更新手順や互換性を確かめる場、mainnetは実際の価値移転を処理する本番環境です。段階導入には、通常経路を壊していないか、異なる版のノードが混在する境界を扱えるか、問題時に期待した経路へ戻れるかを、本番化より前に確認する意味があります。
開発リポジトリには、developブランチへ統合する前にStarfish-Speedと通常経路を試すテスト・エピックも残っています。段階を踏んだ事実は確認できますが、それだけで将来の無障害運用を保証するものではありません。公開された監査の範囲や全指摘が調査資料だけですべて分かるわけでもないため、「本番化済み」と「リスクが消えた」は分けて読む必要があります。
導入済みと判断できる根拠：
稼働状況はブログだけでなく、リリース情報と実装変更からも照合できます。リリース一覧ではv1.32.1にmainnet向けStarfish-Speed有効化が含まれ、プロトコルv36は9月24日以降に有効化可能とされました。さらに、mainnet設定の機能フラグを有効にするプルリクエストが9月18日に記録されています。
IIP一覧では、基礎StarfishとStarfish-SpeedがActiveとして掲載されています。IIPにおけるActiveは、提案だけの段階ではなく、多数のノードが支持し、mainnetでサポートされる段階を示します。公式報告、配布版、設定変更、仕様一覧という異なる記録が同じ導入事実を指しているため、単一の告知だけに依存せず確認できます。
前提となる基礎Starfishのデータ可用性と確定経路
まなぶ「クリプ先生、データ可用性って、データが正しいことと同じなんですか？」
クリプ「少し違うよ。ここでは、検証に必要なデータを参加者が実際に取得できる状態かを確かめる考え方なんだ。」
Starfish-Speedを理解するには、2026年4月に先にmainnetへ入った基礎Starfishの役割を押さえる必要があります。IOTAでは共有オブジェクトを扱う取引がStarfishの合意を通り、その後に並び順が決まります。合意とは、分散したバリデータが、どのデータをどの順序で確定扱いにするかについて共通の判断へ到達する工程です。
基礎StarfishはDAG-BFT型のプロトコルです。DAGは、ブロックや情報が一列だけでなく、複数の参照関係を持つ有向非巡回グラフとしてつながる構造を指します。BFTは、一部の参加者が故障したり不正な応答をしたりしても、安全性と処理継続を目指す設計です。詳しい前提を確認したい場合は、ブロックチェーンの基本構造とPoSとバリデータの役割も参考になります。
ヘッダーとpayloadを分ける理由：
基礎Starfishでは、データ全体であるpayloadと、その要約や参照情報を持つヘッダーを分けて扱います。大きなpayloadを全員が同じ形で一斉に運ぶだけでは、通信が遅い参加者や一部の障害が全体の足かせになりやすいからです。payloadをReed-Solomon方式で断片化し、複数の参加者へ分散させることで、必要な断片からデータを復元できる構成を取ります。
ヘッダーだけを見て内容のすべてを検証できるわけではありません。取引を確定し実行するには、参照されたpayloadが取得可能である必要があります。このため「正しい識別子がある」ことと「中身を取り出せる」ことを分け、後者をデータ可用性として確認します。
DACが可用性を担保する標準経路：
標準経路では、十分な参加者がpayloadの断片を受け取り、復元可能だと確認した証明をDAC（Data Availability Certificate）としてまとめます。DACは、単にデータがどこかに存在するという自己申告ではなく、定められた数の参加者による可用性の裏付けです。並べ替えや確定を急いでも、後から内容を取得できなければ検証や実行が滞るため、DAC待ちは安全な進行に意味があります。
一方で、証明を別工程で待てば、その分だけ確定までのラウンドが増えます。Starfish-Speedが狙うのは、この可用性確認を省略することではありません。通常時にすでに投票の中から同等の情報を得られるなら、別のDAC完成を重ねて待たない、という重複待ちの削減です。
基礎Starfishのトレードオフ：
基礎Starfishは、低速な通信やビザンチン的な振る舞いがある環境でも処理継続を目指し、最悪時のpayload通信量を線形に抑える設計です。その代わり、データ可用性を確実にしてから並べるため、楽観的にすべてが順調な状況では確定に1ラウンド余分にかかります。この「堅牢な標準経路は残しつつ、条件の良いときだけ短い経路を使う」という関係がSpeed版の核心です。
強投票とStrongQCが最終確定を1ラウンド短縮する仕組み
まなぶ「強投票って、普通の投票より賛成の気持ちが強いという意味ですか？」
クリプ「気持ちの強さではないよ。対象のpayloadと参照先のpayloadを保持していることまで表明する、情報量の多い投票なんだ。」
Starfish-Speedでは、バリデータの投票にデータ保持の表明を持たせます。投票者は、対象となるリーダーのpayloadだけでなく、そこから参照されるpayloadも保持していることを示します。この要件を満たす投票が強投票（strong vote）です。
強投票が証明するもの：
通常の賛否だけでは、投票した参加者が後続処理に必要なデータを持っているかは分かりません。強投票は、投票とデータ保持を結び付けます。これにより、十分な強投票が集まったとき、参照payloadも復元・取得可能だと判断する材料が同じラウンド内にそろいます。
ここで重要なのは、強投票が一人のバリデータの宣言ではないことです。分散合意では、単独の参加者が故障または不正である可能性を前提にします。そのため、安全性を判断するには、プロトコルで定めた閾値を超える集合からの投票が必要です。
2f+1の強投票で成立するStrongQC：
想定する障害バリデータ数をfとすると、2f+1の強投票が集まった証明をStrongQCと呼びます。QCはQuorum Certificate、つまり定足数の証明です。2f+1という閾値は、許容範囲内の故障参加者だけでは証明を作れず、正しく動く参加者の情報を含むようにするための境界です。
StrongQCが成立すると、リーダーpayloadだけでなく参照payloadの可用性も強投票の集合によって裏付けられます。この時点で、同じ可用性を確認するための別のDACを待つ必要がなくなります。名称に「Strong」と付いていても、暗号が強くなるという意味ではなく、投票が表明する条件が増え、その定足数証明が成立したという意味です。
楽観経路で省ける待機：
ネットワークが順調で、バリデータが必要なpayloadを受け取り、2f+1の強投票が時間内に集まると、処理は楽観的シーケンスへ進みます。参照payloadを別DACの完成後に並べるのではなく、StrongQCを根拠に先へ進めるため、基礎Starfishより最終確定が1ラウンド短くなります。
「楽観的」は根拠なく安全性を期待する意味ではありません。通信とデータ配布が良好という条件を満たすときにだけ短い経路を採用し、条件の成立をStrongQCで確認する方式です。つまり、速さは条件付きであり、条件確認そのものを飛ばしてはいません。
| 工程 | 基礎Starfish | Starfish-Speedの楽観経路 |
|---|---|---|
| 1. payload配布 | 断片を参加者へ配る | 同じく必要なpayloadを配る |
| 2. 投票 | 通常の投票を集める | payload保持も表明する強投票を集める |
| 3. 可用性証明 | 別工程でDACの成立を待つ | 2f+1の強投票によるStrongQCを使うため、別のDAC待ちを省ける |
| 4. 確定 | 可用性確認後に進む | 条件成立時は1ラウンド早く進む |
| 条件不成立時 | 標準経路を継続 | 標準経路へ分岐し、DACを待つ |
消えるのはデータ可用性の確認そのものではなく、同じ可用性を別の証明で待ち直す工程です。payload配布、定足数による裏付け、確定条件は残ります。この比較で「何を省き、何を省かないか」を区別できます。
楽観条件を満たさない場合は標準経路へフォールバック
StrongQCが成立しない場合、Starfish-Speedは停止したり、少ない投票のまま強引に確定したりする設計ではありません。基礎Starfishが用いる標準経路へフォールバックし、DACによる可用性確認を待ちます。高速経路を追加しても、障害時のより慎重な経路を削除しない点が重要です。
仕様内部には楽観・標準・保留に対応する状態名がありますが、本文を読むうえでは「StrongQCが成立すれば短い経路、まだ条件がそろわなければ待機、不成立なら標準経路」という分岐を押さえれば十分です。Speed版が有効でも、常に高速モードへ固定されるわけではありません。
StrongQCが成立しない場合：
強投票が必要数に達しない理由としては、通信遅延、payloadの配布遅れ、参加者の一時的な停止、不正または非協調的な応答などが考えられます。その場合はDACを使う標準の可用性確認へ戻り、必要な証明をそろえてから進めます。短縮分が得られない代わりに、確定条件を緩めない選択です。
この関係から、「Starfish-Speed導入後は常に1ラウンド短縮」と書くのは正確ではありません。正しくは、StrongQCが成立する楽観条件下で1ラウンド短縮し、成立しないときは基礎Starfish経路を使います。利用者が見る実効遅延は、どの経路がどれだけ使われたかにも左右されます。
低速・障害環境では継続性を優先：
基礎Starfishは、遅いネットワークや一部のビザンチン参加者がいる状況での生存性を重視します。生存性とは、いつまでも止まったままにならず、条件が回復すれば処理が進む性質です。Starfish-Speedは、その土台に通常時の短い経路を足したもので、障害環境を高速経路だけで処理しようとするものではありません。
したがって評価の焦点は、最速値だけでは足りません。平常時にopt経路が使われる割合、遅延時にstdへ正しく移れるか、回復後に処理が追いつくか、異なる版の参加者を境界で排除できるか、といった一連の挙動を見る必要があります。
約15％短縮という試験結果をどう読むか
IIP-12には、19台のバリデータを使った試験で、取引確定時間の中央値（p50）が約206ミリ秒から約174ミリ秒へ短くなった結果が示されています。差は約32ミリ秒で、比率では約15％の短縮です。これはStarfish-Speedの仕組みが管理された環境で期待どおりに働くことを示す材料ですが、mainnet全体にその比率をそのまま当てはめることはできません。
p50の意味：
p50は、観測値を小さい順に並べた中央の値です。平均値とは異なり、一部の極端に遅い結果の影響を受けにくい一方、遅い側の分布を詳しく示す指標でもありません。p50が短くなったからといって、すべての取引が174ミリ秒前後で確定したとは言えず、最も遅いケースが同じ割合で改善したとも限りません。
また、19バリデータという構成は、結果を比較するための試験条件です。mainnetの参加者配置、回線品質、ハードウェア、負荷、地域間距離が同じとは限りません。この数値は仕様に沿った効果を確認するベンチマークとして読み、利用者の体感時間を保証するサービス水準とは区別します。
実環境で数値が変わる要因：
実効遅延は、payloadの大きさ、同時取引量、バリデータ間の往復時間、パケット損失、CPUやストレージの余裕などで変わります。地理的に近い管理環境では強投票が早く集まっても、広域分散したmainnetでは同じ時間にならない可能性があります。逆に、運用改善や回線構成によって試験値と異なる良好な結果になることもあり得ます。
障害時にはフォールバックが使われるため、楽観経路の短縮分が出ない場面もあります。この挙動は設計上の失敗ではなく、安全側の経路が働いた結果です。性能を見る際は単一の中央値だけでなく、遅い側の分布、フォールバック率、障害からの回復時間を合わせて観測する必要があります。
約15％を恒常値と断定できない理由：
約15％という値は、IOTA側の仕様・実装資料に記載された限定条件の測定です。独立した長期運用評価ではなく、mainnetで常時再現されるとの保証もありません。さらに、同時期にはリーダー日程、同期、snapshot、接続監視など複数の変更が進んでいます。mainnet指標が改善しても、その全量をStarfish-Speedだけの効果とみなすことはできません。
数値を記事や運用判断で使う場合は、「19バリデータ試験」「p50」「約206msから約174ms」「約15％」という条件を一緒に記すべきです。「IOTAが15％高速化した」と対象や条件を省くと、スループット、画面応答、すべての確定時間が一律に改善したような誤解を招きます。
同時期の変更がmainnet性能の評価を難しくする
Q3にはStarfish-Speed以外の変更も行われました。合意の速さを観測する周辺には、どのリーダーを選ぶか、ノードが過去状態へ追いつく速さ、peerからcommitを取得する受付制御、snapshotの作成・復元などが関係します。観測値の前後比較では、変更点を一つずつ切り分ける必要があります。
代表的な同時変更：
mainnetでは同時期に、スライド窓の評判評価と絶対スコアを用いる再設計リーダー日程も有効化されました。不良または性能の低いノードをリーダー選択で扱う方法が変われば、確定遅延の分布へ影響する可能性があります。そのため、導入後の改善をすべてStrongQCによる1ラウンド短縮だけへ帰属させるのは慎重さを欠きます。
評価するなら、Starfish-Speedの機能フラグ、リーダー日程の版、委員会構成、各epochのネットワーク状態を記録し、条件の異なる期間を混ぜないことが大切です。
同期・peer受付・snapshot：
Q3報告では同期の2.6倍という改善や正式snapshotへの移行も挙げられています。ただし、これはStarfish-Speedの約15％試験値とは別の対象です。同期は、遅れたノードや新規ノードが既存の状態へ追いつく処理であり、通常の取引が合意で最終確定する時間と同じではありません。
peer受付やstate snapshotにも復旧性・追従性を高める変更がありましたが、StrongQC成立そのものとは別層です。
合意層と照会系を分ける：
Indexerは、確定済みデータをPostgreSQLなどへ整理し、アプリケーションが検索・照会しやすくする仕組みです。Indexerの復元や保持期間が改善すると、ウォレットやサービスの表示が速く安定する可能性があります。しかし、画面へ履歴が表示される時刻は、合意確定時刻と同一ではありません。
利用者の体感を分解すると、取引送信、バリデータへの伝播、合意確定、checkpointや同期、Indexer取り込み、API応答、画面反映という複数段階があります。Starfish-Speedが直接短縮するのは合意経路です。アプリ全体が遅い場合は、どの段階に時間がかかっているかを測らなければ原因を特定できません。
バリデータ更新で注意すべき非互換性と有効化境界
まなぶ「クリプ先生、機能フラグなら、各ノードが好きな時にオンにしても大丈夫ですか？」
クリプ「合意規則は足並みが重要だよ。決められたアップグレード境界で原子的に切り替え、違う版のデータを受け入れないようにするんだ。」
Starfish-Speedは内部処理だけを速くする、完全に後方互換な調整ではありません。IIP-12はBlockHeaderV2とCommit V3を伴い、基礎Starfishとはワイヤ形式と線形化のレベルで非互換としています。バリデータ運用者は、対応バイナリを入れただけでなく、対象ネットワークの有効化可能epochとプロトコル版を確認する必要があります。
BlockHeaderV2とCommit V3の非互換性：
BlockHeaderV2は、強投票や新しい処理に必要な情報を扱うヘッダー形式です。Commit V3は確定結果を表す形式の更新です。古いノードが新形式を知らない、または新ノードが古い形式を新ルールとして受け入れると、参加者間で有効性判断がずれるおそれがあります。
非互換性は、過去の取引が消えるという意味ではありません。切替境界後に生成・交換するblockやcommitについて、同じ規則と形式を使う必要があるという意味です。一般利用者は自分で形式を選ばなくても、利用するRPC、ウォレット、取引所が追従したノードへ接続しているかの影響を受けます。
アップグレード境界での原子的な切替：
実装ではStarfish-Speedを機能フラグで制御し、プロトコルアップグレードの境界で原子的に切り替えます。「原子的」とは、関連する規則の一部だけを中途半端に適用せず、一つの境界で一まとまりとして新状態へ移ることです。版と一致しないblockやcommitは拒否し、異なる合意規則が曖昧に混在することを避けます。
プロトコル更新にはバリデータの超多数による合意が必要で、単一の運営者が全ネットワークを任意の時刻に切り替えるわけではありません。運用者は、リリースノート、設定ソース、対象epochの案内を照合し、ステージング環境で起動・同期・投票・commit生成まで確認してから本番へ反映します。
未更新ノードへの影響：
更新しないバリデータは、新形式を処理できず委員会の有効な参加者として動けなくなる可能性があります。リリース情報では、更新遅れが委員会からの離脱や報酬喪失につながり得る点が示されています。報酬への具体的影響は参加状況やネットワーク規則によるため、一律の損失額をこの記事から計算することはできません。
安全な更新では、バイナリの版、設定、データバックアップ、復旧手順、監視アラート、担当者連絡を事前にそろえます。アップグレード時刻だけを見るのではなく、その前に同期遅れがないか、切替後に期待するプロトコル版を広告しているか、投票とcommitが継続しているかを確認する必要があります。分岐を伴う更新の一般的な考え方はハードフォークとソフトフォークの違いでも整理しています。
導入後にノード運用者が確認したい監視項目
アップグレードが完了したかは、プロセスが起動しているだけでは判断できません。外部peerと接続し、正しい版で同期し、合意に参加し、必要なデータを取得・提供できて初めて運用が成立します。Starfish-Speed導入後は、合意指標と周辺サービス指標を分けて監視します。
接続の確認：
2026年10月の実装変更では、JSON-RPCとvalidator gRPCのlistenerへ、接続数、接続寿命、TLSハンドシェイクなどの指標が追加されました。接続数の急減はpeer到達性や設定ミス、短命接続の増加は再接続ループ、TLS失敗は証明書や時刻、互換設定の問題を疑う手掛かりになります。
単一の瞬間値だけで異常と決めず、更新前の平常値と比較することが大切です。合意遅延が伸びたときに、同じ時間帯の接続数、TLS失敗、CPU、メモリ、ディスクI/O、ネットワーク遅延を並べれば、StrongQCが集まりにくい原因を絞り込みやすくなります。
同期と復旧の確認：
遅れたノードが最新状態へ追いつけるか、正式state snapshotから復元できるかも確認対象です。平常時にcommitを処理できても、再起動や障害復旧で追従できなければ可用性は下がります。復元テストでは、snapshotの取得元、完全性、復元に要した時間、復元後のチェックポイント、最新高へ到達するまでのログを残します。
peer受付の修正は、一部相手が枠を占有しても他peerの最初のcommit取得を妨げにくくするものです。運用では、接続数が多いだけで健全と判断せず、複数peerから実際にデータを取得できているか、特定peerへの依存がないか、同期停止後に自動回復するかまで試します。
層を分けた監視：
確認項目は、合意層ではラウンド時間、StrongQC成立、フォールバック、投票参加、commit生成を見ます。同期層では最新高との差、commit取得、snapshot復元を見ます。照会層ではIndexerの取り込み遅延、PostgreSQL、RPC応答、保持期間を見ます。層ごとの時刻を同じ取引IDで追跡すると、遅延の発生場所を区別できます。
| 層 | 主な確認項目 | 混同しやすい点 |
|---|---|---|
| 合意 | StrongQC、ラウンド、commit | 画面表示の速さと同じではない |
| 接続・同期 | peer、TLS、最新高、snapshot | 取引確定そのものではない |
| Indexer・API | 取り込み差、DB、RPC応答 | 台帳が未確定とは限らない |
運用者向けの最小チェックリストは、①対応版と有効化epoch、②同期高と投票・commitの継続、③peer接続とTLS失敗、④snapshotからの復元、⑤合意とIndexerの遅延の切り分けです。アラートを層ごとに分けると、「合意は正常だがIndexerが遅い」「接続障害で標準経路が増えた」と原因を判断しやすくなります。
Starfish-Speedを評価する際の結論と留意点
- 何が変わったか：2026年9月にmainnetへ導入され、可用性を別工程で待ち直す時間を省けるようになりました。
- 条件は何か：2f+1の強投票でStrongQCが成立したときだけ1ラウンド短縮し、不成立時はDACを使う標準経路へ戻ります。
- 数字をどう読むか：約15％は19バリデータ試験のp50が約206msから約174msになった値で、mainnetの保証値ではありません。独立した長期評価もまだ限定的です。
- 運用者は何を見るか：対応版と切替境界を確認し、合意、接続・同期、Indexerを分けて監視します。
本番化は無事故や全リスクの解消を意味しません。運用者は最新リリースと対象コミットを確認してください。また、確定時間の改善だけでIOTAトークンの価格や収益は判断できません。読者が見るべき基準は、最速値ではなく、条件成立率、遅い側の分布、標準経路への安全な移行、障害後の回復です。
