Access control patterns in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Access control patterns

User requests access

↓

Check access control pattern

↓

Role-based

↓

Verify role

↓

Grant or deny access

User requests access, system checks the chosen access control pattern (role, attribute, or capability), verifies permissions, then grants or denies access.

Execution Sample

Blockchain / Solidity

contract AccessControl {
  mapping(address => string) roles;
  function setRole(address user, string memory role) public {
    roles[user] = role;
  }
  function canAccess(address user) public view returns (bool) {
    return keccak256(bytes(roles[user])) == keccak256(bytes("admin"));
  }
}

A simple role-based access control contract that assigns roles and checks if a user is an admin.

Execution Table

Step	Action	Variable/State	Evaluation	Result
1	Assign role 'admin' to user 0xABC	roles[0xABC]	Set to 'admin'	Role set
2	Check access for user 0xABC	roles[0xABC]	Compare 'admin' == 'admin'	True
3	Check access for user 0xDEF	roles[0xDEF]	Compare '' == 'admin'	False
4	User 0xABC requests access	canAccess(0xABC)	Returns True	Access granted
5	User 0xDEF requests access	canAccess(0xDEF)	Returns False	Access denied

💡 Access granted only if user role matches 'admin'; otherwise denied.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
roles[0xABC]	''	'admin'	'admin'	'admin'	'admin'
roles[0xDEF]	''	''	''	''	''

Key Moments - 2 Insights

Why does user 0xDEF get denied access even though roles[0xDEF] exists?

Because roles[0xDEF] is empty string (''), which does not match 'admin' in the access check (see execution_table step 3).

What happens if we assign a different role than 'admin' to a user?

The access check compares the role to 'admin', so any other role will cause access denial (see execution_table step 3 logic).

Visual Quiz - 3 Questions

Look at the execution table, what is the value of roles[0xABC] after step 1?

A 'user'

B 'admin'

C ''

D undefined

💡 Hint

Check the 'Variable/State' column in step 1 for roles[0xABC].

At which step does the access check return false for user 0xDEF?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Evaluation' and 'Result' columns for user 0xDEF in the execution table.

If we change the role check to 'user' instead of 'admin', what happens at step 4 for user 0xABC?

A Access denied

B Access granted

C Error occurs

D No change

💡 Hint

Since roles[0xABC] is 'admin', checking for 'user' will fail the comparison.

Concept Snapshot

Access control patterns manage who can do what.
Common types: Role-Based (RBAC), Attribute-Based (ABAC), Capability-Based.
RBAC assigns roles to users and checks roles.
ABAC checks user attributes like age or location.
Capability-based uses tokens granting specific rights.
Access is granted only if checks pass.

Full Transcript

This visual trace shows how access control patterns work in blockchain contracts. The user requests access, and the system checks the user's role. If the role matches the required one, access is granted; otherwise, it is denied. The example contract assigns roles to addresses and checks if a user is an admin. The execution table walks through assigning roles and checking access for two users, showing when access is granted or denied. Key moments clarify why some users are denied access and how role checks affect outcomes. The quiz tests understanding of variable states and access decisions at each step.