แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยของสัญญา

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!