【入門編】 DeFiにおける緊急停止機能(Circuit Breaker)の実装 – IoT・OT（制御システム） & ブロックチェーンセキュリティ防御ガイド

皆さん、こんにちは！
Web3の世界へ飛び込んだばかりの新人開発者さん、あるいは日々のセキュリティ対策に奮闘しているIT担当者の皆さん、スマートコントラクトの開発は順調に進んでいますか？

ブロックチェーンの世界は、一度デプロイ（公開）してしまうと、コードを簡単に「修正」できません。銀行のシステムであれば、バグが見つかったら週末にこっそりメンテナンスをして修正できますが、パブリックチェーン上では、世界中の攻撃者があなたのコードを常に監視しています。

今回は、DeFi（分散型金融）プロトコルを守るための最終防衛ライン、「緊急停止機能（サーキットブレーカー）」について、身近な防犯の仕組みに例えながら、一歩ずつ優しく紐解いていきましょう！

—

1. 家の鍵と「緊急停止機能」の共通点

突然ですが、皆さんのご自宅の玄関を思い浮かべてみてください。頑丈な鍵がかかっていれば安心ですよね。でも、もしその鍵のコピーが何者かに盗まれてしまったり、窓ガラスが割られて泥棒が侵入してきたりしたらどうでしょう？

「泥棒が入ってきた！」と気づいたとき、皆さんはどうしますか？
のんびり警察を呼ぶ書類を作ったりしませんよね。まずは、家の中の貴重品を隠すか、安全な部屋に鍵をかけて立てこもるか、あるいは緊急用の警備ボタン（セコムなど）を即座に押すはずです。

DeFiの世界における「緊急停止機能（Circuit Breaker）」は、まさにこの「緊急警備ボタン」にあたります。

プロトコルに異常なアクセス（ハッキングの兆候や、価格オラクルのおかしな変動など）を検知した瞬間、システムの心臓部である「資金の引き出し」や「トークンのスワップ」といった主要機能をピタッと一時停止させ、被害の拡大を最小限に食い止めるための仕組みなのです。

—

2. なぜDeFiにサーキットブレーカーが必要なのか？

「きちんとテストを書いたから大丈夫！」
そう思っていませんか？ 痛いところを突いて申し訳ないのですが、複雑なスマートコントラクトの組み合わせ（レゴブロックのように他のプロトコルと連携するDeFiの性質上）では、個々のパーツが完璧でも、組み合わさった瞬間に予期せぬバグ（フラッシュローンを用いた価格操作攻撃など）が生まれます。

攻撃者は、あなたが寝静まった深夜や休日を狙って、ほんの数秒の間にスマートコントラクトから数億円分の資金をごっそり抜き去っていきます。
人間が手動で「あ、攻撃されている！」と気づいてからトランザクションを投げて止めるのでは、ブロックチェーンのスピード（数秒単位の世界）には絶対に間に合いません。

だからこそ、「異常を検知したら自動的、または信頼できるマルチシグ（複数署名）ガバナンスによって、一瞬で機能をストップできる仕組み」をあらかじめコードに組み込んでおく必要があるのです。

—

3. 実装してみよう！シンプルなサーキットブレーカーのコード

それでは、実際にSolidityを使って、緊急停止機能を持つスマートコントラクトの基本形を見ていきましょう。
難しく考えず、「おうちのブレーカー（スイッチ）」をイメージしながらコードを読んでみてくださいね。

以下のサンプルコードでは、OpenZeppelin社の有名なライブラリである Pausable の概念をベースに、分かりやすく日本語のコメントを添えて解説しています。

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

/**
 * @title 初心者向けの緊急停止機能（サーキットブレーカー）付きコントラクト
 * @notice 泥棒（攻撃者）が入ってきたときに、家全体のブレーカーを落とす仕組みを再現しています。
 */
