Checks-Effects-Interactions pattern in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a simple withdrawal function using Checks-Effects-Interactions

What is the output when calling withdraw(50) on this contract if the initial balance is 100?

Blockchain / Solidity

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

    constructor() {
        balances[msg.sender] = 100;
    }

    function withdraw(uint amount) public returns (string memory) {
        require(balances[msg.sender] >= amount, "Insufficient balance"); // Check
        balances[msg.sender] -= amount; // Effect
        (bool success, ) = msg.sender.call{value: amount}(""); // Interaction
        require(success, "Transfer failed");
        return "Withdrawal successful";
    }

    receive() external payable {}
}

A Revert with "Transfer failed"

B Revert with "Insufficient balance"

C "Withdrawal successful"

D No output, transaction runs out of gas

💡 Hint

Think about the order: check balance, update balance, then send funds.

The function first checks if the sender has enough balance, then reduces it, and finally sends the amount. Since the initial balance is 100 and withdrawal is 50, all steps succeed and the function returns "Withdrawal successful".

❓ Predict Output

intermediate

Effect of changing order in Checks-Effects-Interactions

What happens if the withdraw function sends funds before updating the balance?

Blockchain / Solidity

function withdraw(uint amount) public returns (string memory) {
    require(balances[msg.sender] >= amount, "Insufficient balance"); // Check
    (bool success, ) = msg.sender.call{value: amount}(""); // Interaction
    require(success, "Transfer failed");
    balances[msg.sender] -= amount; // Effect
    return "Withdrawal successful";
}

A Safe because balance is checked first

B Vulnerable to reentrancy attack, balance not updated before sending funds

C Transaction always reverts due to order

D No difference from original function

💡 Hint

Consider what happens if the receiver calls back into withdraw before balance changes.

Sending funds before updating balance allows the receiver to call withdraw again before balance is reduced, causing multiple withdrawals and a reentrancy attack.

🔧 Debug

advanced

Identify the bug in this contract violating Checks-Effects-Interactions

Which line causes a security risk violating the Checks-Effects-Interactions pattern?

Blockchain / Solidity

contract Vulnerable {
    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");
        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Failed to send Ether");
        balances[msg.sender] -= amount;
    }
}

A Line with call to msg.sender.call{value: amount}("")

B Line with require(balances[msg.sender] >= amount, "Insufficient balance")

C Line with balances[msg.sender] -= amount

D Line with balances[msg.sender] += msg.value

💡 Hint

Look for interaction before effect.

The call to send Ether happens before updating the balance, allowing reentrancy attacks. The effect (balance update) should happen before interaction.

🧠 Conceptual

advanced

Why is Checks-Effects-Interactions pattern important?

Which statement best explains the main reason for using the Checks-Effects-Interactions pattern in smart contracts?

A To prevent reentrancy attacks by updating state before external calls

B To reduce gas costs by minimizing external calls

C To allow multiple external calls before state changes

D To make contracts compatible with all Ethereum clients

💡 Hint

Think about what kind of attack this pattern helps avoid.

Updating the contract's state before making external calls prevents attackers from exploiting reentrancy by calling back into the contract before state changes.

🚀 Application

expert

How many times can a reentrant call withdraw funds in this contract?

Given this contract, how many times can a malicious contract reenter and withdraw funds before balance updates?

Blockchain / Solidity

contract ReentrancyExample {
    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");
        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Failed to send Ether");
        balances[msg.sender] -= amount;
    }
}

A Exactly twice, due to call stack limits

B Only once, because require prevents multiple calls

C Zero times, function reverts immediately

D Multiple times until contract runs out of gas or balance

💡 Hint

Consider that balance is updated after sending funds.

Because balance is updated after sending funds, the attacker can reenter multiple times withdrawing repeatedly until funds or gas run out.