0Pricing
Web3 & DApp Development Fundamentals · レッスン

コントラクトのセキュリティベストプラクティス

リエントランシーガード、checks-effects-interactionsパターン、アクセス制御など、スマートコントラクト開発に不可欠なセキュリティ対策を学びます。

「コントラクトのセキュリティベストプラクティス」はCoddyKit上の無料Web3 & DApp Development Fundamentalsレッスンです。 これはレッスン2/3です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはWeb3 & DApp Development Fundamentals学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Web3 & DApp Development Fundamentalsコースには全3レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Smart Contract Security Intro

Welcome to the critical world of smart contract security! Unlike traditional software, bugs in smart contracts can lead to irreversible loss of funds.

Because smart contracts are immutable once deployed, fixing vulnerabilities is extremely difficult, often requiring complex upgrade mechanisms or even redeploying a new contract.

In this lesson, we'll explore essential practices to build more secure and robust smart contracts.

Understanding Reentrancy

One of the most infamous vulnerabilities is reentrancy. It occurs when an external call to another contract or address "re-enters" the calling contract before the initial function's state updates are complete.

Imagine a bank ATM that lets you withdraw money. If it debits your account *after* giving you cash, a reentrancy attack would be like repeatedly asking for cash before the system updates your balance, draining the ATM.

Vulnerable Withdrawal Code

Consider this simplified contract where a user can deposit and withdraw Ether. Can you spot the danger?

The withdraw() function first sends Ether, then updates the balance. An attacker can call withdraw() again from their malicious contract during the external call, before their balance is set to zero.

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

contract VulnerableBank {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint _amount) public {
        require(balances[msg.sender] >= _amount, "Insufficient balance");

        // Vulnerable point: send Ether BEFORE updating balance
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success, "Failed to send Ether");

        balances[msg.sender] -= _amount; // This happens AFTER the external call
    }

    function getBalance() public view returns (uint) {
        return address(this).balance;
    }
}

Preventing Reentrancy: State Locks

A common and effective way to prevent reentrancy is using a reentrancy guard. This involves locking the state of the contract during an external call and unlocking it afterward.

If a re-entrant call tries to execute the locked function, it will revert. OpenZeppelin's ReentrancyGuard is a popular implementation, but you can also build a simple one.

Implementing Reentrancy Guard

Let's add a simple reentrancy guard using a boolean flag. This ensures that the withdraw function cannot be called again until the current execution is complete and the state has been updated.

The nonReentrant modifier sets a lock, performs the operation, and then releases the lock.

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

contract SecureBank {
    mapping(address => uint) public balances;
    bool private _locked; // Reentrancy guard flag

    modifier nonReentrant() {
        require(!_locked, "Reentrant call detected");
        _locked = true;
        _;
        _locked = false;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint _amount) public nonReentrant {
        require(balances[msg.sender] >= _amount, "Insufficient balance");

        balances[msg.sender] -= _amount; // Update balance BEFORE external call (CEI)

        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success, "Failed to send Ether");
    }

    function getBalance() public view returns (uint) {
        return address(this).balance;
    }
}

The CEI Pattern

The Checks-Effects-Interactions (CEI) pattern is a fundamental security best practice. It dictates a specific order for operations within a function:

  • Checks: Validate conditions (e.g., require statements, onlyOwner).
  • Effects: Update the contract's state (e.g., balances[msg.sender] -= amount).
  • Interactions: Perform external calls to other contracts or addresses.

Following CEI helps prevent various attacks, including reentrancy, by ensuring your contract's state is finalized *before* external calls.

CEI in Withdrawal Function

Notice how our SecureBank's withdraw function already follows the CEI pattern:

  • Checks: require(balances[msg.sender] >= _amount, ...) and require(!_locked, ...) from the modifier.
  • Effects: balances[msg.sender] -= _amount; updates the state.
  • Interactions: msg.sender.call{value: _amount}(""); performs the external transfer.

This order is crucial for preventing reentrancy and ensuring consistent state.

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

contract CEIDemo {
    mapping(address => uint) public balances;
    bool private _locked;

    modifier nonReentrant() {
        require(!_locked, "Reentrant call detected");
        _locked = true;
        _;
        _locked = false;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint _amount) public nonReentrant {
        // --- CHECKS ---
        require(balances[msg.sender] >= _amount, "Insufficient balance");

        // --- EFFECTS ---
        balances[msg.sender] -= _amount; // State updated BEFORE external call

        // --- INTERACTIONS ---
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success, "Failed to send Ether");
    }
}

Restricting Access

Not all functions in a smart contract should be callable by everyone. Access control ensures that only authorized addresses or roles can execute specific sensitive operations.

Common examples include:

  • An onlyOwner modifier for administrative functions.
  • Role-based access control (RBAC) where different roles (e.g., MINTER, PAUSER) have specific permissions.

Proper access control is vital to prevent unauthorized actions and maintain contract integrity.

Owner-Restricted Function

Here's how to implement a simple onlyOwner access control using a modifier. The contract stores the deployer's address as the owner, and only this address can call the setNewAdmin function.

This pattern is widely used for critical administrative functions.

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

contract AccessControlled {
    address public owner;
    address public admin;

    constructor() {
        owner = msg.sender; // Deployer is the owner
        admin = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only owner can call this function");
        _;
    }

    function setNewAdmin(address _newAdmin) public onlyOwner {
        admin = _newAdmin;
    }

    function getAdmin() public view returns (address) {
        return admin;
    }
}

Security Best Practices Check

You've learned about reentrancy, the CEI pattern, and access control. Which of the following statements are true regarding secure smart contract development?

Recap: Secure Contracts

Great job! You've grasped fundamental smart contract security practices:

  • Reentrancy: A critical vulnerability where external calls can "re-enter" a function before state updates.
  • Reentrancy Guards: Mechanisms (like mutexes or modifiers) to lock contract state during external calls.
  • CEI Pattern: The recommended order of operations (Checks, Effects, Interactions) to ensure state is updated before external calls.
  • Access Control: Restricting sensitive functions to authorized addresses, often using onlyOwner modifiers.

These practices are crucial for building robust and trustworthy decentralized applications. Keep practicing and stay vigilant!

よくある質問

「コントラクトのセキュリティベストプラクティス」レッスンは無料ですか？

はい。「コントラクトのセキュリティベストプラクティス」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Web3 & DApp Development Fundamentalsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Web3 & DApp Development Fundamentalsコースには全3レッスンが含まれています。

「コントラクトのセキュリティベストプラクティス」で何を学びますか？

リエントランシーガード、checks-effects-interactionsパターン、アクセス制御など、スマートコントラクト開発に不可欠なセキュリティ対策を学びます。 ブラウザで直接実行するハンズオンコードでWeb3 & DApp Development Fundamentalsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Web3 & DApp Development Fundamentalsを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのWeb3 & DApp Development Fundamentalsは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン2/3です。

「コントラクトのセキュリティベストプラクティス」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このWeb3 & DApp Development Fundamentalsレッスンでコードを書いて実行できますか？

はい。すべてのWeb3 & DApp Development Fundamentalsレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. ERC規格（ERC-20、ERC-721）
  2. コントラクトのセキュリティベストプラクティス
  3. アップグレード可能なコントラクト
← Web3 & DApp Development Fundamentalsに戻る