Access control patterns in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Solidity contract function?

Consider the following Solidity contract snippet that implements a simple role-based access control. What will be the output when checkAccess is called by address 0x123?

Blockchain / Solidity

pragma solidity ^0.8.0;

contract AccessControl {
    mapping(address => bool) public admins;

    constructor() {
        admins[msg.sender] = true;
    }

    function checkAccess(address user) public view returns (string memory) {
        if (admins[user]) {
            return "Access granted";
        } else {
            return "Access denied";
        }
    }
}

A "Access granted"

B "Access denied"

C Compilation error

D Runtime error

💡 Hint

Remember that only the contract deployer is set as admin in the constructor.

The constructor sets msg.sender as admin. Since 0x123 is not the deployer, admins[0x123] is false, so the function returns "Access denied".

🧠 Conceptual

intermediate

Which access control pattern is demonstrated by this smart contract snippet?

This contract uses a mapping of addresses to booleans to control who can call certain functions. What is this pattern called?

Blockchain / Solidity

mapping(address => bool) private whitelist;

function addToWhitelist(address user) public onlyOwner {
    whitelist[user] = true;
}

modifier onlyWhitelisted() {
    require(whitelist[msg.sender], "Not whitelisted");
    _;
}

A Capability-based access control

B Role-based access control

C Whitelist access control

D Discretionary access control

💡 Hint

Think about the list of allowed users explicitly stored.

This pattern uses a whitelist, a list of allowed addresses, to control access. Only addresses in the whitelist can call protected functions.

🔧 Debug

advanced

Why does this smart contract fail to restrict access properly?

Examine the following Solidity code. Why can anyone call restrictedFunction even though it is supposed to be restricted?

Blockchain / Solidity

pragma solidity ^0.8.0;

contract FaultyAccess {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(owner == msg.sender);
        _;
    }

    function restrictedFunction() public onlyOwner {
        // restricted logic
    }

    function changeOwner(address newOwner) public {
        owner = newOwner;
    }
}

A Anyone can call changeOwner and set themselves as owner, bypassing restriction

B The constructor does not set the owner correctly

C The modifier onlyOwner is missing a revert message, so it does not revert on failure

D The restrictedFunction is not marked as public

💡 Hint

Check who can call changeOwner and what it does.

The changeOwner function is public and unprotected, so anyone can call it to become the owner. This breaks the access control.

📝 Syntax

advanced

Which option correctly implements a modifier to restrict access to an admin role?

Choose the correct Solidity code snippet that defines a modifier onlyAdmin which restricts function access to addresses marked as admins in a mapping.

A

modifier onlyAdmin() {
    if (!admins[msg.sender]) {
        revert("Not admin");
    }
}

B

modifier onlyAdmin() {
    if (admins[msg.sender]) {
        _;
    } else {
        revert("Not admin");
    }
}

C

modifier onlyAdmin() {
    require(admins[msg.sender] == true);
}

D

modifier onlyAdmin() {
    require(admins[msg.sender], "Not admin");
    _;
}

💡 Hint

Modifiers must include _; to continue execution.

Option D correctly uses require with a message and includes _; to continue function execution. Option D is valid but less common. Option D lacks _;. Option D lacks _; and will block all calls.

🚀 Application

expert

How many addresses have access after running this smart contract code?

Given the following Solidity contract, how many addresses will have access after deploying and calling grantAccess three times with different addresses?

Blockchain / Solidity

pragma solidity ^0.8.0;

contract MultiAccess {
    mapping(address => bool) private accessList;

    function grantAccess(address user) public {
        accessList[user] = true;
    }

    function hasAccess(address user) public view returns (bool) {
        return accessList[user];
    }
}

A 3

B 0

C 1

D Cannot determine without knowing the addresses

💡 Hint

Each call to grantAccess sets one address to true in the mapping.

Each call to grantAccess adds one address to the accessList. After three calls with different addresses, three addresses have access.

Practice

1. What is the main purpose of access control patterns in blockchain smart contracts?

easy

A. To restrict who can perform certain actions on the blockchain

B. To increase the speed of blockchain transactions

C. To store large amounts of data efficiently

D. To create new cryptocurrencies automatically

Solution

1. Step 1: Understand access control concept

   Access control limits permissions, deciding who can do what on the blockchain.

2. Step 2: Identify the main goal

   The goal is to protect blockchain data and functions by restricting unauthorized actions.

3. Final Answer:

   To restrict who can perform certain actions on the blockchain -> Option A

4. Quick Check:

   Access control = restrict actions [OK]

Hint: Access control means who can do what, not speed or storage [OK]

Common Mistakes:

• Confusing access control with transaction speed
• Thinking access control stores data
• Assuming access control creates cryptocurrencies

