[Solidityのはじめ方] Part19: アクセス制御（onlyOwner, modifiers）

スマートコントラクトは、一度デプロイされると変更が困難なため、設計段階でセキュリティを十分に考慮する必要があります。もしアクセス制御が不適切だと、悪意のある第三者がコントラクトの重要な機能を不正に操作したり、保管されている資金を盗んだりする可能性があります。😱

例えば、以下のような操作は特定の権限を持つユーザー（通常はコントラクトの所有者）のみに許可されるべきです。

• コントラクトの設定変更（手数料率の変更など）
• コントラクトの一時停止・再開
• コントラクトに保管されている資金の引き出し
• 管理者権限の移譲

これらの操作を誰でも実行できてしまうと、コントラクトは意図しない動作を起こし、ユーザーに損害を与える可能性があります。適切なアクセス制御を実装することで、このようなリスクを防ぐことができます。

onlyOwner パターンは、Solidityで最も基本的かつ広く使われているアクセス制御の方法です。その名の通り、「所有者（Owner）のみ」が特定の関数を実行できるように制限します。

実装は非常にシンプルです。

1. 所有者のアドレスを保存する変数を定義する: 通常、address 型の owner という名前のステート変数を用意します。
2. コントラクトデプロイ時に所有者を設定する: コンストラクタ内で、コントラクトをデプロイしたアカウントのアドレス (msg.sender) を owner 変数に設定します。
3. onlyOwner Modifierを定義する: 関数を実行しようとしているアカウント (msg.sender) が owner 変数に格納されたアドレスと一致するかどうかをチェックするModifierを作成します。一致しない場合は、require 文でエラーメッセージと共に処理を中断します。
4. 制限したい関数にModifierを適用する: 所有者のみに実行を許可したい関数に、定義した onlyOwner Modifierを追加します。

コード例：

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

contract MyOwnableContract {
    address public owner; // 所有者のアドレスを保存する変数

    // イベント: 所有権が移転されたときに発生
    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    // コンストラクタ: コントラクトデプロイ時に呼び出され、所有者を設定
    constructor() {
        owner = msg.sender; // デプロイした人を所有者とする
        emit OwnershipTransferred(address(0), msg.sender);
    }

    // onlyOwner Modifier: 関数を実行したのが所有者かチェック
    modifier onlyOwner() {
        require(msg.sender == owner, "Ownable: caller is not the owner"); // 所有者でなければエラー
        _; // Modifierのチェックをパスした場合、元の関数の処理を実行
    }

    // 所有者のみが実行できる関数の例
    function withdrawFunds(address payable _to, uint _amount) public onlyOwner {
        // ここに資金引き出しのロジックを記述...
        // 例: require(_to.send(_amount), "Failed to send Ether");
        // 実際のコントラクトでは、残高チェックなども必要です
        // この例では、所有者チェックのみを示しています
    }

    // 所有権を移転する関数（所有者のみ実行可能）
    function transferOwnership(address newOwner) public virtual onlyOwner {
        require(newOwner != address(0), "Ownable: new owner is the zero address");
        emit OwnershipTransferred(owner, newOwner);
        owner = newOwner;
    }
}
        

この例では、withdrawFunds 関数と transferOwnership 関数に onlyOwner Modifierが付与されています。これにより、これらの関数はコントラクトの owner アドレスを持つアカウントからしか呼び出すことができません。

Modifierは、関数の実行前または実行後に特定のコード（チェック処理など）を自動的に実行するための仕組みです。onlyOwner もModifierの一種です。Modifierを使うことで、同じチェック処理を複数の関数で繰り返し書く必要がなくなり、コードの可読性と再利用性が向上します。

Modifierは modifier キーワードを使って定義します。

modifier < modifier名 > ( < 引数リスト > ) {
    // 関数実行前のチェック処理など
    require(< 条件 >, "エラーメッセージ");
    _; // このアンダースコアが、修飾される関数の本体に置き換わる
    // 関数実行後の処理など (必要であれば)
}

重要なのは _; (アンダースコアとセミコロン) です。Modifierの処理の中で _; が書かれた箇所で、そのModifierが適用された関数の本体コードが実行されます。_; の前に書かれたコードは関数実行前に、後に書かれたコードは関数実行後に実行されます。

Modifierの利点 ✨

• コードの削減: 同じ条件チェックを複数の関数に書く必要がなくなります。
• 可読性の向上: 関数の主目的と事前・事後チェックを分離できます。
• セキュリティの向上: アクセス制御や状態チェックなどの重要なロジックを一箇所で管理し、適用漏れを防ぎます。
• 再利用性: 定義したModifierを様々な関数に適用できます。

