Architecture

This page describes the high-level ideas behind EVM compatibility in the Humanode network.

Components

To implement the compatibility, we implement the following:

  • Ethereum Virtual Machine to execute the EVM-byte code on-chain.

  • Ethereum-compatible JSON-RPC interface to allow Wallets, UIs, backends, and other off-chain components to interact with the Humanode network the same way they interact with Ethereum network.

  • Ethereum block emulation layer - to present the necessary block information to the EVM and RPC interface; this is required because our native blocks are built differently from the Ethereum blocks, yet the block information is required for certain interactions with Ethereum.

  • Secondary accounts system - to allow using the familiar Ethereum Wallets and Dapps with the Humanode network; see the #evm-accounts section for more info.

EVM accounts design

Humanode network has two parallel accounts systems: native accounts and EVM accounts.

TLDR: we have decided to go against complex interleaving and emulation of the addresses, and implemented a secondary accounts system for EVM 20-byte accounts.

The problem

Humanode native accounts are SS58-encoded 32-byte blobs, typically containing the public key of an externally owned account.

This is not compatible with EVM, which uses hex-encoded 20-byte blobs, which are either a truncated Keccak hash sum of an externally-owned account's public key, or a smart contract account's address.

To make things work, we had to decide on how we enable the EVM accounts on Humanode network.

The solution

We have decided to add a secondary accounts system for the EVM network. It complements the native accounts system but does not replace it.

Users can have any number of native accounts and EVM accounts, and there is no mapping required (unlike with our old implementation, see Other potential options section for more info).

The operations with EVM accounts and EVM smart contracts are available via the Ethereum JSON-RPC interfaces, and the operations with native accounts are available via the native (Substrate) JSON-RPC interface.

Since the account systems are separate, the currencies that the two account systems utilize are also technically separate. We call the native Humanode network currency HMND, and the EVM currency eHMND.

Two account systems can interact with each other on-chain via the interfaces we expose via pallets (from the native end) and precompiles (from the EVM end). For instance, we have implemented HMND/eHMND swap to transfer the funds from native accounts to EVM accounts and vice versa.

Other potential options

Testnet 2 era design

In our first design iteration on the EVM compatibility (at the time we launched Testnet 2) we implemented the account mapping system - which used a single accounts system but stored the EVM 20-byte accounts addresses in the emulated 32-byte native account addresses.

This was complicated, so we decided to change how this works.

Other considered solutions

... and we will write this section a bit later. Better to ship this doc early so you all can see it, isn't it?

PreviousPrecompilesNextHMND/eHMND swap

Last updated