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

selfdestructの終焉と「資金ロック」の罠：Dencunアップグレード後の生存戦略

現場で「とりあえずコントラクトを削除してリセットすればいい」なんて安易な設計をしているエンジニアがいたら、今すぐその思考を止めてくれ。特にSCADAやIoTのゲートウェイがオンチェーンの決済と連携している場合、その判断は致命的な経済的損失を招く。

今回は、EIP-6780によって「死に体」となったはずの selfdestruct が、なぜ今なおエンジニアを地獄へ突き落とすのか、その深淵を解説する。

—

1. EIP-6780がもたらした「半端な削除」という悪夢

かつて、selfdestruct はコントラクトを消し去り、その残高を全額指定アドレスへ送金する強力なツールだった。しかし、Dencunアップグレードにより仕様が大きく変わった。現在は、「同一トランザクション内で作成されたコントラクト以外」に対して selfdestruct を実行しても、ただの空のオペレーションになるか、あるいは単なる送金処理に成り下がるようになったんだ。

ここで最も恐ろしいのは、「コントラクトは生きているのに、ロジックだけが機能不全を起こす」という状況だ。

なぜ資金がロックされるのか？

多くの開発者が陥る罠は、「コントラクトを削除したつもりで、実はストレージやロジックの一部が中途半端に残り、後から送金された資金が『ブラックホール』に飲み込まれる」というケースだ。特に、プロキシパターンを採用していない古い設計のコントラクトでこの破壊を行うと、そのアドレス宛に送られたトークンやETHは、二度と引き出せなくなる。

—

2. 実践的防御：セキュアな「退避」ロジック

コントラクトを「破壊」するのではなく、「無効化」する設計に変える必要がある。以下のサンプルコードは、Solidityで実装すべき「セキュアな資金退避パターン」だ。

推奨される実装例（Solidity）

selfdestruct に頼らず、ステート変数で「停止状態」を管理し、資金を確実に引き出すロジックを実装する。

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

contract SecureVault {
    address public owner;
    bool public isStopped; // 運用停止フラグ

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Unauthorized");
        _;
    }

    // 緊急停止機能：ロジックを封印する
    function stopVault() external onlyOwner {
        isStopped = true;
    }

    // 資金を確実に退避させる関数
    function withdrawAll(address payable _target) external onlyOwner {
        require(isStopped, "Vault must be stopped before withdrawal");
        
        uint256 balance = address(this).balance;
        require(balance > 0, "No funds to withdraw");
        
        // 安全に全額を転送
        (bool success, ) = _target.call{value: balance}("");
        require(success, "Transfer failed");
    }

    // 停止中は入金を拒否
    receive() external payable {
        require(!isStopped, "Vault is closed for deposits");
    }
}

—

3. インフラレイヤーでの「安全装置」

ブロックチェーンのロジックだけでなく、フロントエンドやバックエンドのインフラ側でも「誤操作による資金消失」を防ぐための設定が必要だ。特にIoTデバイスからWeb3ウォレットへ署名を送るようなアーキテクチャでは、署名権限を厳格に制限すること。

AWS IAM ポリシーの例（鍵管理の保護）

もしオンチェーンのトランザクション実行をバックエンドサーバー（KMS等）で行っている場合、selfdestruct を呼び出す権限を全ユーザーから剥奪しておく。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "kms:Decrypt",
        "kms:Sign"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "kms:EncryptionContext:Method": "selfdestruct"
        }
      }
    }
  ]
}

*注：これはあくまで概念的な制限だ。スマートコントラクト側のアクセス制御（onlyOwnerなど）が第一の防壁であることを忘れないでほしい。*

—

4. セキュリティリサーチャーからの警告

いいか、後輩諸君。Web3の世界では「コードは法律」だ。一度ロックされた資金は、どれだけ泣き叫ぼうが、法的な救済はほぼ不可能だ。

1. 自己破壊は禁忌: 現代のイーサリアムでは selfdestruct は使うな。代わりに「停止フラグ」を立てて、資金を退避させるための「退避用関数」を用意しろ。
2. テストネットでの極端なシミュレーション: selfdestruct がどう挙動するか、Sepolia等のテストネットで「送金可能な状態」を維持したまま実行し、そのアドレスがどうなるかを徹底的に観測しろ。
3. プロキシパターンの検討: ロジックを切り離すなら、selfdestruct ではなく、アップグレード可能なプロキシパターン（Transparent Proxy等）を使うのが定石だ。

現場で何かトラブルが起きたとき、「仕様が変わったから仕方ない」という言い訳は、そのまま君のエンジニアとしてのキャリアの終焉を意味する。常にEIPの動向を追い、最新の環境で何が起こるかを検証し続けること。それがプロの仕事だ。