スマート コントラクトにアクセス制御を実装するにはどうすればよいですか?

アクセス制御の基礎を理解する

1. アクセス制御は、イーサリアムまたはその他の EVM 互換ブロックチェーンにデプロイされたスマート コントラクト内の特定の機能を実行できるユーザーを定義します。

2. 適切なアクセス制限がないと、外部アカウントまたは契約により、所有権の譲渡や新しいトークンの鋳造などの機密操作がトリガーされる可能性があります。

3. OpenZeppelin Contracts ライブラリは、不正な動作を軽減するために、 Ownable 、 AccessControl 、 ReentrancyGuardなどの標準化された監査済みの実装を提供します。

4. 所有権ベースのモデルでは単一のアドレスに排他的特権を割り当てますが、役割ベースのシステムでは、きめ細かな権限による複数の信頼できるエンティティにわたる委任が可能です。

5. アクセス修飾子が正しく設定されていないと、特に所有者の秘密キーが紛失したり侵害された場合、管理機能が回復不能に失われたり、契約全体が侵害されたりする可能性があります。

Ownable と AccessControl のどちらを選択するか

1. Ownableは、一時停止や緊急撤退などの重要な機能に対して 1 人のデプロイ担当者が単独の権限を保持する単純なユースケースに適しています。

2. AccessControl は、独立した割り当て、取り消し、放棄の機能を備えた階層型ロール (ADMIN_ROLE、MINTER_ROLE、PAUSER_ROLE など) をサポートします。

3. AccessControlのロールは bytes32 識別子として表され、関数の実行前にロールのメンバーシップをチェックするカスタム ロジックが有効になります。

4. Ownableを継承するコントラクトは、コア ロジックを再設計するか、状態を新しい展開に移行することなく、複数管理ガバナンスに簡単にアップグレードできません。

5. どちらのパターンも、実行時に条件を強制するために、 onlyOwnerやhasRoleなどの修飾子と組み合わせたrequireステートメントに依存します。

Solidity でのロールベースの権限の実装

1. 定数 bytes32 変数を使用して必要なロールを宣言します (例: bytes32 公開定数 MINTER_ROLE = keccak256('MINTER_ROLE') ) 。

2. 構築中に_setupRole(DEFAULT_ADMIN_ROLE, msg.sender)を呼び出してデフォルトの管理者を初期化し、初期制御を付与します。

3. GrantRole(role, account)を使用して権限を動的に割り当て、DEFAULT_ADMIN_ROLE 以上の所有者のみがこのアクションを実行できるようにします。

4. 機密関数は、呼び出し元の適格性を検証するために内部でhasRoleを呼び出すonlyRole(MINTER_ROLE)などの修飾子を使用して保護します。

5. revokeRole(role, account)を介して明示的な取り消しメカニズムを組み込み、チーム メンバーが退職するときやキーがローテーションされるときに権限を削除します。

所有権の移転と放棄を確実に行う

1. transferOwnership関数はイベントを発行し、内部の_owner記憶変数をアトミックに更新する必要があります。

2. 偶発的な自己破壊や管理権限のロックを防ぐために、新しい所有者がゼロ以外のアドレスであることを要求します。

3. 現在の所有者がrenounceOwnershipを呼び出すことを許可し、 _owner をaddress(0) に設定して、それ以降の所有権ベースのアクションを効果的に無効にします。

4. 契約が所有権を受け入れて安全に管理するためのフォールバック ロジックを実装していない限り、所有権を契約に譲渡することは避けてください。

5. 再入またはフロントランニングベクトルを防ぐために、所有者アドレスをハードコーディングしたり、所有権関連関数内に未チェックの外部呼び出しを埋め込んだりしないでください。

よくある質問

Q: 同じ契約内で Ownable と AccessControl を組み合わせることはできますか? A: はい、ただし、冗長性が生じ、競合が発生する可能性があります。 Ownableインターフェイスを期待する従来のツールとの下位互換性が必要でない限り、 AccessControlのみを使用することをお勧めします。

Q: DEFAULT_ADMIN_ROLE 所有者が秘密キーを紛失した場合はどうなりますか? A: タイムロックまたはマルチシグ ラッパーが外部に実装されていない限り、回復は不可能です。失われた認証情報を復元するオンチェーン メカニズムは存在しません。

Q: EOA のみにロールを割り当てるのは安全ですか? それとも契約でもロールを保持できますか? A: コントラクトはロールを保持できますが、そのためには、悪意のあるデリゲートコールや信頼できない外部ロジックによる攻撃対象にならないように、慎重に設計する必要があります。

Q: 開発中にアクセス制御ロジックをテストするにはどうすればよいですか? A: Hardhat または Foundry を使用して、未承認のアカウントからのトランザクションをシミュレートし、メインネットにデプロイする前に、expect(revert) パターンで復帰をアサートします。