Access Control Implementation

Access Control Implementation

The role-based access control system is implemented using OpenZeppelin's AccessControl and AccessControlUpgradeable contracts. This provides a standardized and audited approach to role management.

CanonicalBridge Role Flow

Code Implementation: The role checks are implemented using modifiers in the CanonicalBridge contract:

// Example role check implementation
function authorizeWithdraw(WithdrawMessage calldata message) 
    external 
    onlyRole(WITHDRAW_AUTHORITY_ROLE) 
    whenNotPaused 
{
    // Implementation details
}

This pattern ensures that only authorized entities can perform sensitive operations. The onlyRole modifier checks that the caller has the required role before executing the function body.

Treasury Role Flow

Technical Implementation Details:

• Role Definition: Roles are defined as bytes32 constants using keccak256 hashes:

  bytes32 public constant DEPOSITOR_ROLE = keccak256("DEPOSITOR_ROLE");
  bytes32 public constant WITHDRAW_AUTHORITY_ROLE = keccak256("WITHDRAW_AUTHORITY_ROLE");

• Role Storage: Role assignments are stored in a mapping structure that tracks which addresses have which roles.

• Role Checks: Role checks are performed using the onlyRole modifier, which reverts the transaction if the caller doesn't have the required role.

• Administrative Control: The DEFAULT_ADMIN_ROLE has the authority to grant and revoke all other roles, providing centralized role management.

Administrative Functions Deep Dive

Role Management

The DEFAULT_ADMIN_ROLE has the authority to grant and revoke all other roles. This is implemented using OpenZeppelin's AccessControl contract:

// Grant a role
function grantRole(bytes32 role, address account) 
    public 
    override 
    onlyRole(getRoleAdmin(role)) 
{
    _grantRole(role, account);
}

// Revoke a role
function revokeRole(bytes32 role, address account) 
    public 
    override 
    onlyRole(getRoleAdmin(role)) 
{
    _revokeRole(role, account);
}

These functions ensure that only authorized entities can modify role assignments. The getRoleAdmin function returns the admin role for a given role, which is typically the DEFAULT_ADMIN_ROLE.

System Upgrades

The Treasury contract implements the UUPS (Universal Upgradeable Proxy Standard) pattern for upgradeability:

// Upgrade implementation
function _authorizeUpgrade(address newImplementation) 
    internal 
    override 
    onlyRole(UPGRADER_ROLE) 
{
    // Additional upgrade logic if needed
}

This function is called during the upgrade process and ensures that only entities with the UPGRADER_ROLE can upgrade the contract. The UUPS pattern allows for upgrading the contract logic while maintaining the same contract address and state.

Emergency Controls

The PAUSER_ROLE and STARTER_ROLE control the operational state of the contracts:

// Pause operations
function pause() 
    external 
    onlyRole(PAUSER_ROLE) 
{
    _pause();
}

// Unpause operations
function unpause() 
    external 
    onlyRole(STARTER_ROLE) 
{
    _unpause();
}

These functions allow for quickly pausing the contract in emergency situations and resuming operations when the emergency is resolved. The separation of these roles ensures that a single compromised entity cannot both pause and unpause the contract.

Withdrawal Authorization

The WITHDRAW_AUTHORITY_ROLE authorizes withdrawals:

function authorizeWithdraw(WithdrawMessage calldata message) 
    external 
    onlyRole(WITHDRAW_AUTHORITY_ROLE) 
    whenNotPaused 
{
    // Validate message
    // Start fraud window
    // Emit event
}

This function is called by the Withdrawal Relayer to initiate the withdrawal process. It validates the withdrawal message, starts the fraud window, and emits an event for tracking. The role restriction ensures that only authorized entities can initiate withdrawals.

Withdrawal Cancellation

The WITHDRAW_CANCELLER_ROLE can cancel suspicious withdrawals:

function deleteWithdrawMessage(WithdrawMessage calldata message) 
    external 
    onlyRole(WITHDRAW_CANCELLER_ROLE) 
{
    // Validate message exists
    // Delete message
    // Emit event
}

This function allows the Bridge Troll to cancel suspicious withdrawals during the fraud window. It validates that the withdrawal exists, deletes it from the system, and emits an event for tracking. This provides a critical security mechanism for preventing fraudulent withdrawals.

Security Configuration

The FRAUD_WINDOW_SETTER_ROLE configures the fraud window duration:

function setFraudWindowDuration(uint256 durationSeconds) 
    external 
    onlyRole(FRAUD_WINDOW_SETTER_ROLE) 
{
    // Validate duration (minimum 1 day)
    // Set new duration
    // Emit event
}

This function allows for adjusting the fraud window duration based on security needs. It enforces a minimum duration of 1 day to ensure a reasonable security buffer and emits an event for tracking. The role restriction ensures that only authorized entities can modify this critical security parameter.