Skip to content

Commit 8ef08ce

Browse files
nhussein11eshaben
andcommitted
Create "Accounts" page in sc basics section (#385)
* fix: wip * fix: singular to smart contract basics * fix: wording and links * fix: wording * Apply suggestions from code review Co-authored-by: Erin Shaben <[email protected]> * fix: updating .pages titles * fix: updating intro * Update polkadot-protocol/smart-contract-basics/accounts.md Co-authored-by: Erin Shaben <[email protected]> --------- Co-authored-by: Erin Shaben <[email protected]>
1 parent ad9410b commit 8ef08ce

File tree

9 files changed

+100
-14
lines changed

9 files changed

+100
-14
lines changed

polkadot-protocol/.pages

+1-1
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,6 @@ nav:
33
- index.md
44
- architecture
55
- parachain-basics
6-
- smart-contracts-basics
6+
- smart-contract-basics
77
- onchain-governance
88
- 'Glossary': glossary.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
title: Smart Contract Basics
2+
nav:
3+
- index.md
4+
- 'Overview': overview.md
5+
- 'PolkaVM Design': polkavm-design.md
6+
- 'EVM vs PolkaVM': evm-vs-polkavm.md
7+
- 'Accounts': accounts.md
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
---
2+
title: Accounts in Asset Hub Smart Contracts
3+
description: Bridges Ethereum's 20-byte addresses with Polkadot's 32-byte accounts, enabling seamless interaction while maintaining compatibility with Ethereum tooling.
4+
---
5+
6+
# Accounts on Asset Hub Smart Contracts
7+
8+
## Introduction
9+
10+
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:
11+
12+
- EVM-compatible wallets (like MetaMask) can use their familiar 20-byte addresses
13+
- Polkadot accounts continue using their native 32-byte format
14+
- The Asset Hub chain automatically handles conversion between the two formats behind the scenes:
15+
16+
- 20-byte Ethereum addresses are padded with `0xEE` bytes to create valid 32-byte Polkadot accounts
17+
- 32-byte Polkadot accounts can optionally register a mapping to a 20-byte address for Ethereum compatibility
18+
19+
This dual-format approach enables Asset Hub to maintain compatibility with Ethereum tooling while fully integrating with the Polkadot ecosystem.
20+
21+
## Address Types and Mappings
22+
23+
The platform handles two distinct address formats:
24+
25+
- [Ethereum-style addresses (20 bytes)](https://ethereum.org/en/developers/docs/accounts/#account-creation){target=\_blank}
26+
- [Polkadot native account IDs (32 bytes)](https://wiki.polkadot.network/docs/build-protocol-info#addresses){target=\_blank}
27+
28+
### Ethereum to Polkadot Mapping
29+
30+
The [`AccountId32Mapper`](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/struct.AccountId32Mapper.html){target=\_blank} implementation in [`pallet_revive`](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/index.html){target=\_blank} 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:
31+
32+
- [**Core mechanism**](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/trait.AddressMapper.html#tymethod.to_fallback_account_id){target=\_blank} - 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:
33+
- Able to fully revert, allowing a smooth transition back to the Ethereum format
34+
- Provides clear identification of Ethereum-controlled accounts through the `0xEE` suffix pattern
35+
- Maintains cryptographic security with a `2^96` difficulty for pattern reproduction
36+
37+
### Polkadot to Ethereum Mapping
38+
39+
The conversion from 32-byte to 20-byte addresses is handled through a stateful mapping system implemented in the [`AddressMapper`](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/trait.AddressMapper.html){target=\_blank} trait. The core functionality includes:
40+
41+
- Address conversion in both directions
42+
- Account registration and management
43+
- Mapping status verification
44+
45+
## Account Registration
46+
47+
The registration process is implemented through the [`map`](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/trait.AddressMapper.html#tymethod.map){target=\_blank} function. This process involves:
48+
49+
- Checking if the account is already mapped
50+
- Calculating and collecting required deposits based on data size
51+
- Storing the address suffix for future reference
52+
- Managing the currency holds for security
53+
54+
## Fallback Accounts
55+
56+
The fallback mechanism is integrated into the [`to_account_id`](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/trait.AddressMapper.html#tymethod.to_account_id){target=\_blank} function. It provides a safety net for address conversion by:
57+
58+
- First, attempting to retrieve stored mapping data
59+
- Falling back to the default conversion method if no mapping exists
60+
- Maintaining consistency in address representation
61+
62+
## Contract Address Generation
63+
64+
The system supports two methods for generating contract addresses:
65+
66+
- [**CREATE1 method**](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/fn.create1.html){target=\_blank}:
67+
68+
- Uses the deployer address and nonce
69+
- Generates deterministic addresses for standard contract deployment
70+
71+
- [**CREATE2 method**](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/fn.create2.html){target=\_blank}:
72+
73+
- Uses the deployer address, initialization code, input data, and salt
74+
- Enables predictable address generation for advanced use cases
75+
76+
## Security Considerations
77+
78+
The address mapping system maintains security through several design choices evident in the implementation:
79+
80+
- The stateless mapping requires no privileged operations, as shown in the [`to_fallback_account_id`](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/trait.AddressMapper.html#tymethod.to_fallback_account_id){target=\_blank} implementation
81+
- The stateful mapping requires a deposit managed through the [`Currency`](https://paritytech.github.io/polkadot-sdk/master/pallet_revive/pallet/trait.Config.html#associatedtype.Currency){target=\_blank} trait
82+
- Mapping operations are protected against common errors through explicit checks
83+
- The system prevents double-mapping through the [`ensure!(!Self::is_mapped(account_id))`](https://github.com/paritytech/polkadot-sdk/blob/stable2412/substrate/frame/revive/src/address.rs#L125){target=\_blank} check
84+
85+
All source code references are from the [`address.rs`](https://github.com/paritytech/polkadot-sdk/blob/stable2412/substrate/frame/revive/src/address.rs){target=\_blank} file in the Revive pallet of the Polkadot SDK repository.
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
---
2+
title: Smart Contract Basics
3+
description: TODO
4+
template: index-page.html
5+
---
6+
7+
# Smart Contract Basics

polkadot-protocol/smart-contracts-basics/.pages

-6
This file was deleted.

polkadot-protocol/smart-contracts-basics/index.md

-7
This file was deleted.

0 commit comments

Comments
 (0)