Substrate & EVM address
Substrate
Substrate is an SDK and a framework that allows developers to create their own customized blockchain nodes. The blockchain node and network developed using Substrate are what we call a substrate-based blockchain.
Some of the popular Substrate-based blockchains are Polkadot, Moonbeam.
Ethereum-compatible Blockchain
Ethereum-compatible blockchains implement the EVM (Ethereum Virtual Machine). EVM is a state machine that defines how the blockchain state should be changed from block to block. EVM is where the smart contracts are executed and the blockchain transactions are generated.
Smart contracts are programs stored on a blockchain that run when invoked through qualified external accounts. Solidity is the most popular language used to write smart contracts on Ethereum and Ethereum-compatible blockchains.
Some of the popular Ethereum-compatible blockchains are Binance Smart Chain, Avalanche, Harmony, etc.
Blockchain Accounts
In an abstract sense, accounts in blockchain are actors or entities that are able to perform certain actions or transactions on the blockchain. Similar to how user accounts are identified by their username and password, blockchain accounts are represented by their public/private key pairs, where the public key is analogous to a username and the private key is like a password for that account. Different blockchain networks may generate these key pairs using different cryptographic algorithms and encoding formats.
Substrate supports different algorithms like ECDSA, Ed25519, and SR25519 to generate key pairs while EVM based blockchains only supports ECDSA.
Blockchain Addresses
A blockchain address can be thought like a bank account for crypto assets. Encoding raw bytes of the public key of an account results in a human-readable string, which is regarded as the address of that account. A blockchain address can be reverse mapped to the account it represents.
Ethereum uses Keccak256 hash function to generate 20-byte addresses of H160 format, from the public key of the account. Substrate uses Blake256 hash function to generate addresses of format SS58.
This difference in address format poses a challenge to interoperability between EVM-based blockchains and Substrate-based blockchains.
H160 address
H160 addresses are 42 hex-characters long.
Example: 0x027e99362a6b2EdCcC9341A4b49f639e4F26D34F
On Substrate, each EVM account is backed by a native Substrate account.
SS58 address
SS58 is a simple address format designed for Substrate based chains. SS58 address is base58 encoding of an account’s 32 byte Substrate public key.
By default, SS58 address start with number 1 but this can be customized by blockchain developers ( For eg: Polkadot addresses always start with the number 1).
Eg: 5DAAnrj7VHTznn2AWBemMuyBwZWs6FNFjdyVXUeYum3PTXFy (public key: 0x306721211d5404bd9da88e0204360a1a9ab8b87c66c1bc2fcdd37f3c2222cc20)
The conversion between 32 byte public key and SS58 representation of an account can be done using the Subkey tool.
EVM on Substrate
Substrate has an Ethereum compatibility layer, called Frontier, which brings EVM into Substrate-based blockchains. This allows users to use their metamask wallets for doing transactions and enables developers to use Solidity for writing smart contracts and using web3.js and Ethers.js libraries for interacting with the blockchain.
EVM in Substrate-based blockchains runs as a sandboxed runtime which makes it more secure as well. The transaction and state mutations from EVM are saved contiguously with the native Substrate state as well but it can’t directly modify the state of the native blockchain. However, the native blockchain can access EVM’s data. In short, EVM lives on the native blockchain as a subset of Ethereum compatible services. The extrinsic exposed by EVM can be called and browsed via any Ethereum compliant client.
Though it has these leverages, the challenge is interoperability between EVM accounts and native Substrate accounts due to the above-mentioned differences in addresses.
The current implementation that allows us to overcome this obstacle is as follows:
Account Conversion and Mapping
H160 to SS58 address mapping
The balance of all H160 accounts are tied with the native Substrate account which is referred to as Proxy Substrate account.
The generated proxy substrate account does not have a private key hence it is unable to sign any transaction but is able to receive and hold the balance. Any Substrate account can directly transfer funds to it. The funds associated with this proxy substrate account represents funds for its equivalent Ethereum (H160) address as well.
The funds in the proxy Substrate addressed can only be withdrawn by the original Substrate account by calling withdraw function.
Mapping from EVM to its Proxy Substrate type account can be done in many ways.
- ACALA has a way to do two way address mapping so that user has to just deal with one account & private key.
- Moonbeam has the concept of unified accounts, which enables users to do transactions on both Substrate side and EVM side with the same H160 account.
- Similarly, other Substrate based chain have their own implementation of the mapping. However, the default and the most popular one is Hash Truncated Hash Mapping which is also implemented on the Frost test-network. The steps for this mapping are as follows:
- Prefix ethereum address (buffer) with hex equivalent of string “evm:”
- Hash (Blake-2b is widely used) the above result. This gives the Substrate public key.
- Base-58 encode the above public key to get the SS58
SS58 to H160 address mapping
H160 address is simply the first 20 bytes of the Substrate public key. This mapping is direct and deterministic which simplifies the address translation.
Eg:
The SS58 address 5DAAnrj7VHTznn2AWBemMuyBwZWs6FNFjdyVXUeYum3PTXFy has 32 byte public key 0x306721211d5404bd9da88e0204360a1a9ab8b87c66c1bc2fcdd37f3c2222cc20.
This account’s equivalent Ethereum address will be 0x306721211d5404bd9da88e0204360a1a9ab8b87c.
JavaScript implmentation of both these conversions can be found here.