Polygon PoSのサイドチェーン構造で実行を担うBorに、安定版v2.10.2が公開されました。更新担当者が最初に判断すべき点は三つです。古いWIT2ベータ版を安定版と混在させないこと、Clef利用時は告知署名の許可を確認すること、状態ルート計算パイプラインは標準更新と同時に有効化しないことです。これはハードフォークやデータベース移行ではなく、再同期も不要なノードソフトウェア更新です。
対象はバリデータ、ブロック生産者、sentryノード（ブロック生産者を外部接続から隔離する中継ノード）、予備ノードの運用者です。必須対応は正規配布物への更新と互換性確認、任意対応は状態ルート計算パイプラインの性能試験です。更新前の合格条件は現行構成と基準値を記録できていること、更新後の合格条件はチェーン先端への追随、ピア接続、WIT2または意図したWIT1利用、資源指標が許容範囲にあることです。
- 対象者：Borを直接運用する担当者。一般利用者の操作は不要です。
- 必須：正確な版、古いWIT2ベータ利用歴、Clef、取得元GHCRを確認して標準設定で更新します。
- 任意：パイプラインは更新成功後、比較対象を用意した試験として別に扱います。
- 失敗判定：接続断、追随遅延の拡大、意図しないWIT1フォールバック、資源上限超過があれば変更を進めません。
Witnessと状態ルートを処理順に沿って説明した後、実行順、合格条件、ロールバック分岐を示します。なお、Polygon PoSとEthereumのL2との違い、処理上限の基礎となるEthereumのガスの仕組みは関連記事で補えます。本稿は2026年10月14日時点の公式フォーラム、GitHub Release、実装PRを整理したもので、独自の実機ベンチマーク結果ではありません。
Bor v2.10.2で押さえるべき変更点
公開日とアップデートの位置づけ
Bor v2.10.2は2026年9月30日に安定版として公開されました。Polygonの運営案内とGitHubのリリースノートが示す位置づけは、合意ルールを切り替えるハードフォークではなく、既存のPolygon PoSノードソフトウェアを更新するリリースです。そのため「指定ブロック高で全員が新ルールへ移るイベント」と考えるより、運用対象ノードのバイナリやコンテナを計画的に差し替える保守作業と捉えるのが適切です。
ただし、ハードフォークでないことは、いつ更新しても影響がないという意味ではありません。WIT2の古いベータ実装と安定版では通信データ形式（通信データ形式）が異なるため、対象ノード群の構成によっては接続互換性を考慮する必要があります。更新計画では「チェーンが分岐するか」だけでなく、「どのノード同士が同じ通信機能を使うか」を確認します。
再同期・genesis変更・DBスキーマ変更は不要
公式案内では、v2.10.2への移行に再同期、genesis変更、データベーススキーマ変更はいずれも不要と説明されています。既存チェーンデータを捨てて最初から同期し直す種類の更新ではありません。これは作業時間とストレージ負荷を見積もるうえで重要ですが、バックアップ、停止手順、ロールバック条件を省いてよいという意味ではありません。
実務では、現在のBorバージョン、起動引数、設定ファイル、コンテナイメージのdigest、接続先、Clef利用の有無を更新前に記録します。起動後はプロセスが立ち上がっただけで完了とせず、チェーン先端への追随、ピア数、エラーログ、ブロック取り込みの遅延まで確認します。再同期不要という性質を生かし、異常時に直前の構成へ戻せる作業単位を保つことが大切です。
運用への影響が大きい主要項目
中心となる変更は三つあります。第一は、ブロック生産者が署名したWitness告知をピアが検証し、ブロック取り込み前から中継・配布できるWIT2です。第二は、あるブロックの状態ルート計算と次のブロックの取引実行を重ねる状態ルート計算パイプラインです。第三は、同期、mempool、preconfirmation、sequencerなどで発生し得た個別症状への修正です。
このうち、WIT2は通信経路と署名設定、パイプラインは計算資源と同期性能に関係します。preconfirmationとsequence storeはv2.10.2へ上げるだけで自動的に有効になる機能ではありません。また、公式コンテナの取得先はDocker HubではなくGHCRです。機能、既定値、配布方法を一つの変更として混同せず、それぞれを別の確認項目に分けます。
WIT2はWitness伝播をどう変えるのか
まなぶ「クリプ先生、Witnessってブロックそのものとは違うんですか？」
クリプ「うん。ブロックが取引のまとまりなら、Witnessはその取引後の状態を検証するための証拠データだよ。先に告知とWitnessが届けば、受信ノードが自分のブロック取り込みを終えるまで次への配布を待つ時間を短くできるんだ。」
ブロック生産者がWitness告知へ署名する流れ
WIT2では、ブロック生産者がWitnessの存在や内容に関する告知へ署名します。受信側は、単に「あるピアから届いた」という接続関係だけに頼らず、その告知が正当なブロック生産者によって署名されたものかを確かめられます。告知と実データを区別して扱うため、まず検証可能な案内を広げ、その後に必要なWitnessを取得する流れを組み立てられます。
署名は内容を秘密にする暗号化ではありません。また、署名があれば届いたデータのすべてが無条件に正しいという意味でもありません。署名者と告知の結び付きを確認する材料であり、受信サイズやページ数など別の検証も組み合わせます。Clefを使って署名操作を分離している環境では、新しい告知用MIMEタイプを許可できているかが実運用上の要点になります。
未実行のピアでも告知を検証・中継できる理由
従来の流れでは、ピアが自分でブロックを実行して結果を得るまで、次の配布行動に必要な確信を持ちにくい場面があります。WIT2の署名付き告知なら、受信ピアはブロック実行の完了を待たずに署名を検証し、告知を次のピアへ中継できます。これがtransitive relay、つまり一つ先だけで止めず、検証した告知を連鎖的に伝える考え方です。
ここで改善対象になるのは情報がネットワークへ広がる順番です。個々のノードのCPU性能を直接引き上げる機能でも、通信遅延をゼロにする機能でもありません。どれほど効果が出るかはピア構成、ネットワーク品質、負荷、WIT2対応状況に左右されるため、自環境の観測値で判断します。
ブロック取り込み前にWitnessを配布する狙い
pre-import servingは、ローカルでブロック取り込みが完了する前でも、条件を満たしたWitnessを他のピアへ提供できるようにする考え方です。各ノードが前段の処理をすべて直列に終えるのを待ってから次へ渡すのではなく、検証可能な情報とデータを早めに流すことで、ネットワーク全体の待ち時間を減らす狙いがあります。
ただし、早期配布には受信データの境界管理が必要です。無制限にページを受け取ったり、ピア間の曖昧な合意だけでサイズを決めたりすれば、資源消費の問題につながります。そこでWIT2では、署名済みサイズ帯とガス由来のページ上限という補強が組み合わされています。
WIT2のサイズ検証と受信上限
署名済みサイズ帯で許容するWitness差
Witnessは、同じ目的のデータでも生成過程によって表現上のサイズが完全には一致しない場合があります。WIT2のsize oracleは、その非決定性を「何でも許可する」のではなく、ブロック生産者が署名したサイズ帯の範囲で受け入れる設計です。厳密な一値だけを要求して正当な差まで拒否することと、上限なく受け入れることの間に、検証可能な許容範囲を置きます。
初心者は「非決定的」を「結果がランダムで信用できない」と誤解しがちです。ここで問題にしているのは、チェーン状態の正否が毎回変わるという話ではなく、Witness表現のサイズ差をどう安全に扱うかです。署名された範囲に収まることは受理条件の一部であり、告知の署名検証や受信上限と一緒に機能します。
ガス由来の上限でページ数を制限
Witnessをページ単位で受け取る際、受信可能なページ数はガスから導く上限で縛られます。ブロックが消費できる計算量の枠と関係する情報から天井を求めることで、要求されたページを無制限に受け続ける状況を避けます。これは、通信機能を早めても資源消費の境界を失わないための防御です。
上限があるからといって、帯域やメモリの監視が不要になるわけではありません。実際のリソース消費は、同時接続数、データの到着タイミング、キャッシュ、ディスクI/Oなどにも左右されます。更新後は拒否や再試行に関するログも含め、WIT2が正常に働いているかと資源消費が許容範囲かを合わせて確認します。
ピア間投票に依存しない検証設計
ページ上限を決める際に、接続中のピアが示す値を多数決のように集計すると、接続相手の偏りや悪意あるピアの影響を考える必要が生じます。v2.10.2に含まれる補強では、ページ数の境界をクロスピア投票ではなくガス由来の上限へ結び付けます。各ノードが同じ種類の入力から独立に境界を確認しやすくする設計です。
この変更を「ピアを信用しなくてよくなった」と広く解釈するのは正確ではありません。P2P運用には接続管理、レート制御、ログ監視などが引き続き必要です。ここで投票依存を外したのはWitnessページ数という特定の判定です。変更の適用範囲を限定して理解することが、過大評価を避けるコツです。
混在バージョンとClef設定の注意点
WIT1とWIT2の接続単位での交渉
WIT1とWIT2は、ネットワーク全体が一斉にどちらか一方へ切り替わるのではなく、接続ごとに対応能力を交渉できます。したがって、安定版WIT2に対応したノードとWIT1のみのノードが存在する移行期間そのものは想定されています。接続相手に応じて利用できるプロトコルを選ぶため、段階的な導入が可能です。
ただし、段階導入できることと、どのバージョンの組み合わせでも安全に混在できることは別です。運用台帳にはBorの大まかな世代だけでなく、正確なバージョンとWIT2ベータ利用歴を記録します。sentryとブロック生産者のように通信経路上で強く結び付くノード群は、同じメンテナンス窓で更新する方が不整合の切り分けをしやすくなります。
古いベータ版との混在で接続が切れる条件
公式リリースは、古いWIT2ベータ版とv2.10.2安定版で通信データ形式が異なる点を注意事項として挙げています。該当するベータ版を運用しているノードと安定版を混在させると、互換性のない通信によって接続が切れる可能性があります。通常のWIT1ノードとの能力交渉とは分けて扱うべき問題です。
更新前には、対象ホストの実行ファイルだけでなく、コンテナタグ、digest、過去に試験導入したイメージが残っていないかを確認します。ロードバランサーやオーケストレーターの背後に複数個体がある場合、一部だけ古いベータ版のまま残ることもあります。同一窓更新の目的は停止時間をそろえることだけでなく、互換性のない期間を短くし、問題発生時の原因候補を減らすことです。
Clefで許可するMIMEタイプとフォールバック確認
まなぶ「設定を忘れたらノードが止まるから、すぐ気づけますよね？」
クリプ「今回は止まらずWIT1へ戻る場合があるんだ。静かなフォールバックだから、稼働確認だけでなく使われたプロトコルも確かめよう。」
Clefを署名に使う環境では、application/x-bor-wit2-announceを許可する必要があります。このMIMEタイプが許可されていない場合、WIT2の告知署名を利用できず、WIT1へフォールバックします。注意したいのは、必ずしもプロセス停止のような目立つ障害にならないことです。
更新後に「Borが起動している」「ブロック高が進んでいる」だけを確認すると、WIT2を使えていない状態を見逃します。Clefのルール、拒否ログ、Bor側のプロトコル交渉やフォールバックを示すログを確認し、期待する接続でWIT2が成立しているかを観測します。セキュリティ境界を弱める一括許可ではなく、公式が示す対象MIMEを必要な範囲で追加します。
状態ルート計算パイプラインの仕組み
まなぶ「パイプラインって、二つのブロックを同時に確定することですか？」
クリプ「確定ルールを変える話ではないよ。ブロックNの状態ルート計算と、次のN+1の取引実行を重ねて待ち時間を減らす処理方法なんだ。」
状態ルート計算と次ブロック実行の並行化
状態ルートは、ある時点のアカウントやコントラクト状態を要約して表す値です。ブロックの取引を実行して状態を更新した後、その結果を木構造へ反映し、ルートを計算する処理があります。通常これらを順番に待つと、ブロックNの後処理が終わるまでN+1の実行へ進みにくくなります。
状態ルート計算パイプラインは、ブロックNの状態ルート計算とブロックN+1の取引実行を重ねます。工場の流れ作業のように、異なる段階を別の対象へ同時に適用して全体の待ちを減らす発想です。二つのブロックを無関係に処理するわけではなく、状態の依存関係と正しい順序を保ちながら、重ねられる工程を並行化します。
ブロック取り込みと同期追随で狙う改善
この機能が狙うのは、外部から受け取ったブロックを取り込むブロック取り込みと、チェーン先端へ追随する同期処理です。同期が遅れたノードが複数ブロックを連続して検証するとき、状態ルート計算と次ブロック実行の重なりが効けば、直列処理の待ちを減らせる可能性があります。
ただし、性能向上の大きさは公式情報だけから一律に断定できません。CPUコア、メモリ、データベースを置くストレージの遅延、キャッシュ、同居プロセス、追随時の負荷などでボトルネックは変わります。機能の説明と、自環境で得られる改善値を区別してください。
block production向け機能ではない理由
パイプラインはブロック取り込みの処理経路に導入されたもので、ブロック生産そのものを高速化する設定として案内されているわけではありません。「並列化」という言葉だけから、バリデータの提案機会や報酬が増えると結び付けるのは根拠がありません。目的は受信済みブロックの処理と同期追随の改善です。
ブロック生産者にも同期性能は運用上重要ですが、それは生産ロジックが変わることとは別です。評価指標にはimport時間やチェーン先端との差を置き、ブロック提案数や暗号資産価格を直接の成果指標にしない方が、機能の範囲に沿った検証になります。
パイプラインを有効化する前の検証項目
既定で無効になっている設定
v2.10.2へ更新しても、状態ルート計算パイプラインは既定で無効です。つまり、バージョン更新の安全性確認とパイプライン有効化の性能試験を分けられます。最初に標準設定のまま安定版へ更新し、互換性や通常同期を確認した後、試験対象だけで任意機能を有効にする段階設計がしやすい構成です。
既定無効は「危険だから使ってはいけない」という判定でも、「有効にすれば必ず速くなる」という約束でもありません。運用環境ごとの差を計測しながら導入するための選択肢です。設定名と指定方法は公式リリースノートを参照し、利用中の設定管理方式へ正確に反映します。
有効化前後で計測するリソースと同期遅延
比較では、CPU使用率の平均だけでなくピークとスロットリング、メモリ使用量とGC、ディスクの読み書き量・待ち時間、チェーン先端との差、ブロックimport時間、再起動後に追い付くまでの時間を記録します。並行処理によりCPU利用が増えても同期遅延が縮む場合がある一方、I/Oが詰まれば期待した改善が出ない可能性があります。
比較条件もそろえます。同じ種類のホスト、同等のピア構成、近い負荷帯で無効時と有効時を観測し、単発の最良値ではなく継続的な傾向を見ます。アラート閾値、リソース上限、異常時の無効化手順を先に決めておけば、試験が本番障害へ広がるリスクを抑えられます。
並列処理のレース修正と試験上の留意点
並列処理では、複数の処理が同じ状態へ触れる順番によって結果が変わるレースが課題になります。v2.10.2へ至る開発過程では、夜間継続テスト（nightly test）で見つかったパイプラインの競合失敗が修正されています。また、競合検出テスト（race test）が完走できるようパッケージのタイムアウトも調整されました。
修正と試験強化は安定版を評価する材料ですが、すべてのハードウェアや負荷で問題が起きない保証ではありません。検証環境では通常同期だけでなく、遅れからの追随、再起動、負荷上昇、ログローテーションなど実運用に近い条件も試します。問題が出たときは、パイプライン有効化の前後、Borバージョン、ホスト指標、該当ログ時刻をそろえて切り分けます。
該当機能を使う運用者だけ確認する周辺修正
信頼済みピアと同期ペナルティの扱い
同期時のペナルティ免除は、信頼済みピアだけへ限定されました。一般ピアまで例外扱いできる余地を狭め、運用者が明示的に信頼した接続先にだけ免除を適用する変更です。これはWIT2のサイズ上限とは別の同期防御であり、ピア設定の意味をより厳密にします。
更新後はtrusted peerの登録内容を棚卸しし、古いアドレスや不要な接続先が残っていないかを確認します。信頼設定は接続しやすさのための便利なラベルではなく、通常の扱いから外す可能性がある設定です。構成管理に登録理由、所有者、確認日を残すと、例外が恒久化するのを防ぎやすくなります。
再取込・tx-fetch・SetHeadの同期安定化
ホワイトリスト地点より前の正規ブロックを再取込する際、正規チェーンであるにもかかわらず処理が妨げられるケースへの修正が含まれます。また、取引取得が宙づりになったピアを永久に除外せず再試行する変更は、再起動後にsentryのmempoolが長時間ほぼ空になる症状への対処です。
チェーン先端を戻すSetHead処理の途中でsnap syncへ切り替わらないようにする修正も入っています。これらはすべて「同期」という一語に属しますが、過去ブロックの再取込、取引取得ピアの再利用、同期モードの遷移という異なる経路です。更新後の確認も、head追随だけでなくmempoolの回復、再試行ログ、SetHeadを伴う運用時の挙動に分けます。
preconfirmationとsequencerの修正範囲
preconfirmation経路では、pending state読取時の不要なreceiptコピーを避ける最適化、正規ブロック（canonical block）の取り込み後もpreconfirmation receiptを保持する修正が含まれます。sequencerでは、自身が確認済みの親sealによって後続ビルドが止まる条件が修正されました。これらは該当機能を運用する環境で確認すべき変更です。
一方、名称がリリースノートに並んでいるからといって、すべてのBor利用者がpreconfirmationやsequence storeを使っているわけではありません。両機能は既定で無効です。自組織で有効化していないなら、更新によって突然サービスが始まることはありません。有効化済みなら、receiptの継続性、pending読取、ビルド進行、外部sequence storeとの接続を個別に回帰確認します。
Bor v2.10.2更新前後のチェックリスト
1. 事前記録と対象ノードの特定
資産台帳からバリデータ、ブロック生産者、sentry、予備ノード、検証環境を洗い出し、正確なBorバージョン、起動引数、設定ファイル、接続先、Clef利用の有無を記録します。CPU、メモリ、ディスクI/O、ブロック取り込み時間、チェーン先端との差、ピア数、mempool回復時間も更新前の基準値として保存します。合格条件は、各ノードの所有者と現行構成を一意に追跡できることです。
古いWIT2ベータ版が一台でもあれば互換性対象として印を付け、通信経路上で結び付くノード群を同じメンテナンス窓へ入れます。WIT1だけのノードとの段階移行と、通信データ形式が異なる旧WIT2ベータとの混在は別問題です。後者を長く残す計画は合格にしません。
2. GHCRイメージとdigestの確認
公式コンテナの取得先はDocker HubではなくGitHub Container Registry（GHCR）です。CI/CD、構成管理、レジストリミラー、脆弱性スキャンの参照先を確認し、タグだけでなく実際に展開するdigestを記録します。GHCRへの通信、認証、社内ミラーへの同期を事前に試し、全ホストが意図した同一成果物を参照できれば合格です。取得元やdigestを確認できない成果物は展開しません。
3. 標準設定で更新する
設定と監視状態を保存し、戻す版・イメージ・設定、担当者、連絡経路を明記してから、冗長性を保てる順序で更新します。この段階では状態ルート計算パイプライン、preconfirmation、sequence storeを新たに有効化しません。版更新と任意機能を分離することで、異常時の原因候補を狭めます。プロセスが指定版で起動し、設定の読込エラーがなく、チェーン先端へ追随すれば一次合格です。
4. WIT2とClefを確認する
Clef（署名鍵の操作をBorプロセスから分離する署名ツール）を使う場合は、application/x-bor-wit2-announceの許可、拒否ログ、Bor側のプロトコル交渉を確認します。WIT2を期待する接続で成立していること、または設計どおりWIT1を選んでいることが合格条件です。起動していても意図せずWIT1へ静かに戻っていれば不合格とし、許可範囲をむやみに広げずClefルールを修正します。
5. 同期と資源指標を比較する
ピア数、チェーン先端との差、ブロック取り込み時間、Witnessの拒否・再試行、CPU、メモリ、ディスクI/O、mempoolの回復を事前値と同じ時間軸で比較します。監視ダッシュボードに変更時刻を残し、通常の負荷変動と更新の影響を区別します。運用チームが定めた閾値内で安定し、追随遅延が継続的に拡大しなければ標準更新は合格です。
6. 任意でパイプラインを試験する
標準更新が安定した後、比較対象を残した検証ノードでだけパイプラインを有効化します。同種ホスト、近い負荷帯、同等のピア構成で、CPUピークとスロットリング、メモリとGC、ディスク待ち時間、チェーン先端との差、ブロック取り込み時間、再起動後の回復時間を無効時と比較します。同期遅延が改善し、資源とエラーが事前の上限内なら展開候補です。改善がない、I/O待ちや追随遅延が悪化する、エラーが増える場合は無効へ戻します。
7. 異常時のロールバック分岐
接続断、追随不能、意図しないフォールバック、資源上限超過が続く場合は、まず直前に変えた一項目を戻します。パイプライン試験中なら設定を無効化し、標準更新そのものに問題があるなら記録済みの旧版イメージと設定へ戻します。再同期やDB移行は不要と案内されているため、原因確認前にデータディレクトリを削除しません。旧構成で追随と指標が基準内へ戻ったことをロールバックの合格条件とし、ログ時刻、版、digest、設定差分を保存して再試験へつなげます。
まとめ：運用者別の次の行動
- 全運用者：現行構成と基準値を保存し、GHCRの正規成果物を標準設定で更新して、追随・接続・資源指標を確認します。
- 古いWIT2ベータ利用者：通信データ形式の非互換を前提に対象群を特定し、安定版との混在時間を短くします。
- Clef利用者：告知用MIMEタイプを必要な範囲で許可し、意図しないWIT1フォールバックがないかログで確認します。
- パイプライン試験者：標準更新の合格後に別変更として試し、同期改善と資源増加を比較し、無効化条件に触れたら戻します。
この順序なら、安定版への保守更新、WIT2の通信確認、任意の性能試験を切り分けられます。判断の根拠は機能名ではなく、版・設定・ログ・同条件の計測値です。