contract SimpleCircuitBreaker {
    // オーナー（管理者）のアドレスを保持します
    address public owner;

    // サーキットブレーカーの状態（true: 停止中, false: 正常稼働中）
    bool public paused;

    // ユーザーの預金残高を記録するマッピング
    mapping(address => uint256) public balances;

    // 状態が変化したときに外部へ知らせるイベント（防犯ブザーのようなものです）
    event Paused(address account);
    event Unpaused(address account);
    event Deposited(address indexed account, uint256 amount);
    event Withdrawn(address indexed account, uint256 amount);

    // 「いま停止中かどうか？」をチェックするモディファイア（条件のフィルター）
    modifier whenNotPaused() {
        require(!paused, "CircuitBreaker: システムは現在緊急停止中です！");
        _; // 条件クリアなら、本来の処理を実行します
    }

    modifier whenPaused() {
        require(paused, "CircuitBreaker: システムは現在正常稼働中です。");
        _;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Caller: オーナー権限がありません！");
        _;
    }

    constructor() {
        owner = msg.sender; // デプロイした人をオーナーに設定
        paused = false;     // 最初は「正常稼働中（スイッチON）」
    }

    /**
     * @notice 通常時の預金機能
     * @dev whenNotPausedがついているので、停止中はこの関数を実行できません。
     */
    external payable whenNotPaused {
        require(msg.value > 0, "Deposit: 0より大きい値を送金してください");
        balances[msg.sender] += msg.value;
        emit Deposited(msg.sender, msg.value);
    }

    /**
     * @notice 通常時の引き出し機能
     * @dev こちらも緊急停止中は実行不可です。
     */
    external whenNotPaused {
        uint256 amount = balances[msg.sender];
        require(amount > 0, "Withdraw: 残高がありません");

        balances[msg.sender] = 0;
        (bool success, ) = msg.sender.call{value: amount}("");
        require(success, "Withdraw: 送金に失敗しました");

        emit Withdrawn(msg.sender, amount);
    }

    /**
     * @notice 【緊急ボタン】オーナーが異常を検知したときに呼び出す
     */
    external onlyOwner whenNotPaused {
        paused = true; // ブレーカーを落とす！
        emit Paused(msg.sender);
    }

    /**
     * @notice 【復旧ボタン】安全が確認された後にシステムを再開する
     */
    external onlyOwner whenPaused {
        paused = false; // ブレーカーを戻す
        emit Unpaused(msg.sender);
    }
}

コードのポイント解説

  • paused という変数が、家でいう「メインの安全ブレーカー」の役割を果たしています。
  • modifier whenNotPaused というフィルターを各機能（預金・引き出し）の入り口に貼ることで、paused が true になった瞬間に、すべての出入り口がガッチリとロックされる仕組みになっています。

—

4. ガバナンスによる復旧プロセスの重要性

さて、ここで一つ大きな疑問が湧くはずです。
「誰がその緊急ボタンを押すの？もしオーナーの秘密鍵がハッキングされたら、悪意ある人が勝手に停止ボタンを押したり、逆に解除できなくしたりするのでは？」

その通り！非常に鋭い着眼点です。
先ほどのコードではシンプルにするために onlyOwner（たった一人の管理者）に権限を持たせていますが、実際の商用DeFiプロトコルでこれをやると、管理者のアカウントが乗っ取られた時点でゲームオーバーになってしまいます。

そのため、実務の世界では以下のような「ガバナンスと復旧プロセス」を設計します。

1. マルチシグ（Multi-sig）の導入

  • 緊急停止ボタンを押す権利を、信頼できる複数の人物（例えば、コア開発者、セキュリティ監査人、コミュニティ代表など、5人中3人の署名が必要など）に分散させます。一人だけが暴走してもボタンが押せない、あるいは押せる仕組みにします。

2. タイムロック（Time-lock）の活用

  • 復旧（再開）する際には、急にスイッチを入れるのではなく、「24時間後に再開しますよ」という猶予期間（タイムロック）を設けます。これにより、万が一管理者が乗っ取られて不正な復旧を試みても、ユーザーがその間に資金を安全に避難させる時間的猶予を作ることができます。

3. ガーディアン（Guardian）ロールの分離

  • 「システムを停止させる権限（ストップボタン）」はセキュリティ専門AIやガーディアンと呼ばれる即時対応チームに持たせ、逆に「システムを再開させる権限や資金を動かす権限」は厳重なDAOの投票やタイムロック付きマルチシグに分ける、という権限の最小化が定石です。

—

5. まとめ：一歩ずつ、安全なWeb3の世界へ

今回は、DeFiにおける緊急停止機能（サーキットブレーカー）について、家の防犯やブレーカーに例えて解説しました。

  • 緊急停止機能は、攻撃から資産を守る最後の砦（防犯ブザー＆ブレーカー）。
  • コード上では、状態変数と modifier を組み合わせて簡単に実装できる。
  • ただし、誰がそのボタンを握るのか（ガバナンスとマルチシグの設計）がセキュリティの成否を分ける。

セキュリティの世界は奥が深く、最初は聞き慣れない用語に圧倒されるかもしれませんが、一つひとつの仕組みを身近な例に置き換えて考えていけば、必ず理解できるようになります。

焦らず、一歩ずつ、安全で信頼されるスマートコントロクトを作れるエンジニアを目指していきましょう！次回の解説もお楽しみに！

スポンサーリンク

コメント

タイトルとURLをコピーしました