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.