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

こんにちは！新人のIT担当者さん、そしてブロックチェーンやスマートコントラクトのセキュリティに足を踏み入れたばかりの皆さん、日々の開発や学習お疲れ様です！

「スマートコントラクトって、一度ブロックチェーンにデプロイしちゃえば、もう書き換えられなくて安心なんだよね？」
そんな風に思っていませんか？実は、コントラクトには自分自身を完全に消去してしまう（自己破壊する）という、ちょっと恐ろしい機能が隠されているんです。今回は、この selfdestruct（セルフデスクトップ）という仕組みが引き起こす「資金ロックリスク」について、身近な防犯の例えを交えながら、一歩ずつ優しく紐解いていきましょう！

—

1. 家の鍵に例える「selfdestruct（自己破壊）」の恐怖

突然ですが、あなたが大切なお金や宝物を保管するために、頑丈な「金庫」を作ったと想像してください。その金庫には鍵がついていて、あなたが決めたルール通りにしか開きません。これがブロックチェーン上の「スマートコントラクト」です。

では、もしその金庫を作った職人が、こんな隠しコマンドを持っていたらどうでしょう？
「この呪文を唱えると、金庫の扉だけでなく、金庫の躯体そのものが跡形もなく消え去り、中に入っていた現金や宝物は床のコンクリートの底に埋もれて二度と取り出せなくなる」

これが、スマートコントラクトにおける selfdestruct の正体です。コントラクトがこの命令を受けると、ブロックチェーン上からそのコードが消し去られ、コントラクトが持っていた残高（ETHなどの暗号資産）は、強制的に指定された別のアドレスへ送金される……はずでした。しかし、設計を少しでも間違えると、送金先がうまく機能せず、中に入っていた資産が永遠に宙ぶらりん（ロック）されてしまうという悲劇が起きるのです。

泥棒があなたの金庫をこじ開けるのではなく、「設計ミスで自分自身が金庫ごと消滅し、中身が取り出せなくなる」というのが、この脆弱性の怖いところですね。

—

2. 攻撃者やバグが狙う「残存資産の罠」

「でも、わざわざ自分で自分を消すようなバグなんて書かないよ！」と思いますよね。そこが落とし穴なんです。

実務の開発現場では、例えば以下のようなシチュエーションでこのリスクが牙をむきます。

不要になったコントラクトの「お片付け」のつもりが……

開発を終えて「もうこの古いコントラクトは使わないから、消しておこう」と selfdestruct を実行したとします。しかし、そのコントラクト宛てに、後からユーザーがうっかり送金してしまったらどうなるでしょうか？コントラクトはすでに消滅しているため、後から届いたお金は受け取ることも引き出すこともできず、永遠に消えたままになります。

悪意ある第三者による強制送金（強制自爆ハック）

過去の仕様では、特定の条件を満たすと誰でもコントラクトの selfdestruct を呼び出せる設計ミスや、権限管理の甘さを突いたハッカーが、勝手にコントラクトを消去してしまう事件が多発しました。

—

3. 実コードで見てみよう：危ない書き方と安全な書き方

百聞は一見に如かず。実際にSolidity（スマートコントラクトを書く言語）のコードを見ながら、何が危険でどう対策すべきかを確認していきましょう。

以下のコードは、昔よく見られた「危ないお片付け機能」を持つコントラクトの例です。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

// 【注意】これは危険な古い書き方のサンプルです
contract UnsafeVault {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    // お金を預かる機能
    function deposit() public payable {}

    // コントラクトを消去してオーナーに残高を渡す関数
    function destroy() public {
        require(msg.sender == owner, "オーナーしか呼べません");
        
        // 【危険】ここでコントラクトが消滅し、指定アドレスに残高が強制送金されます
        // もし送金先で何らかのエラー（ガス不足や受取拒否）が起きると、資金がロックされます
        selfdestruct(payable(owner));
    }
}

このコードの何が問題かと言うと、selfdestruct は「問答無用でデータを消し去る」ため、現代の柔軟なコントラクト設計においては、あまりにもリスクが高すぎるのです。

—

4. EIP-6780による救世主！最新の仕様変更を知ろう

「えっ、じゃあ怖くてコントラクトなんて書けないよ……」と思ったそこのあなた、安心してください！
イーサリアムの開発者たちもこの問題を重く見て、EIP-6780という大型アップデート（2024年のDencunアップグレードなど）を導入しました。

このアップデートにより、selfdestruct の挙動が大きく変更されました。
「同じトランザクション内で新しく作成されたコントラクト以外では、資金の消滅やコントラクトの完全削除が制限され、実質的に単なる『残高の強制送金（Transfer）』に近い挙動へ安全化された」のです。

つまり、昔のように「うっかりコントラクトが消えて資金が迷子になるリスク」は大幅に軽減されました。しかし、それでもなお、無駄な機能や古い書き方をコードに残しておくべきではありません。

一歩ずつ進める安全な設計のベストプラクティス

実務では、selfdestruct を極力使わず、以下のような「一時停止（Pausable）」や「アップグレード可能（Upgradeable）」なパターンを採用するのが現代の標準です。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/Pausable.sol";

// 【推奨】OpenZeppelinなどの信頼されたライブラリベースの安全な設計
contract SafeVault is Ownable, Pausable {
    
    // コンストラクタでオーナーを設定
    constructor() Ownable(msg.sender) {}

    // お金を預かる機能
    function deposit() public payable whenNotPaused {}

    // 緊急時にコントラクトの機能を一時停止する（selfdestructは使わない！）
    function emergencyStop() public onlyOwner {
        _pause(); // 機能をストップするだけで、コントラクト自体は消さない
    }

    // 通常の引き出し機能
    function withdraw(uint256 amount) public onlyOwner {
        require(address(this).balance >= amount, "残高が不足しています");
        (bool success, ) = payable(owner()).call{value: amount}("");
        require(success, "送金に失敗しました");
    }
}

このように、コントラクトを「消してしまう」のではなく、_pause() 関数を使って「一時的に鍵をかけて安全に守る」というアプローチを取るのが、現代のセキュリティにおける鉄則になります。

—

まとめ

いかがでしたでしょうか？今回は、スマートコントラクトの自己破壊（selfdestruct）が引き起こす資金ロックリスクについて、防犯の例えや実際のコードを交えて解説しました。

selfdestruct はコントラクトと資金を消滅させる諸刃の剣。
古いコードや不適切な設計は、資金ロストの大きな原因になる。
現代の仕様（EIP-6780）や、OpenZeppelin等のライブラリを活用し、消すのではなく「一時停止して安全に管理する」設計へシフトしていきましょう！

セキュリティの世界は一見難しそうに見えますが、一つひとつの仕組みを丁寧に紐解いていけば、必ず安全なコードを書けるようになります。一緒に一歩ずつ、セキュアな開発スキルを磨いていきましょうね！