The EVM Compatibility Chronicles - Part IV

This is the final part of our series of articles on The EVM Compatibility Chronicles.

As previously discussed, the challenge for building Humanode's EVM-compatible chain is that we need to support an API designed exclusively for EVM addresses. We cannot use Substrate-style addresses universally since EVM requires wallets that understand EVM addresses. Our chain must interpret these EVM addresses in some way.

When asked How to resolve this issue, MOZGIII said,
"There are alternative approaches to implementing this integration. For example, we are investigating solutions that limit the use of EVM addresses, so that every user wanting to interact with EVM-based applications must create both a Substrate account and an EVM account. These users would then need to link the accounts, establishing a one-to-one relationship between the addresses that are maintained on-chain."

With this method, both addresses would point to the same account, resulting in a single balance. Suppose you have 100 HMND in both accounts; if you transfer 5 HMND from each address, the combined deduction would be 10 HMND. In this way, there would be no need to convert between the two accounts. This is one potential solution.

"Another alternative is to separate the balances and maintain completely distinct systems fully. For example, a Substrate account could hold 100 HMND, while an Ethereum account would contain a different token, say EVM-HMND. There would be an exchange rate between the two, and transfers of EVM-HMND would only occur between EVM accounts, while HMND transfers would be limited to Substrate accounts. Additionally, users would have the option to convert between the two tokens through exchanges", says MOZGIII

There are numerous options to consider, but the two mentioned above are vastly different and would significantly impact the user experience.

For example, the first option allows for a single token but limits users by requiring them to go through a mapping process to interact with the EVM section. It is important to note that we are discussing the intricate details of a specific implementation aspect. If users send tokens to non-mapped addresses, those funds could be lost forever, as there would be no Substrate account in place to hold the funds.

Also read - The EVM Compatibility Chronicles - Part I

Addressing this issue presents two potential solutions. The first option involves preventing transfers to non-mapped accounts, which would be a safer approach and help protect users from losing their funds. The second option allows users to send funds anywhere, and if funds are sent to an unmapped account that is later mapped, the funds would automatically be transferred to the associated Substrate address. This would prevent fund loss. Alternatively, funds sent to non-mapped addresses could simply be burned.

Also read - The EVM Compatibility Chronicles - Part II

In summary, we have already identified several solutions to address the challenges we face in building EVM compatibility. The task at hand is to carefully evaluate and choose the best possibility that aligns with our specific requirements and goals.

Summing Up

As for when to expect a fully EVM-compatible Humanode update, I suggest it’s coming “SOON ” ;)

Here’s a summarized update on the progress thus far from MOZGIII:

We've been diligently working on EVM compatibility for quite some time and have successfully implemented all three components we discussed in part III. The challenge now lies in effectively integrating these components. In essence, we've developed an alpha version of the solution. Both the EVM and emulation layer, as well as the RPC API, are robust and reliable. The only remaining task is to fine-tune the proper configuration. We are in the final stages of this process and are currently making the necessary adjustments for a fully functional solution.