EVM in Motoko for Trustless Execution Environments

Hello ethResearch :wave: it has been a while since I posted. Thanks for your patience as I wade back into the eth universe.

An organization that I’m running called https://icdevs.org is funding an evm built in Motoko that is targeted to run on the Internet Computer(and that we think will slide well into the AO universe as well). We should have started this 3 years ago, but there is no time like the present. To date this work has been funded through #GG19 and #GG20. The eventuality of this project is trustless execution and consensus agents and the ability to monitor and relay messages between EVMs(and other chains) in a trustless manner.

The bounty has reached its first milestone and we’re looking for experienced EVM implementors to tell us what we’ve missed and how to make it better. I realize this forum seems to have moved on to bigger and harder scaling challenges, but I’m hoping you all can point me in the right direction to find the right audience. It is a bit too technical for r/ethereum but may be too basic for this forum and not quite an EIP.

Why we are looking to build out an EVM execution layer for the Intenet computer(from our thread at Open - ICDevs.org Bounty #63 - EVM OpCodes - Motoko - 1.9 ckETH - Bounties - Internet Computer Developer Forum )

  1. The obvious - we can’t build an EVM in motoko without the op-codes. Now building an evm in motoko isn’t particularly a priority at the moment, but long term the Ethereum Foundation has made it a priority to have EVMs in as many languages as possible as a security feature. Would it make sense to have IC canisters as evm nodes for other chains? Probably depends on network config and a few other things, but I could certainly see it being of value long term. Having the op-codes defined separates the execution concerns from any future project that might want to wire up the rest of the EVM machinery. From building from the ground up you get an EVM that takes the IC’s compute pattern and restrictions into account in ways that existing EVMs written in other languages would need significant rewrites to support.
  2. General education - These opcodes are an awesome way to learn about stacks, memories, and crypto primitives. Education is the primary goal of ICDevs.org and we feel like Motoko versions of these libraries would make a really interesting set of examples for people learning about how EVMs work, why they work, and what concepts mirror over into the IC(and which ones don’t).
  3. Libraries and Integrations - these libraries build on top of a number of other Bounties that we’ve funded that could use some burn-in and integration testing to improve them and make sure they are working properly. GitHub - f0i/merkle-patricia-trie.mo: A Merkle Patricia Trie implementation in Motoko GitHub - relaxed04/rlp-motoko: RLP implementation on motoko. In addition, some of the op codes implement core functionality that we’ll need to do cross-chain like ecrecover which would be important for a motoko canister trying to verify a signature from the evm universe.
  4. Micro EVMs - In one universe bitfinity EVMs proliferate and we end up with a garden of highly specialized evms on the IC that interact and interoperate in unique ways. These libraries would allow you to pull in the memory, storage, etc from those EVMs and run transaction simulations to check for opportunities or to automate actions against them using things like the event logs. The always-on nature of IC canisters makes them ideal for writing bots/agents that seek opportunities and execute on them by signing tecdsa messages and relaying them.

Our bounty hunter has completed the first milestone, arithmetic functions.

project file:

main code file:

tests: