Polygon Labsは、ネットワークが公に発表する前に、2つのハードフォークを通じて静かに修正された2つのセキュリティ脆弱性を明らかにしました。これらの修正は、8月29日にPolygonステークメインネットで有効化されたAustinおよびKyotoのアップグレードに含まれており、技術的な詳細を説明するコミュニティフォーラムの投稿は、それより2日前に掲載されました。
実際に何が壊れていたのか
オースティンハードフォークは、Bor実行クライアントをv2.10.0にアップグレードし、メインネットブロック91,949,700で有効化されました。京都は、Heimdallコンセンサスクライアントをv0.11.0にアップグレードし、ブロック高51,533,000で有効化されました。
Bor側では、二つのカテゴリの問題に対処する必要がありました。まず、L1からL2へのステート同期イベントが実質的に計測されておらず、通常のガス会計によって制限される過剰な計算を、ブロックリソースを消費する可能性がありました。オースティンフォークは、このリスクを制限するために、ブロックごとのガス上限を導入しました。
2番目のBorの問題は、無制限のTxDependencyデータに関係していました。これはBorがトランザクションの順序を追跡するために内部で使用する構造です。この構造のサイズに制限がなければ、意図的に作成された入力によってブロック処理が停止したり、接続されたピアが完全にクラッシュしたりする可能性がありました。
ヘimdallの問題は性質が異なっていた。コンセンサスクライアントは、ヘimdallが基盤としているCosmos SDKスタックで広く使用されているprotobuf Anyメッセージの処理において、バイトレベルのネスティング脆弱性を抱えていた。この層におけるネストされたメッセージ処理のエラーと署名検証の問題は、バリデータ間のコンセンサスメッセージの妨害に利用され得た。Kyotoフォークは、これらのチェックをバイトレベルでパッチした。
両方のフォークにはバイナリアップグレードのみが必要でした。ジェネシスファイルの変更、ステート移行、歴史的なチェーンデータの書き換えは必要ありませんでした。バリデーターはソフトウェアを更新する必要がありましたが、チェーンステート自体はそのまま維持されました。
アップグレードしなかったノードには何が起こりますか
フォーク前のバイナリを引き続き実行しているすべてのバリデーターまたはノードオペレーターは、正統なコンセンサスから外れて動作しています。これらのノードは、ネットワークの残りの部分が放棄したチェーンに自らフォークしています。
ポリゴンのガイドラインは明確です。直ちにBor v2.10.0以上およびHeimdall v0.11.0以上にアップグレードするか、ロールバックおよび再同期手順に従ってください。
Polygonは、両方のアクティベーション中にメインネットの障害は発生しなかったと報告しました。両方のフォークは、メインネット展開前にAmoyテストネットで検証され、コミュニティフォーラムへの開示は、メインネットアクティベーションの前にではなく、成功後にタイミングを合わせました。
2026年における積極的なアップグレードのパターン
オースティンと京都は孤立した出来事ではありません。Polygonは2026年7月にIthacaハードフォークを活性化し、ネットワーク上のライブ性と支払いの信頼性を向上させました。
過去1年間、Polygon PoSネットワークは重要なアーキテクチャの移行を経てきました。ネットワークのネイティブトークンがMATICからPOLへ移行し、ステーキング改革の議論が継続され、sPOLというリキッドステーキングトークンが導入されたことにより、バリデーターおよびステーカーのコミュニティは経済的かつ技術的な変化を同時に吸収しています。
まだアップグレードしていないバリデーターオペレーターは、この開示を緊急事態とみなしてください。DoS脆弱性の詳細が公開されたことと、フォーク前のノードが既に正規のコンセンサスから外れていることから、古いバイナリを実行し続けることは一時的な問題ではなく、状況が悪化し続ける問題です。