【実務・中級編】コントラクトの自己破壊(selfdestruct)による資金ロックリスク – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

スマートコントラクトの「死」と「残存」：selfdestructが突きつけるWeb3の残酷な現実

現場でコードを叩いている諸君、お疲れ様。今日はスマートコントラクトの「消滅」という、一見すると便利そうな、しかし実際には資金を永遠に奈落へ突き落としかねない危険な機能、selfdestructの話をしよう。

特に最近のEIP-6780による仕様変更は、多くのエンジニアを混乱させている。かつては「コントラクトを削除して整理する」というモダンな掃除術のように思われていたこの命令が、なぜ今、最優先の警戒対象なのか。その泥臭い真実を共有する。

—

1. selfdestructの正体とEIP-6780の罠

selfdestructは、コントラクトをブロックチェーン上から「物理的に」削除し、残ったETHを特定の宛先に強制送金する機能だ。これだけ聞くと「不要なコントラクトを消せる便利なゴミ箱」に聞こえるだろう。

しかし、攻撃者はこれを「資金ロックの兵器」として利用する。

もし、コントラクトAがコントラクトBを呼び出し、Bがselfdestructを実行して消滅したとする。Bのコードが消えた後、Bの古いアドレスに誰かが誤って（あるいは意図的に）ETHを送金したらどうなるか？そのETHは二度と取り出せない。コントラクトBはもう存在せず、誰にも制御できないからだ。

EIP-6780による変化

Dencunアップグレード以降、selfdestructは「同じトランザクション内」で作成されたコントラクトしか削除できなくなった。一見、安全になったように見えるだろう？だが、これは「過去の設計のまま運用している古いコントラクトが、実は脆弱なまま放置されている」ことを意味する。古い設計思想で作られたプロダクトほど、この地雷を抱えている可能性が高いんだ。

—

2. 攻撃シナリオ：PoCで見える「資金消失」

攻撃者は、コントラクトの設計上のミスを突き、自らの手で相手の資金を凍結させる。

// 攻撃対象となる脆いコントラクトのイメージ
contract VulnerableVault {
    // 資金を受け取る関数
    function deposit() public payable {}

    // 管理者だけが実行できる削除関数。これが悪夢の始まり。
    function kill() public onlyOwner {
        selfdestruct(payable(msg.sender));
    }
}

この VulnerableVault が一度 kill() された後、外部から deposit() に相当する処理や、予期せぬ送金が行われると、その資金はブラックホールに消える。インフラエンジニア諸君、これをWebアプリに置き換えて考えてくれ。「ユーザーがログインできなくなったシステムに、さらに課金し続ける」ような状況だ。目も当てられないだろう？

—

3. 実践：絶対に踏んではいけない地雷を避けるための設計

結論から言うと、selfdestructはもう使うな。 これが現在のベストプラクティスだ。

コントラクトを「停止」させたいのであれば、削除するのではなく「一時停止（Pause）」させるのが鉄則。OpenZeppelinの Pausable を活用し、論理的にアクセスを遮断するのが、現代のWeb3開発における「大人の振る舞い」だ。

推奨される堅牢な実装（JavaScript/ethers.jsによる制御例）

もしコントラクトの運用を制御する管理画面を構築しているなら、削除ボタンを作るのではなく、以下のコードのように「停止フラグ」を立てる設計にすること。

// フロントエンドや運用ツールからコントラクトを安全に制御する例
async function pauseContract(contractInstance) {
    try {
        console.log("コントラクトを一時停止中...");
        
        // selfdestructの代わりに、OpenZeppelinのPausableを利用
        const tx = await contractInstance.pause();
        await tx.wait();
        
        console.log("安全に運用を停止しました。資金はコントラクト内に保護されています。");
    } catch (error) {
        console.error("停止処理に失敗しました。緊急事態を確認してください:", error);
    }
}

—

4. インフラ・セキュリティ担当が今すぐやるべき「棚卸し」

Web3プロジェクトを守る君たちへ、今日からやるべきタスクをリストアップした。

全コードの静的解析: grep -r "selfdestruct" ./contracts を実行し、該当するコードがどこにあるか全て洗い出せ。
権限の再確認: selfdestructを実行可能な関数に、誰がアクセスできるのか？マルチシグ（Gnosis Safe等）で保護されていないなら、今すぐ修正だ。
監査ログの強化: 万が一のインシデントに備え、Webサーバー側でコントラクト呼び出しのログを記録し、異常なトランザクションを検知するアラートを仕込め。

Nginxでの推論攻撃対策（参考）

直接ブロックチェーンとは関係ないが、コントラクトのAPIエンドポイントを叩くWebサーバー側も固めろ。

# /etc/nginx/conf.d/security.conf
# 頻繁なステータス変更リクエストをレートリミットで防ぐ
limit_req_zone $binary_remote_addr zone=contract_limit:10m rate=1r/s;

location /api/v1/contract/ {
    limit_req zone=contract_limit burst=5 nodelay;
    # 承認済みIPからのアクセスのみを許可するなどの厳格な制御
    allow 192.168.1.0/24;
    deny all;
}

—

最後に：エンジニアとしての矜持

selfdestructを安易に使いたがるエンジニアは、しばしば「後始末」を過小評価する。しかし、Web3の世界では「削除」は取り消し不可能な破壊行動だ。

我々リサーチャーが現場で見てきたのは、設計の甘さが招いた数億円規模の損失だ。君たちが書くコードは、単なるテキストではない。それはデジタル資産の門番だ。その責任を理解し、常に「最悪の事態」を想定した設計を心がけてほしい。

何か疑問があればいつでも聞いてくれ。泥臭い現場の知見が、君たちのコードを守る盾になるはずだ。