ニュース暗号資産Mantle、11月5日のRethバグを受けop-reth v1.6.3でステートルート修正をバックポート、資産は安全

Mantle、11月5日のRethバグを受けop-reth v1.6.3でステートルート修正をバックポート、資産は安全

著者: Tron Weekly·

重要ポイント

  • •Mantle Network は op-reth mantle-v1.6.3 をリリースした。これは独自のプロダクションバージョンライン上のリリースで、最新のアップストリーム版へ移行する代わりに、アップストリームの Reth 修正をバックポートしたものだ。
  • •セキュリティ企業 Blockaid は11月5日、未修正のノードが不正なステートルートを生成し、アプリやブリッジがオンチェーン状態の検証に使う RPC メソッド eth_getProof 経由で不正なステートプルーフを返す可能性があると開示した。
  • •アップストリームの修正は公開開示の2日前となる11月3日に Reth に取り込まれ、Reth v2.10.0 および op-reth v2.8.1 を含む修正済みリリースとして提供された。
  • •Blockaid はこの問題をエクスプロイトではなく正確性のバグと分類し資金流出は確認されなかった。Mantle は資産が安全であり、ユーザーの対応もデータベース移行も不要であることを確認した。
  • •most の OP Stack チェーンが op-reth クライアントを共有しているため、このバグはそれ以外は独立したネットワーク間に相関リスクをもたらし、Base の node-reth v1.5.3 リリースや Celo のバックポートマージといった対応を促した。
Mantle、11月5日のRethバグを受けop-reth v1.6.3でステートルート修正をバックポート、資産は安全

Mantle Network は、op-reth スタックの基盤となるアップストリーム実行クライアント Reth に存在し、Ethereum 互換ネットワーク全般に影響していたステートルートバグの発生中もオンラインを維持した。チームは op-reth mantle-v1.6.3 をリリースした。これは Mantle 独自のプロダクションバージョンライン上のリリースであり、最新のアップストリーム版に移行する代わりに、アップストリームのバグ修正をバックポートしたものだ。Xでの発表において Mantle は、資産は安全でありユーザーの対応もデータベース移行も不要としながら、ノード運営者にアップグレードを要請した(投稿)。

リスクの高い短時間のインシデント

この一件は短時間で終わり、エンドユーザーには見えなかったため、重要でないように見えるかもしれない。しかしそうではない。ステートルートは、アカウント残高やコントラクトストレージの有効性を証明するために用いられる暗号学的コミットメントであり、その計算を誤ると、ノードの停止、無効なプルーフの返却、あるいは標準チェーンからの逸脱が生じうる。「Layer 2 が Ethereum に Settlement する以上、このレイヤーでの正確性は極めて重要だ」と Mantle の発表は強調した。

何が起きたか、誰が影響を受けたか

不具合は、Ethereum 実行クライアントの Rust 実装である Reth、および複数の Layer 2 ネットワークが採用するその OP Stack 版 op-reth に存在していた。11月5日、セキュリティ企業 Blockaid は、未修正のノードが不正なステートルートを生成し、eth_getProof(アプリケーションやブリッジがオンチェーン状態の検証に利用する RPC メソッド)経由で不正なステートプルーフを返す可能性があると開示した。Blockaid はこの問題をエクスプロイトではなく正確性のバグと分類し、実被害としての資金流出は確認されなかった。アップストリームの修正は11月3日 — Blockaid の公開開示の2日前 — に Reth に取り込まれており、Reth v2.10.0 や op-reth v2.8.1 を含む修正済みリリースとして提供された。

対応はエコシステム全体に広がった。Base は node-reth v1.5.3 を公開し、ノードの正確性を再検証したと発表し、Celo はバックポートをマージした。Mantle は異なる道を選び、最新リリースへの更新ではなくプロダクションラインを直接修正した。このバックポート方式は、新しいアップストリーム版からの無関係な変更を取り込むことなく、既存のリリースラインに的を絞った修正を提供するものだ。

より広いクリプトエコシステムにとって重要な理由

実行クライアントは、ブロックチェーンインフラの中で最も目立たないながらも最も影響の大きい構成要素の一つだ。開発者はその上に API を拡張しインデクサーを運用する。機関投資家はカストディアン、取引所、データプロバイダーに依存している。こうしたすべてのレイヤーは、ノードが状態について合意に達することに依存している。不正なステートルートは必ずしも資金の盗難を意味するわけではなく、不正確なプルーフ、同期の停止、あるいはアプリケーションが一貫性のないデータを受け取ることを意味しうる。

ブリッジやクロスチェーンメッセージングサービスが証明可能な状態に依存している場合、わずかな不整合でも予防的な停止を引き起こしうる。これらの停止は防御的な対応であり、エクスプロイトによるものではなかったが、単一のクライアントバグがどれほど速くエコシステム全体の混乱を生み出しうるかを示している。

この一件はまた、クライアントの多様性の重要性とその限界をも浮き彫りにした。Ethereum の実行レイヤーは複数のクライアントを運用することで、一つが故障した場合のシステミックリスクを低減している。しかし most の OP Stack チェーンは op-reth を共有している。この共通コンポーネントのバグは、それ以外は独立しているネットワーク間に相関リスクをもたらす。

Mantle と OP Stack ネットワークの今後

差し迫った課題は運営者による採用だ。パッチは、ノード運営者、RPC プロバイダー、バリデーター、インフラチームが展開して初めてリスクを低減するものであり、運営者はアップグレードを計画しノードをテストすることが求められる。Blockaid は、プロトコルとブリッジに対し、プロバイダーが修正済みであることを確認するよう助言した。

中長期的には、この一件は三つの傾向を浮き彫りにする。即時更新できないプロダクションライン向けのより速い開示とバックポート、プルーフを信頼できない場合のクロスチェーンメッセージのプルーフ検証を含むクライアントバグへのより多くの contingency、そして OP Stack チェーン間の共有依存関係の継続的な分析だ。

Mantle にとっての試練は継続性だ。その設立時の価値提案は、分散型金融、ゲーム、コンシューマーアプリケーション向けのスケーラビリティ、低手数料、信頼できる Settlement に hinges している。アップストリームのバグ発生中もオンラインを維持したことはこの提案を裏付けるが、ネットワークはプロダクションラインがアップストリームのセキュリティパッチと同期し続けていることを示す必要が依然ある。結局のところ、ブロックチェーンセキュリティとは、状態を計算するソフトウェアと、そのパッチ適用の速さにも関わるのだ。