onlyOwner以外のModifierの例

Modifierはアクセス制御以外にも、様々な事前条件チェックに使えます。

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

contract ModifierExamples {
    address public owner;
    uint public value;
    bool public paused;

    constructor() {
        owner = msg.sender;
    }

    // onlyOwner Modifier (再掲)
    modifier onlyOwner() {
        require(msg.sender == owner, "Not the owner");
        _;
    }

    // コントラクトが一時停止中でないかチェックするModifier
    modifier whenNotPaused() {
        require(!paused, "Contract is paused");
        _;
    }

    // 特定の値以上であるかチェックするModifier (引数付き)
    modifier costs(uint _amount) {
        require(msg.value >= _amount, "Not enough Ether provided.");
        _;
    }

    // 状態を変更する関数 (所有者のみ、かつ一時停止中でない場合)
    function setValue(uint _newValue) public onlyOwner whenNotPaused {
        value = _newValue;
    }

    // 一時停止状態を切り替える関数 (所有者のみ)
    function setPaused(bool _paused) public onlyOwner {
        paused = _paused;
    }

    // Etherを受け取って何かする関数 (0.1 Ether以上必要)
    function payToPlay() public payable costs(0.1 ether) {
        // 支払いを受け取った後の処理...
    }

    // 複数のModifierを適用することも可能
    function complexAction(uint _newValue) public payable onlyOwner whenNotPaused costs(0.05 ether) {
        value = _newValue;
        // さらに複雑な処理...
    }
}
        

この例では、onlyOwner に加えて、コントラクトが一時停止していないかをチェックする whenNotPaused と、関数呼び出し時に十分なEtherが送られているかをチェックする costs というModifierを定義しています。

setValue 関数には onlyOwner と whenNotPaused の両方が適用され、payToPlay 関数には costs が、complexAction 関数には3つ全てのModifierが適用されています。関数に複数のModifierを適用する場合、記述した順に実行されます。

安全で堅牢なスマートコントラクトを開発するためには、アクセス制御を適切に実装することが重要です。以下にいくつかのベストプラクティスを挙げます。

• 最小権限の原則: 関数に必要な最小限の権限のみを与えるように設計します。例えば、誰でも閲覧できる情報取得関数に onlyOwner をつける必要はありません。
• 関数の可視性を適切に設定する: public, external, internal, private を正しく使い分け、意図しない外部からのアクセスを防ぎます。
• Modifierを賢く使う: Modifierは便利ですが、乱用するとコードが複雑になり、ガス消費量が増える可能性もあります。単純なチェックは関数内で require を使う方が良い場合もあります。
• 役割ベースのアクセス制御 (RBAC): onlyOwner だけでなく、複数の役割（管理者、ユーザー、監査役など）を定義し、役割ごとに権限を割り当てる方が、より複雑なアプリケーションには適している場合があります。OpenZeppelinの AccessControl コントラクトがこの実装を助けます。
• イベントを活用する: 所有権の移転や重要な設定変更など、アクセス制御に関連する操作が行われた際にはイベントを発行し、オフチェーンでの監視や追跡を容易にします。
• テストと監査: アクセス制御ロジックが意図通りに機能するか、十分なテストを行いましょう。重要なコントラクトの場合は、専門家による監査を受けることを強く推奨します。
• Checks-Effects-Interactionsパターン: 特に外部コントラクト呼び出しやEther送金を含む関数では、まず条件チェック（Checks）、次に状態変更（Effects）、最後に対話（Interactions）を行うことで、リエントランシー攻撃などの脆弱性を防ぎます。

これらのプラクティスに従うことで、スマートコントラクトのセキュリティを大幅に向上させることができます。

今回は、Solidityにおけるアクセス制御の基本である onlyOwner パターンと、より汎用的な Modifier について学びました。適切なアクセス制御は、スマートコントラクトの安全性を確保するための第一歩です。

• onlyOwnerパターン: コントラクト所有者のみに操作を限定する基本的な方法。
• Modifier: 関数の実行前後にチェック処理などを追加し、コードの再利用性と可読性を高める仕組み。
• ベストプラクティス: 最小権限の原則や関数の可視性、テストの重要性を理解する。

これらの知識を活用し、安全なスマートコントラクト開発を進めていきましょう！🎉 次のステップでは、スマートコントラクト監査の基本について学びます。

• Solidity 公式ドキュメント – Modifiers: https://docs.soliditylang.org/en/latest/contracts.html#modifiers
• OpenZeppelin Docs – Access Control: https://docs.openzeppelin.com/contracts/5.x/access-control (OwnableとAccessControlの両方が解説されています)