The EVM Compatibility Chronicles - Part III

After our in-depth exploration of the importance of an EVM-compatible Humanode in part II, it is only natural to be curious about the team's approach to achieving this compatibility, particularly the challenges they face and how they plan to overcome them. In addition, we will also uncover the current stage of development. Let's examine MOZGIII's insights on this subject.

Starting with the basics, there are three components needed to implement EVM:

• First, the Virtual Machine to run EVM. For this, Humanode utilizes SputnikVM under the hood, a well-tested VM built on Rust and adopted by many Rust-based chains.
• Second, the Remote Procedure Call (RPC) interface is required. This layer enables external applications like wallets, dApps, and exchanges to interact with the node. For EVM compatibility, we need to implement the Ethereum RPC interface, which necessitates emulating parts of the Ethereum blockchain to support certain RPC interface functions.
• The third component is the emulation layer for the Ethereum blockchain structures. It acts as a bridge between our native blockchain and the information required for the Ethereum RPC interface for wallets.

"The team didn't have to build much from scratch, instead opting to use available resources within the Substrate ecosystem. Frontier pallets and crates are being utilized to implement the integration, as Humanode is also a Substrate-based chain", says MOZGIII.

This is the high-level outline of how we plan to build EVM compatibility.

However, some niche-specific details within these components pose challenges. For instance, the way Substrate chains are constructed involves a part of the code called runtime, which contains the logic enabling transactions and other features typical of existing chains, such as Ethereum's smart contracts and transactions.

Similarly, Substrate has transactions and can also incorporate smart contracts as code that users inject into the chain. This runtime also allows developers to include more advanced code for rapidly extending functionality.

One aspect of runtime includes defining the account ID (address used by users). In Humanode's case, the Substrate address format (which is SS58 encoded strings), is used. This is the address typically seen in Polkadot extensions. However, EVM and Ethereum employ different addresses, utilizing 20-byte hex code sequences. The address mapping between these formats is a niche-specific implementation that is still being worked on.

"The challenge lies in the need to support Ethereum-style addresses for EVM compatibility while retaining Substrate native addresses. And the team wants to keep it this way to ensure consistent compatibility with the rest of the Substrate platforms", MOZGIII underlined.

"One way to do it is to replace Substrate addresses entirely with Ethereum addresses. In doing so, we would create a Substrate-based chain that uses Ethereum addresses natively. Users could interact with Polkadot apps while connecting their MetaMask addresses instead of Polkadot JS extensions", he adds.

However, this approach is not ideal for our EVM compatibility, as it introduces the shortcomings of EVM. As EVM is an older, more rigid system with limitations that outweigh the benefits of adopting EVM-based addresses. Furthermore, while we aim to enable MetaMask wallet usage, these wallets do not support Substrate-based APIs.

Our ultimate goal is to offer alternative methods for building functionality on top of our network that don't rely solely on EVM smart contracts or Solidity-based solutions. So, it doesn't make sense for us to replace our core mechanisms with EVM-based systems.

Also, read: The EVM Compatibility Chronicles Part I

Adopting this solution would allow users to transfer funds to Ethereum wallets and interact with smart contracts using Ethereum addresses, but they would lose almost all visibility of the transactions they sign in their wallets. This is because transactions involving the Substrate layer code wouldn't be native to these wallets, necessitating emulation and creating the need for an additional compatibility layer.

Also, as our focus is on providing Sybil resistance rather than simply creating yet another EVM-compatible chain, we aim to enable EVM apps to run on our chains while ensuring a positive user experience. To achieve this, we will still need to resolve the issue of address mapping.

In the end, we don't want to restrict the ability to interact with the native logic we add to our chain, just to add transactions and smart contracts. This is why we continue to explore and develop our integration in a different way.

We will discuss the different approaches that the Humanode team has identified to deal with these challenges in part IV of the EVM compatibility chronicles.