Access control with OpenZeppelin in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Access control with OpenZeppelin

Contract starts

↓

Import AccessControl

↓

Define roles as bytes32

↓

Assign roles in constructor

↓

Function called

↓

Check if caller has role

↓

Execute

↓

End function

This flow shows how a contract imports OpenZeppelin's AccessControl, defines roles, assigns them, and checks roles before running functions.

Execution Sample

Blockchain / Solidity

import "@openzeppelin/contracts/access/AccessControl.sol";

contract MyContract is AccessControl {
    bytes32 public constant ADMIN_ROLE = keccak256("ADMIN_ROLE");

    constructor() {
        _grantRole(ADMIN_ROLE, msg.sender);
    }

    function adminFunction() public onlyRole(ADMIN_ROLE) {
        // admin-only logic
    }
}

This contract sets up an ADMIN_ROLE and restricts adminFunction to callers with that role.

Execution Table

Step	Action	Role Checked	Caller	Has Role?	Result
1	Contract deployed	ADMIN_ROLE	Deployer	Yes	Assign ADMIN_ROLE to deployer
2	Call adminFunction	ADMIN_ROLE	Deployer	Yes	Function executes
3	Call adminFunction	ADMIN_ROLE	Other user	No	Revert: AccessControl: account is missing role

💡 Execution stops when caller lacks required role and function reverts

Variable Tracker

Variable	Start	After Deployment	After Call 2	After Call 3
roles[ADMIN_ROLE][Deployer]	false	true	true	true
roles[ADMIN_ROLE][Other user]	false	false	false	false

Key Moments - 2 Insights

Why does the function revert when called by a user without the ADMIN_ROLE?

Because the execution_table row 3 shows the role check fails (Has Role? = No), so AccessControl reverts the call to prevent unauthorized access.

How is the ADMIN_ROLE assigned to the deployer?

Row 1 in execution_table shows that during deployment, _grantRole assigns ADMIN_ROLE to the deployer, setting roles[ADMIN_ROLE][Deployer] to true.

Visual Quiz - 3 Questions

Look at the execution_table, what happens at step 2 when the deployer calls adminFunction?

A The function reverts because the deployer lacks ADMIN_ROLE

B Nothing happens, the call is ignored

C The function executes because the deployer has ADMIN_ROLE

D The function executes but with limited permissions

💡 Hint

Check execution_table row 2 where Has Role? is Yes and Result is Function executes

At which step does the contract assign ADMIN_ROLE to the deployer?

A Step 1

B Step 2

C Step 3

D Never assigned

💡 Hint

Look at execution_table row 1 where Result says Assign ADMIN_ROLE to deployer

If we call adminFunction from a user without ADMIN_ROLE, what will the roles mapping show for that user?

A true

B false

C undefined

D null

💡 Hint

See variable_tracker row for roles[ADMIN_ROLE][Other user] which remains false

Concept Snapshot

AccessControl from OpenZeppelin manages roles.
Define roles as bytes32 constants.
Assign roles with _grantRole.
Use onlyRole modifier to restrict functions.
Calls revert if caller lacks role.
Secure and simple role-based access.

Full Transcript

This example shows how to use OpenZeppelin's AccessControl in Solidity. First, the contract imports AccessControl and defines a role ADMIN_ROLE as a bytes32 hash. In the constructor, the deployer is given the ADMIN_ROLE using _grantRole. When adminFunction is called, the onlyRole modifier checks if the caller has ADMIN_ROLE. If yes, the function runs; if no, the call reverts with an error. The execution table traces deployment and calls, showing role assignments and checks. The variable tracker shows how roles mapping changes. Key moments clarify why calls revert without roles and how roles are assigned. The quiz tests understanding of role checks and assignments. This pattern helps secure smart contracts by controlling who can call sensitive functions.