Access Substrate Functions Using Ethereum H160 Addresses
We believe the future will be a multi-chain one. As applications start to deploy across multiple blockchains, many users and apps will be coming from Ethereum. Given this, we believe Ethereum compatibility features are key enablers to make multi-chain deployments easier. As part of our work on Substrate-based Ethereum compatibility, we have made significant updates to the underlying account system on Moonbeam, replacing the default Substrate-style accounts and keys with Ethereum-style accounts and keys. These changes greatly improve the user experience when interacting with Moonbeam. And the fact that we could even make a low level change like this is a testament to the power of building on Substrate.
The Importance of Unifying the Accounts
Any parachain in the Polkadot ecosystem can offer a full EVM implementation, which provides the possibility of executing Solidity-based smart contracts with minimal to no changes. Substrate makes this integration possible, just plug the EVM pallet into your runtime for EVM support, and the Ethereum pallet with Frontier to have Ethereum RPC compatibility. The availability of these open-source modules that we have worked on with Parity has led multiple parachains to offer Ethereum compatibility on their chains.
But there is an important catch. With the configuration described above, a user (let’s say Alice) can have an Ethereum-style address (H160 format), which is 40+2 hex-characters long, in a Substrate based chain. This address matches a private key, which can be used to sign transactions in the Ethereum side of the chain. Furthermore, the address is mapped into a storage slot inside the Substrate Balance pallet to a Substrate-style address (H256 format). However, Alice only knows the private key of the H160 address, and not of the mapped version. Therefore, she is unable to send transactions with her H256 address and is limited only to do read-only operations through Substrate’s API. As a consequence, Alice needs another H256 address matching a different private key to be able to operate in the Substrate side of the chain, which include, among others, staking, balances, and governance. The following diagram illustrates this configuration.
This creates friction and a poor user experience for Alice. First, she has to move tokens to her H160 mapped H256 address to be able to make transactions and deploy contracts through the EVM. Second, she also needs to hold a balance in her other H256 address (which she has a different private key for) to use Substrate-based features. So in short, Alice needs a minimum of two private keys to have the best of both worlds.
Moonbeam’s focus is to create a fully Ethereum-compatible environment on Polkadot with the best user experience possible. This extends beyond the base Ethereum feature set, with additional features such as on-chain governance, staking, and cross-chain integrations.
In this context, PureStake recently announced a Unified Accounts implementation for Moonbeam, as part of the v3 upgrade of the Moonbase Alpha TestNet. With this configuration, a user (let’s call him Bob) will only need a single H160 address, with its corresponding private key, to do everything we mentioned above including both EVM and Substrate functions. The diagram for this new configuration looks as follows.
That is it, Bob only holds one private key that matches one address. He does not need to move balances between 2 different accounts and is able to access all the features with a single account and private key. We have standardized this single account to conform to the Ethereum-style H160 address and ECDSA key standards.
Polkadot JS Integration
With the introduction of Unified Accounts, the Polkadot JS Apps interface was updated as well so that it natively supports H160 addresses and ECDSA keys. To test this out in Polkadot JS Apps, we need to connect it to the Moonbase Alpha TestNet by clicking the top left corner logo and selecting Moonbase Alpha under Test Networks.
After switching, Polkadot JS site will not only connect to Moonbase Alpha, but it will also change its styling, to make a perfect match.
Import an H160 Account
Let’s see how we can import our already existing MetaMask account to Polkadot JS Apps. First, navigate to the accounts section, and click in the add account button.
This will open a wizard pop-up that will guide you through the process of adding an account to the Polkadot JS Apps interface. Make sure you click on the drop-down menu and change from Mnemonic to Private Key, this allows you to add an account through a private key.
Next, enter your private key that you can export from MetaMask, in this case I’m using an account with the following details:
- Private key: 28194e8ddb4a2f2b110ee69eaba1ee1f35e88da2222b5a7d6e3afa14cf7a3347
- Public address associated with it: 0x44236223aB4291b93EEd10E4B511B37a398DEE55.
Make sure to include the prefix in the private key, that is 0x. If you entered the information correctly, the corresponding public address should appear in the upper left corner of the window.
Click next and finish the wizard by setting an account name and password. After a confirmation message, you should see in the main Accounts tab the address with the corresponding balance, in our case Bob’s. Moreover, we can overlay the MetaMask extension to see that both balances are the same.
Now, let’s demonstrate the potential of Moonbeam’s Unified Accounts scheme by making a transfer through the Substrate API using the Polkadot JS Apps. Remember that we are talking about interacting with Substrate using an Ethereum-style H160 address. To do so, I’ve imported another account, named Charley with 5 DEV tokens.
So, let’s click on Bob’s send button, which opens another wizard that guides you through the process of sending a transaction. Set the send to address and the amount, which for our example is 5 DEV tokens. When ready click on the Make Transfer button.
After you sign the transaction using your password, Polkadot JS will display some messages on the top right corner while it’s being processed. Once confirmed, you should see the balances updated for each account.
The Unified Accounts implementation is taking all the headlines. But with the v3 release, there were several upgrades that came along, which include a lot of minor bug fixes.
Apart from that, the subscription to event logs functionality, that was implemented with the v2 release, now supports wildcards and conditional indexed parameters. This allows for better handling of contract event logs. For more information, you can visit this link .
Another important update was some changes in the Chain Id scheme. The Ethereum specification describes a numeric Chain Id system that, in general terms, helps transactions to be executed only in one network. Moonbeam nodes support multiple public chains and TestNets, with the following Chain Ids:
- Local Parachain TestNet: 1280
- Local Standalone Node: 1281
- Reserved for other TestNets: 1282–1283
- Moonbeam (Polkadot MainNet): 1284
- Moonriver (Kusama): 1285
- Moonrock (Rococo): 1286
- Moonbase Alpha TestNet: 1287
As Moonbeam grows and multiple networks are live at the same time, different Chain Ids help prevent replay attacks. Fun fact, the Moonbeam MainNet Chain Id will be 1284 because it takes approximately 1284 milliseconds for a moonbeam to reach Earth.
For more information regarding the v3 Upgrades, you can check the official release notes.
If you have any feedback regarding the Unified Accounts implementation, Moonbase Alpha v3, or any other Moonbeam related topic, feel free to visit our website or reach out through our official development Discord server.