Accounts on Asset Hub Smart Contracts

Introduction

Asset Hub natively uses Polkadot's 32-byte account system but provides interoperability with Ethereum's 20-byte addresses through an automatic conversion system. When interacting with smart contracts:

• EVM-compatible wallets (like MetaMask) can use their familiar 20-byte addresses
• Polkadot accounts continue using their native 32-byte format

• The Asset Hub chain automatically handles conversion between the two formats behind the scenes:

  • 20-byte Ethereum addresses are padded with 0xEE bytes to create valid 32-byte Polkadot accounts
  • 32-byte Polkadot accounts can optionally register a mapping to a 20-byte address for Ethereum compatibility

This dual-format approach enables Asset Hub to maintain compatibility with Ethereum tooling while fully integrating with the Polkadot ecosystem.

Address Types and Mappings

The platform handles two distinct address formats:

• Ethereum-style addresses (20 bytes)
• Polkadot native account IDs (32 bytes)

Ethereum to Polkadot Mapping

The AccountId32Mapper implementation in pallet_revive handles the core address conversion logic. For converting a 20-byte Ethereum address to a 32-byte Polkadot address, the pallet uses a simple concatenation approach:

• Core mechanism - takes a 20-byte Ethereum address and extends it to 32 bytes by adding twelve 0xEE bytes at the end. The key benefits of this approach are:
  • Able to fully revert, allowing a smooth transition back to the Ethereum format
  • Provides clear identification of Ethereum-controlled accounts through the 0xEE suffix pattern
  • Maintains cryptographic security with a 2^96 difficulty for pattern reproduction

Polkadot to Ethereum Mapping

The conversion from 32-byte to 20-byte addresses is handled through a stateful mapping system implemented in the AddressMapper trait. The core functionality includes:

• Address conversion in both directions
• Account registration and management
• Mapping status verification

Account Registration

The registration process is implemented through the map function. This process involves:

• Checking if the account is already mapped
• Calculating and collecting required deposits based on data size
• Storing the address suffix for future reference
• Managing the currency holds for security

Fallback Accounts

The fallback mechanism is integrated into the to_account_id function. It provides a safety net for address conversion by:

• First, attempting to retrieve stored mapping data
• Falling back to the default conversion method if no mapping exists
• Maintaining consistency in address representation

Contract Address Generation

The system supports two methods for generating contract addresses:

• CREATE1 method:

  • Uses the deployer address and nonce
  • Generates deterministic addresses for standard contract deployment

• CREATE2 method:

  • Uses the deployer address, initialization code, input data, and salt
  • Enables predictable address generation for advanced use cases

Security Considerations

The address mapping system maintains security through several design choices evident in the implementation:

• The stateless mapping requires no privileged operations, as shown in the to_fallback_account_id implementation
• The stateful mapping requires a deposit managed through the Currency trait
• Mapping operations are protected against common errors through explicit checks
• The system prevents double-mapping through the ensure!(!Self::is_mapped(account_id)) check

All source code references are from the address.rs file in the Revive pallet of the Polkadot SDK repository.

Last update: March 6, 2025
| Created: March 6, 2025