autorenew
MegaETH Multisig インシデント:オフチェーン署名のフットガンを解説

MegaETH Multisig インシデント:オフチェーン署名のフットガンを解説

In the fast-paced world of blockchain projects, even the best-laid plans can go awry due to subtle technical oversights. A recent incident involving MegaETH highlights a critical vulnerability in how multisig wallets handle off-chain signatures. Shared via a humorous yet insightful comic on X by @hrkrshnn, this event serves as a cautionary tale for teams managing large-scale funding raises.

MegaETHのmultisigインシデントを描いた漫画

セットアップの理解

2025年11月25日、MegaETH チームは正確に午前11時に $1B の cap raise を実行することを目標にしていました。そのために Safe multisig ウォレットを使用し、7人中4署名を必要とする設定にしました。計画は事前にこれらの署名をオフチェーンで収集し、予定時刻にトランザクションを提出するというものです。

Multisig(マルチシグ)は、トランザクションを実行する前に複数の承認を要求するウォレットのセキュリティ機能です。複数の鍵で金庫を守るように、管理権限を分散してセキュリティを高めます。off-chain signatures は、これらの承認がブロックチェーンに即時ブロードキャストされずに収集されることを意味し、準備はできてもコミットはしない運用を可能にします。

MegaETH の構成では、Safe multisig が最初に $250M に制限された pre-deposit contract を管理し、後にその上限を引き上げる計画でした。

フットガン:オフチェーン署名の可視性

ここで問題となるのが「フットガン」—自ら招いた危険です。Safe TX Service API は off-chain signatures を公開状態で見られるようにしています。この設計はオーナーが認証なしでアクセスしやすくする一方で、どこを見ればよいか知っている者には署名を露出してしまいます。

コミックでは "godtierfarmer.eth" や "chud.eth" といった人物が API 経由で署名を覗き見る様子が描かれています。便利ではありますが、慎重に管理されていないとこの透明性はリスクを招きます。

ツイートで指摘されているように: "The @megaeth issue is arguably a (known) footgun in Safe. All four signatures were off-chain signatures, but the @safe backend exposes them to anyone, as opposed to only other signers."([元ツイート](https://x.com/hrkrshnn/status/1993465014712516736))

事件の展開

午前10時26分—予定より34分早く—"chud.eth"(オーナーではない)が収集された署名を使って $1B への cap raise を実行しようとトランザクションを送信しました。レース条件に敗れて失敗しましたが、脆弱性が存在することを鮮明に示しました。

MegaETH が引用した retro では、SaleUUID ミスマッチ、Sonar のレート制限、そして解決後に発生した大量の入金といった追加の問題も詳述されています。チームは上限を管理された方法で引き上げるつもりでしたが、露出した署名により早まった試みが可能になってしまいました。

最終的にキャップは早期に引き上げられ、$500M まで埋まったところで一時停止しました。資金が失われることはありませんでしたが、コミックが表現する通り「顔を覆いたくなる瞬間」でした。

学んだ教訓と振り返り

コミックは以下の重要な教訓で締めくくられます:

  1. すべての署名を早期に収集しないこと:少なくとも1つは go-time まで保留しておき、早期実行を防ぐ。
  2. API 設計の改善:理想的には Safe API はオフチェーン署名を非オーナーから隠すべきで、このリスクを軽減する。

MegaETH チームは ops チームへの共感を示し、プレッシャーの高い環境ではこうしたミスが起こり得ることを認めています。彼らの透明な retro は複合的な技術問題を浮き彫りにし、資産は危険にさらされなかったものの、ユーザー体験には影響が出たことを強調しています。

ブロックチェーン実務者にとって、この事件はツールの細部を理解する重要性を再確認させるものです。Safe のようなツールは強力ですが、デフォルト設定をそのまま使うと問題になる場合があり、特にトークンの調達のような公衆向け運用では注意が必要です。

Meme トークンとそれ以外への影響

MegaETH は厳密にはミームトークンではありませんが、ここでのダイナミクスはタイミング、公平性、セキュリティが最重要となるミームコインのローンチと似通っています。ミームプロジェクトはしばしばトレジャリー管理やローンチに同様の multisig 設定を使うため、この警告は非常に relevant です。仕組みが露出すればフロントランニングやエクスプロイトにつながり、信頼が損なわれます。

先手を打つために、チームはワークフローを監査し、保留中署名のプライバシーを優先するカスタムスクリプトや代替の multisig ソリューションを統合することを検討すべきです。

暗号資産の世界で構築しているなら、こうしたインシデントは学びの宝です。詳細は引用された投稿の全文 retro を確認し、X 上の議論をフォローしてブロックチェーン運用のベストプラクティスに関する洞察を得てください。

おすすめ記事