2〜4倍速いのはEthereumのブロック時間ではなく、ブロックがノードへ届く伝播経路です。Optimumは2026年10月20日、RLNCを使う補助網mump2pが、16のノード事業者と約2万2,000のバリデータを接続してメインネット稼働したと発表しました。標準通信を置き換える変更ではありません。
一般のETH保有者に設定変更や送金は不要です。一方、バリデータ運営者には到着の速さと安定性を自環境で評価する余地があります。ただし平均2〜4倍などの主要な本番数値は開発元発表で、測定期間や標本、比較条件の全容は未公表です。本記事は前半で一般読者向けに意味と仕組みを整理し、後半の「運営者向け」から導入判断を扱います。
Optimumのmump2pがEthereumメインネットで稼働
Optimumは2026年10月20日、mump2pをEthereumメインネットで稼働したと発表しました。mump2pは、Ethereumの合意層で扱われるブロックなどのデータを、既存の経路とは別の経路でも運ぶネットワークです。ここでいうメインネット稼働は、Ethereumの合意規則そのものが変更されたという意味ではありません。バリデータ運営者が追加ソフトウェアを接続し、標準網と並行してデータを受け渡す運用が本番環境で始まった、という位置づけです。
Ethereumでは、取引の実行を担う実行層と、バリデータがブロックや投票を共有して合意を形成する合意層が連携します。mump2pが主に関わるのは、合意クライアントがネットワーク越しにメッセージを受け取る部分です。利用者がETHを送る画面や、ウォレットの秘密鍵管理を置き換える製品ではありません。
16事業者・約2.2万バリデータが接続
発表によると、稼働開始時点では16のノード事業者が参加し、約2万2,000バリデータがmump2pに接続しました。接続規模は、研究用の少数ノードだけではなく、実際のステーキング事業者を含む本番運用へ進んだことを示します。一方で「約2万2,000」はEthereum全体のバリデータ数ではなく、mump2pにつながった範囲です。ネットワーク全体が一斉に切り替わったと受け取るのは誤りです。
バリデータは、32 ETH単位のステークを基礎としてブロック提案やアテステーションに参加する論理的な役割です。一つの事業者が多数のバリデータを運用できるため、16事業者と約2万2,000バリデータは同じ種類の数値ではありません。前者は運営主体の数、後者は参加するバリデータ単位の概数です。分散性を考えるときは、単純なバリデータ数だけでなく、何社が、どの地域や基盤で運用しているかも重要になります。
140万ETH超と約34億ドルのTVBが示す範囲
Optimumは接続バリデータに関連するステークを140万ETH超、発表時の評価額を約34億ドルとし、これをTVB（Total Value Boosted）と表現しています。この数字は、mump2pが保管する顧客資産、預かり残高、売上高、プロトコル収益を示すものではありません。補助伝播を利用するバリデータに結び付いたETHの評価額を表す、開発元独自の指標です。
また、ドル換算額はETH価格に応じて変わります。140万ETH超という数量と約34億ドルという時価評価を分けて読む必要があります。「34億ドルがmump2pへ入金された」「同額の資産がmump2pの管理下にある」と言い換えることはできません。導入規模の参考にはなりますが、製品の安全性や収益性を直接証明する数字でもありません。
公称2〜4倍高速化は何を測った数値か
まなぶ「クリプ先生、“2〜4倍速い”なら、Ethereumのブロック時間そのものが短くなったんですか？」
クリプ「いや、ここで比べているのはブロックが各ノードへ届く速さなんだ。ブロック生成の周期や合意ルールが2〜4倍になったわけではないよ。」
「平均2〜4倍高速」という表現は、ブロックが作られる間隔、取引確定までの時間、Ethereum全体の処理件数が2〜4倍になったという意味ではありません。発表が扱うのは、同じブロックが標準のlibp2p経路とmump2p経路のどちらから先に到着したか、また到着までにどれほど時間がかかったかです。ネットワーク伝播の改善と、プロトコル全体の性能改善を区別することが出発点になります。
10回中9回で標準libp2pより先に受信
Optimumの初期本番測定では、mump2pが10回中9回の割合で標準libp2pより先にブロックを届けたとされています。これは「全ブロックの90%が必ず高速化する」という保証ではなく、開発元が観測した比較結果の要約です。地域、接続先、時間帯、ブロックの大きさ、ネットワーク混雑などが変われば、先着する経路も変わり得ます。
二つの経路を競争させる構成では、先に届いた正常なデータを使い、遅れて届く同一データを重複として処理できます。このため、mump2pが常に勝つ必要はありません。標準経路が先に届けば標準経路を使えます。価値は「補助経路が平均的に速いか」だけでなく、片方が遅延した場面で別経路が間に合う可能性を持てる点にもあります。
到着時間分散7.88分の1という評価
発表には、到着時間の分散が標準経路の7.88分の1だったという公称値もあります。分散は、平均値の周りで測定結果がどれだけ散らばるかを見る尺度です。平均到着時間が短くても、時々大幅に遅れるなら運用の予測は難しくなります。反対に、ばらつきが小さければ、到着タイミングを見積もりやすくなります。
ただし「分散が7.88分の1」は「毎回の到着時間が7.88倍速い」と同じではありません。平均速度とばらつきは異なる指標であり、単位や計算方法も違います。さらに、この数値の再現性を判断するには、測定したノード数、地域、期間、標本数、外れ値の扱いを確認する必要があります。現時点では、公称値として扱うのが適切です。
本番値と事前実験を同一視できない理由
mump2pの背景には、36地域ノードを使った実験やシミュレーションをまとめた研究があります。そこでは、高負荷や大きなメッセージを扱う条件で、RLNC方式がGossipsubより小さい遅延やばらつきを示しました。この結果は仕組みの可能性を支えますが、2026年10月のEthereumメインネット全体と完全に同じ条件で実施した独立再現試験ではありません。
実験では条件を制御し、方式ごとの差を見やすくできます。本番では、世界各地の回線品質、クラウド事業者、クライアント実装、ピア選択、他の処理負荷が混在します。したがって「研究で優位だった」「本番初期測定で速かった」「各運営者の環境で利益が出る」は三段階に分けて評価すべきです。前二つは後一つを自動的に保証しません。
RLNCはブロック伝播をどう高速化するのか
必要な特定断片の再送を待たず、複数経路から届く独立断片を復元に使えるため、遅い経路への依存と待ち時間を減らせることが要点です。
まなぶ「符号化断片って、元のブロックを細かく切っただけですか？」
クリプ「単純な切り分けとは少し違うよ。複数の断片を数学的に混ぜ、十分な種類を集めれば元データを復元できるようにするんだ。」
RLNCはRandom Linear Network Codingの略で、日本語ではランダム線形ネットワーク符号化と呼ばれます。直感的には、送るデータを複数の材料に分け、それらを異なる係数で混ぜた断片を作る方法です。受信側は、内容が重ならない十分な数の断片を集め、連立方程式を解くように元のデータを復元します。
ブロックを符号化断片に分けて配信する仕組み
通常のファイル分割を本のページに例えると、1ページ目を失った場合は同じ1ページ目を別の相手から取り直す必要があります。RLNCでは、各断片が複数ページの情報を少しずつ含むような状態を作ります。そのため、特定の断片だけを待つのではなく、復元に役立つ独立した断片を複数の相手から集められます。
ネットワーク上では、ノードが受け取った符号化断片をさらに組み合わせ、別のピアへ渡すこともできます。送信元から全データを順番どおりに受け取ってから再送する方式に比べ、複数経路の帯域を同時に使いやすくする狙いがあります。経路の一部が遅い、あるいは断片が失われる状況でも、別経路から届いた有用な断片で復元へ近づけます。
十分な独立断片から元データを復元
復元に重要なのは断片の単純な個数ではなく、互いに独立した情報を持つことです。同じ組み合わせの断片を何度受け取っても、新しい情報は増えません。異なる係数で作られた断片が必要数そろえば、受信側は元のブロック相当データを再構成できます。この性質が、経路ごとに「欠けた特定パーツ」を要求する同期処理を減らす方向に働きます。
もちろん、符号化と復号には計算が必要です。研究ではその負荷を含めた評価が行われていますが、実際の設備で許容できるかはCPU、メモリ、帯域、同時処理数によって異なります。伝送時間の短縮が計算負荷を上回る環境では効果を得やすくても、小規模機器や極端な高負荷時に同じ結果になるとは限りません。
遅延・ばらつき・単一経路依存を抑える狙い
RLNCの狙いは、最短経路を一つ当てることではなく、複数経路から届く帯域を復元に役立てることです。ネットワークの接続関係が変わる状況でランダム線形結合が情報拡散を効率化し得ることは、過去の理論研究でも検討されています。また、ブロックチェーンの伝播へ符号化を使う効果はOptimumだけの主張ではなく、別の研究でも対象になっています。
一方、効果は接続構造や帯域、遅延分布などの条件に依存します。符号化すれば常に速くなるという一般則ではありません。断片の生成・検証・復元、ピア管理、異常データへの対処にも資源を使います。技術の理論的な利点と、特定サービスの実装品質は別々に評価する必要があります。
Gatewayが標準Gossipsubと補助網をつなぐ
Ethereumの合意層では、ブロックやアテステーションなどをピア同士へ広めるためにlibp2pのGossipsubが使われます。Gossipsubは、各ノードが話題ごとのメッシュへ参加し、受け取ったメッセージを近隣へ伝える仕組みです。mump2pはこの標準経路を消すのではなく、Gatewayを介して追加の経路を設けます。
合意クライアントのメッセージを中継するサイドカー
Gatewayは、既存の合意クライアントの隣で動くサイドカーです。サイドカーとは、主要アプリケーションを大幅に書き換えず、通信や監視などの機能を外付けする補助プロセスを指します。合意クライアントとmump2pの間でメッセージを中継し、標準網と補助網を橋渡しします。
Optimumの説明では、Gatewayはバリデータの署名鍵を扱わず、署名やバリデータのdutiesを変更しません。これは、秘密鍵を持つ署名ソフトウェアと伝播経路の役割を分離する設計です。ただし、鍵を扱わないことはGatewayにリスクがないという意味ではありません。ネットワーク入力を受け、合意クライアントへデータを渡す以上、入力検証や接続設定は安全性に直結します。
重複排除・SSZ再符号化・ローカル網への再投入
公開されているGatewayの実装概要によると、GatewayはGossipトピックを購読し、受信したデータの重複を除いたうえでmump2pへ転送します。逆方向ではmump2pから受け取った内容をEthereumの形式へ戻し、ローカルの合意層ネットワークへ再投入します。Ethereum合意層のメッセージではSSZというシリアライズ方式が用いられるため、境界での符号化処理が必要です。
同じブロックが標準Gossipsubとmump2pの両方から届く設計では、重複排除が重要です。識別が正しく機能すれば先着データを活用し、後着データを無駄に何度も処理せずに済みます。反対に、不具合や設定不整合があれば、CPU、メモリ、帯域を余計に消費したり、ローカル網へ不要な再投入を繰り返したりする可能性があります。
標準Gossipsubを残すフェイルセーフ設計
標準経路を残す利点は、補助網に障害が起きても元の通信手段を利用できる点です。mump2pが停止した、Gatewayが再起動した、資格情報が失効した、といった場面でも、合意クライアントが標準Gossipsubへ接続し続けていれば、直ちに通信手段をすべて失う構成にはなりません。
ただし、二重経路があるだけで自動的に可用性が保証されるわけではありません。両経路が同じクラウド、回線、DNS、設定管理へ依存していれば、共通原因で同時に影響を受けることがあります。フェイルセーフとして評価するには、標準経路だけで正常運転へ戻れるか、Gateway停止時の監視と切り分けができるかを実環境で試す必要があります。
性能の根拠と限界：分かること・分からないこと
新しいネットワーク技術を判断するときは、論文、テストネット、本番測定、公開コード、第三者監査を同じ証拠として混ぜないことが大切です。論文は方式の性質を比較し、テストネットは運用統合を試し、監査は特定時点のコードや設計から弱点を探します。それぞれが答える質問は異なります。
36地域ノードの実験で確認された遅延と安定性
OPTIMUMP2Pの研究は、36の地域ノードを使う実験とシミュレーションでRLNC方式とGossipsubを比較しました。調査資料によれば、高負荷や大容量の条件で、提案方式は遅延とばらつきを抑えました。悪意あるノードを含む条件での配信性も論点に含まれています。これは、単なる製品紹介より踏み込んだ技術的根拠です。
一方、研究結果から分かるのは、その実験設計と条件の範囲です。現在のEthereumメインネットで、全クライアント、全地域、全ブロックについて同じ倍率になることまでは証明しません。論文の比較結果は「仕組みが機能し得る根拠」、本番の継続観測は「現実の構成でも効果が続くかを確かめる根拠」と整理できます。
大手ノード事業者とHoodiで進めた事前評価
本番稼働の前には、KilnやP2P.orgなどを含むノード事業者がテストネット段階に参加したと発表されました。Lido Operator Portalでも、Lido Curatedの運営者を対象に、Hoodi上で約1カ月の評価参加が案内されています。段階的な導入は、実運用に近い接続や監視、障害対応を確認する機会になります。
ただし、参加事業者の名前や規模は、それだけで性能値の独立検証を意味しません。誰がどの測定を行い、原データを公開し、結果を再現したのかを見る必要があります。テストへの参加、製品の採用、測定結果への第三者保証は別々の事実です。
公開コードとProbeLab監査で確認できる範囲
OptimumはGatewayや操作用CLIなどをGitHubで公開しています。公開コードがあれば、外部の開発者はデータの流れや更新履歴を確認できます。さらにProbeLabはGatewayのセキュリティ監査を行い、合意クライアント接続、bootstrap API、beacon APIなどの攻撃面を整理しました。
監査は、対象となった版と範囲に対する専門家の検査です。将来の更新、運用設定、資格情報の保管、クラウド側の権限、未知の脆弱性まで永続的に安全と保証するものではありません。導入者は監査報告の指摘だけでなく、実際に使用するバージョン、修正状況、依存ライブラリ、公開ポートを照合する必要があります。
本番測定でまだ分からないこと
一方、2〜4倍、10回中9回、分散7.88分の1という本番値は開発元発表です。測定期間、対象ブロック数、地域分布、計測開始点、外れ値処理、標準経路のピア構成は公開資料だけでは確定できません。研究は方式の可能性、Hoodiは導入手順、監査は特定版の攻撃面を検証しますが、この本番倍率を独立に再現したものではありません。
判断を強めるには、固定した測定方法、匿名化した原データ、地域・クライアント別の結果、長期間の分位点、第三者再現が必要です。ここでいう分位点とは、測定値を小さい順に並べたときの位置で、中央値に加えて遅い側の95％点などを見ると、平均値では隠れる遅延を確認できます。現状は「初期の公称測定」として扱うのが妥当です。
伝播速度と報酬改善は同義ではない
ブロックを早く受信できれば、バリデータが最新情報を基に動ける余地は増えます。しかし、収益や報酬は伝播速度だけで決まりません。バリデータがブロック提案や投票などの担当作業（duties）を行うタイミング、クライアントの処理、地域、MEV用のブロック候補を作るビルダーと、それを運ぶリレーへの接続、障害時間など多くの条件が関係します。
数十ミリ秒や数百ミリ秒の差が実務上重要になる場面はあり得ますが、その差がどれだけ報酬に反映されるかは運営者ごとに測る必要があります。平均到着時間だけでなく、担当作業の失敗、遅れた投票（アテステーション）、提案成功率、追加費用、障害時間を同じ期間で比較して初めて、導入効果を判断しやすくなります。
TVBは預かり資産や収益を示す指標ではない
TVBは「Total Value Boosted」というOptimum独自の呼称であり、DeFiで一般的に使われるTVLと同一ではありません。接続するバリデータのステーク評価額を合算した規模感であり、mump2pのスマートコントラクトへロックされた資産や、補償対象の残高を示しません。
独自指標を見るときは、定義、集計時点、重複の有無、価格換算方法を確認します。TVBが大きいことは利用範囲の一面を表しますが、ネットワークの分散性、コードの安全性、事業の継続性、利用者が得る収益を直接示すわけではありません。投資判断の単独材料にはできません。
ここからは運営者向け：運用負荷とセキュリティリスク
まなぶ「標準経路を残すなら、追加しても悪いことはないように見えます。」
クリプ「逃げ道が増える利点はあるけれど、管理するソフトや接続口も増えるんだ。可用性と攻撃面の両方を測る必要があるよ。」
補助経路は冗長性を増やす一方、システムの部品も増やします。新しいプロセス、設定ファイル、資格情報、ポート、監視項目、更新手順が加われば、障害点と誤設定の可能性も増えます。導入判断では速度だけを測らず、追加した複雑性に見合うかを考えます。
サイドカー・APIキー・追加ポートが増やす攻撃面
Optimum Gatewayの利用にはAPIキーなどの資格情報と、合意クライアント側のピア設定が必要です。APIキーは秘密鍵そのものではありませんが、漏えいすればサービスの不正利用や運用情報の露出につながる可能性があります。環境変数、設定ファイル、ログ、バックアップ、サポート時の共有経路まで含めて保護する必要があります。
追加ポートやAPIは、必要な送信元だけに制限し、インターネットへ不用意に公開しないことが基本です。実行ユーザーの権限を絞り、合意クライアントや署名機器から可能な範囲で分離し、更新版の署名や配布元を確認します。監査済みの設計でも、管理画面を公開したり、既定資格情報を使い回したりすれば運用上の弱点になります。
二重配信の重複排除と資源消費
同一メッセージが二経路から届くこと自体は設計上想定されています。しかし、重複判定が追いつかない、再投入ループが起きる、異常な断片を大量に受ける、といった状況では帯域やCPU、メモリを圧迫する可能性があります。通常時の平均負荷だけでなく、ピーク時や障害時の挙動を見るべきです。
運営者はGatewayのキュー長、復号時間、重複率、エラー率、再接続回数、CPU・メモリ・帯域を監視し、合意クライアントの同期状態やdutiesと相関させます。資源上限や再起動方針を決め、Gatewayを止めた状態でも標準経路で運用を継続できるかを定期的に確認すると、障害の切り分けが容易になります。
補助網への接続集中と障害・検閲・観測の懸念
多くの事業者が同じ補助網へ依存すると、その補助網の障害や設定ミスが複数の運営者へ同時に波及する可能性があります。標準Gossipsubが残るため直ちにEthereum全体の停止を意味しませんが、補助経路に期待した性能が一斉に失われる相関リスクはあります。
また、集中した中継点は、どの運営者がいつ接続し、どのメッセージを送受信したかというメタデータを観測しやすくする懸念があります。運営主体がメッセージを選別する可能性、地域別の利用条件、ログの保存方針、サービス停止時の扱いも確認対象です。公称の「permissionless」という説明だけでなく、利用するAccelerateなど各サービスの提供条件と依存関係を見る必要があります。
バリデータ運営者と一般保有者への影響
mump2pの直接の導入主体は、Ethereumのバリデータや合意クライアントを運用する事業者です。一般のETH保有者、取引所利用者、ウォレット利用者がブロックを受け取る経路を自分で設定する話ではありません。対象を分けると、ニュースを必要以上に大きく捉えずに済みます。
バリデータ運営者が確認すべき導入条件
運営者はまず、対応する合意クライアントとバージョン、必要ポート、API資格情報、CPU・メモリ・帯域、ログ保存先、監視項目を確認します。次に、Gatewayとmump2pの更新手順、障害時のサポート窓口、利用条件、データの取り扱い、標準経路へ戻す手順を文書化します。
- 互換性：利用中の合意クライアントと構成が正式な対応範囲か
- 権限：Gatewayが署名鍵や不要なAPIへ到達できないか
- 可用性：Gateway停止時も標準Gossipsubで同期とdutiesを続けられるか
- 観測：先着率、遅延分布、重複率、資源消費、エラーを比較できるか
- 更新：監査対象版と実際の導入版の差、脆弱性情報、ロールバック手順を把握しているか
- 契約：利用料金、提供地域、API制限、ログやメタデータの扱いを確認したか
最初から全バリデータへ広げず、影響を限定したカナリア導入で比較する方法もあります。標準経路のみの対照群を残せば、同じ期間のネットワーク状況で効果と負荷を見やすくなります。変更管理では、設定、開始時刻、対象、終了条件を記録しておくことが重要です。
地域・クライアント・MEV運用別の実測が必要
ある地域で標準ピアへの接続が良好なら、補助網の差は小さいかもしれません。逆に、遠距離回線や不安定な経路が多い場所では、複数経路を使う価値が大きくなる可能性があります。クライアントの処理時間がボトルネックなら、ネットワークだけを速くしても全体の遅延は同じ割合で減りません。
MEVを利用する運営では、ビルダーやリレーからのデータ経路と、合意層のブロック伝播を混同しないことも重要です。提案収益の変化をmump2pだけに帰属させるには、他の構成変更や市場状況を統制する必要があります。少なくとも導入前後で同じ指標を取り、平均だけでなく中央値や遅い側の分位点、障害回数を確認します。
ETH保有者に直接の設定変更はない
ETHを取引所や通常のウォレットで保有している人に、mump2pのための設定変更や送金は必要ありません。mump2pの利用をうたって秘密鍵、シードフレーズ、資金移動を求める案内があれば、今回の仕組みとは一致しません。一般利用者が秘密鍵をGatewayへ登録することもありません。
間接的には、ブロック伝播の安定性が高まればネットワーク運用に良い影響を与える可能性があります。ただし、現段階で一般利用者の送金が何秒短縮する、手数料が下がる、ETH価格が上がるとは結論づけられません。mump2pはEthereumの仕様変更ではないため、今後のプロトコル更新を扱うEthereum GlamsterdamとHoodiの最新動向とは分けて追う必要があります。
まとめ：mump2pは標準網を残した補助伝播ルート
mump2pは、Ethereumのブロック伝播をRLNCで補う並行ルートです。一般のETH保有者に作業はなく、手数料や価格への直接効果もまだ言えません。運営者は公称倍率だけでなく、自環境の遅延分布、資源消費、障害復旧、資格情報の管理を比較してください。
現時点の焦点は、開発元の初期測定が長期・地域別・クライアント別でも再現するか、第三者データで確認できるかです。研究、テストネット、公開コード、監査が裏付ける範囲を越えて断定しないことが、導入判断の出発点になります。