2. Which of the following is the correct Solidity syntax to define a modifier named onlyOwner for access control?

easy

A. modifier onlyOwner() => { require(msg.sender == owner); _; }

B. function onlyOwner() { require(msg.sender == owner); }

C. modifier onlyOwner { if(msg.sender == owner) _; }

D. modifier onlyOwner() { require(msg.sender == owner); _; }

Solution

1. Step 1: Recall modifier syntax in Solidity

   A modifier uses the keyword 'modifier', parentheses for parameters, and the '_;' placeholder.

2. Step 2: Check each option

   modifier onlyOwner() { require(msg.sender == owner); _; } correctly uses 'modifier onlyOwner() { require(msg.sender == owner); _; }'. Others have syntax errors or missing parts.

3. Final Answer:

   modifier onlyOwner() { require(msg.sender == owner); _; } -> Option D

4. Quick Check:

   Modifier syntax = modifier onlyOwner() { require(msg.sender == owner); _; } [OK]

Hint: Modifiers need 'modifier', parentheses, and '_;' inside [OK]

Common Mistakes:

• Using 'function' instead of 'modifier'
• Omitting parentheses after modifier name
• Using arrow syntax which is invalid here

3. Consider this Solidity snippet:

mapping(address => bool) public admins;

modifier onlyAdmin() {
  require(admins[msg.sender], "Not admin");
  _;
}

function addAdmin(address newAdmin) public onlyAdmin {
  admins[newAdmin] = true;
}

constructor() {
  admins[msg.sender] = true;
}

What happens if a non-admin calls addAdmin?

medium

A. The contract crashes and becomes unusable

B. The transaction reverts with error 'Not admin'

C. The function runs but does nothing

D. The new admin is added successfully

Solution

1. Step 1: Understand the onlyAdmin modifier

   The modifier requires that the caller's address is in the admins mapping as true, else it reverts with "Not admin".

2. Step 2: Analyze calling addAdmin by non-admin

   If the caller is not an admin, require fails, causing the transaction to revert with the error message.

3. Final Answer:

   The transaction reverts with error 'Not admin' -> Option B

4. Quick Check:

   Non-admin call triggers require revert [OK]

Hint: Require false causes revert with error message [OK]

Common Mistakes:

• Assuming function silently fails
• Thinking non-admin can add admins
• Believing contract crashes permanently

4. Identify the bug in this Solidity access control code:

address public owner;

modifier onlyOwner() {
  require(msg.sender = owner, "Not owner");
  _;
}

constructor() {
  owner = msg.sender;
}

medium

A. Missing semicolon after owner declaration

B. Constructor should be named differently

C. Using assignment '=' instead of comparison '==' in require

D. Modifier missing parentheses

Solution

1. Step 1: Check require statement syntax

   The require uses '=' which assigns, not '==' which compares. This causes a compile error or unexpected behavior.

2. Step 2: Verify other parts

   Semicolon is present, constructor name is correct, and modifier has parentheses, so no issues there.

3. Final Answer:

   Using assignment '=' instead of comparison '==' in require -> Option C

4. Quick Check:

   Use '==' for comparison in require [OK]

Hint: Use '==' to compare, '=' is assignment [OK]

Common Mistakes:

• Confusing '=' and '==' in conditions
• Thinking constructor name must differ
• Ignoring parentheses in modifier

5. You want to implement a multi-level access control in Solidity where: - The contract owner can add or remove admins. - Admins can add or remove users. - Users can only call a restricted function. Which pattern best fits this scenario?

hard

A. Use nested mappings with modifiers for owner, admin, and user roles

B. Use a single boolean mapping for all roles and check in functions

C. Use public variables for roles without modifiers

D. Use events only to track roles without restrictions

Solution

1. Step 1: Understand multi-level access control needs

   Different roles require different permissions; owner controls admins, admins control users, users have limited access.

2. Step 2: Evaluate patterns

   Nested mappings with modifiers (Use nested mappings with modifiers for owner, admin, and user roles) is complex but correct. Single boolean mapping (Use a single boolean mapping for all roles and check in functions) cannot distinguish roles well. Public variables without modifiers (Use public variables for roles without modifiers) is insecure and insufficient. Events only (Use events only to track roles without restrictions) do not enforce control.

3. Step 3: Choose best practical pattern

   Nested mappings with modifiers provide clear, secure role checks and control flow.

4. Final Answer:

   Use nested mappings with modifiers for owner, admin, and user roles -> Option A

5. Quick Check:

   Multi-level roles need nested mappings + modifiers [OK]

Hint: Use nested mappings and modifiers for clear role control [OK]

Common Mistakes:

• Using single mapping for all roles
• Skipping modifiers for access checks
• Relying only on events without restrictions