On EVM Support in NEAR

This is a write up to detail specific reasons for having an EVM support in NEAR Protocol as a separate Execution Environment.

NEAR is recently launched ecosystem. It is also very different from Ethereum or even other blockchains.

Sharding introduces new concept of async cross contract communications. This is similar how transition was going from single CPU to multi CPU computers.

NEAR has a very different account / contract model as well. E.g. accounts have many access keys and supports permissioning them. Contracts can be updated in-place and have new interesting effects (like can share a permissioned key to itself with a user, like NEAR Drop does).

All this means two things:

  • There are new concepts and standards must be developed how to build on NEAR
  • Developers will need to learn new concepts and figure out how to leverage them the best

Both of these things will take time to develop.

Another important thing is tooling for developers. Even though our basic dev experience has been relatively good, but the experience for developers is not just SDKs and APIs but also set of companies that provide services for developers like TheGraph, BlockNative, etc.

Expanding more on async contract communication, there are actually interesting issues when using for specific types of applications. Because the transaction might be taking multiple blocks - there are more opportunity for front running.

Example would be if Uniswap would be just copied 1 to 1 on NEAR, where each pool is a separate smart contract. If there is a trade that connects multiple pools (for example via 1inch algorithm) NEAR → DAI → MKR. After NEAR → DAI exchange completed, there is a receipt sent to another shard B, but by this time the fact that this transaction is been processed has been known to any observer in the system. Such observer can ahead of the receipt receival from shard A send their own transaction to shard B’s DAI → MKR pool. E.g. front-running in sync environment can be done by block producers (miners) but in async there are possible cases when front-running by any external observer.

Similar thing happens for example between a lending pool and a AMM that it uses to do liquidations.

There are solutions, from merging pools into one contract (what NEAR-CLP project did) and have a caller calculating slippage ahead of time and provide very low margin for that. Even if observer is trying to frontrun - it will just cost gas for both of them but the observer can loose money on this trade and get arbitraged away by someone else.

There are considerations to introduce sync communication between WASM contracts. There are still a lot more discussions and work on figuring what is the best way to introduce this.

All these considerations need a lot more time to figure out, test in practice and see how it evolve together with community bringing their insights.

In the mean time, financial ecosystem is needed to bootstrap Open Web. And for many developers, the existing and battle tested code provides great ground for innovation.

Ethereum’s tooling also are familiar to them and have lots of tutorials, which allows to build apps faster.

Solution to bring a synchronous contract processing of EVM provides us with a place where existing developers and contracts can go easily.

There is a concept of “Execution Environment” - a sub space on the blockchain which processes transactions. Ethereum 2.0 Serenity suggested this originally to allow different runtimes (and also bring Eth 1.0 to it while still allowing for newer things like WASM).

Given NEAR pretty much implements on many of the same points, it make sense to bring Execution Environment of EVM as it’s own shard.

Internally to EVM all cross contract calls are synchronous, receiving the same properties as developers and users are used to on Ethereum. Even internal to EVM addresses are the same, having a way to map between NEAR WASM and EVM environments.

Additionally, because we want to enable existing Ethereum users to easily use migrated and new apps inside EVM, there is a way to interact directly from MetaMask into NEAR EVM without even changing or configuring anything.

Most of the tooling can also easily connect - there is a Web3 provider that connects to NEAR EVM and there is a plan to have an RPC Proxy server which would make even more things easier.

Even in pre-beta version, there was already a few developers who tried to use it. Even more are waiting for BetaNet release to start playing with it.

EVM together with Rainbow bridge can provide a very smooth experience for Ethereum developers and users to transition to NEAR.

As NEAR WASM tooling matures, some apps will be reworked into WASM apps but some will stay inside EVM as ~1,000 tps will be enough for quite a few apps to co-exist. Remember also that NEAR can have arbitrary number of EVMs in theory, so if apps don’t need to co-exist they can transfer out into their own EVM and in theory can their own shard. Communication between one EVM and another or WASM contract will be asynchronous though.

We can’t also rule out that there will be another “Execution Environment” later that people would find useful.


You are also going to need EtherScan equivalent. Binance has licensed Etherscan for their Binance Smart Chain, but I expect it to be expensive business:

Based on my testing MetaMask and Ledger both work with BSC unmodified.

Also will this change how Rainbow Bridge operates?

Not really, Rainbow is actually generic protocol that can support any runtime. There are few technical details like how to connectors will preserve connectivity across runtimes, but it’s mostly just to support WASM<>EVM transport easier.

What I definitely don’t like in this concept, is that the “shards” domain leaks into the runtime matter. Also, the “Execution Environment” subject is poorly defined.

To be clear, NEAR sharding is in some ways closer to Polkadot para-threads than to sharding designs of many other chains.

Meaning each contract is it’s own shard. So “shards” domain is not leaking per se, it’s how everything works on base layer. And developers of “base” layer apps must be keenly aware of this.

Within any contract, one can build any complicated system of accounts and subsequent WASM calls. Literally you can run version of our runtime in sync mode within a single contract.

EVM is just an example of such contract.

Currently we precompiled it for performance reasons, but I see if we will be able to indicate to nodes which WASM should be compiled with high optimizations (either via governance or via protocol usage statistics), we can actually move EVM back to contract level.

Everything in current EVM precompile is design with that in mind.

1 Like

There is also very clear DevX point.

The onboarding for existing blockchain developers with EVM:

  1. Read documentation that NEAR has EVM
  2. Run tests on existing code pointing at proxy
  3. Dev deploy to TestNet
  4. Switch frontend to use NEAR Web3 Provider

Alternative is people need to:

  1. Learn Rust or AssemblyScript (which has a lot of it own quirks which are different from TypeScript)
  2. Learn NEAR specific things like cross contract calls, value attachments, testing infra and simulation. Which to be clear, for Rust is really good.
  3. Rewrite all the contracts. Potentially needing to rewrite parts that they just used from other places (like OpenZeppelin libraries or leveraging existing deployed contracts)
  4. Get them to re-reviewed by security audit firms
  5. Rebuild frontend

This is the same choice why we started to do Rust and AssemblyScript in the first place - because we wanted to give people an easier onboarding into the blockchain.

Given the number of developers and tools in Ethereum ecosystem have grown pretty dramatically from when we started, it’s clear that Solidity tooling must be supported as well.


Having an EVM-compatible runtime on the protocol level seems more attractive to me.

1 Like