The introduction of EVM runtime support in the NEAR Protocol will be a major change for Ethereum developers who are seeking an alternative chain. This search is mainly caused by enormous Ethereum gas fees, which are the consequence of the absence of scalability. The NEAR EVM runtime, compared to Ethereum, provides a number of enhancements:
- EVM fees will be 1,000x-10,000x times cheaper than Ethereum’s,
- The EVM runtime will be able to host approximately 10 times higher transaction throughput compared to the current state of Ethereum,
- NEAR transaction finality time entails the confirmation of 2 blocks (roughly 2 seconds), which is substantially lower even than a one-block confirmation time in Ethereum (13 seconds on average),
- In case a dApp ecosystem will grow and a single EVM runtime won’t be able to fit it, NEAR’s sharding approach enables scaling the number of EVM runtimes. Each of them would be equivalent to Ethereum 1.0, while connections between them would be implemented using asyncronous calls,
- Full, uncompromising Ethereum compatibility on top of decentralised PoS L1 protocol.
The aforementioned means that the NEAR EVM will solve the current and future computational pains of the Ethereum ecosystem, preserving the existing engineering investment in both smart contracts and in frontend code.
This post aims to shed some light on the NEAR EVM architecture and the expected changes to the protocol. We are also going to use this post to collect requirements for EVM testing before the eventual MainNet launch.
For those interested in the EVM roadmap for Q1 2021, find it here and here.
EVM architecture
In recent weeks we have made an important decision to move most of the EVM implementation to the contract level. What does this mean?
- The intervention of the EVM runtime in the NEAR protocol will be substantially reduced. Having EVM as a “precompile” entailed major pain points that were pointed out by multiple people in the EVM base token discussion.
- Having the majority of the code on the contract level will simplify the maintenance, upgrades, and governance of the EVM runtime in the early stages, and will allow fast reactions to any security vulnerabilities. Though the EVM governance and upgradability approach is not as yet fixed, the Rainbow Bridge approach seems mostly applicable in this case too.
The current architecture of the NEAR EVM looks as follows:
The EVM smart contract implements two main interfaces: Execution and Token. The Execution interface allows users to send ordinary Ethereum transactions (for example, created with MetaMask or web3.js). Underneath, these transactions get decoded (RLP), verified (secp256k1) and executed in the EVM runtime (Sputnik VM).
The operations allowed in the EVM runtime may be moved to the NEAR Protocol level (and thus become precompiles) in case a smart contract does not deliver target performance. For example, on the protocol level there are sha256() and keccak256() precompiles already available. In case of the need for additional precompiles, a protocol upgrade will be proposed to NEAR validators. The information on the required precompiles will be collected once sufficient load testing performed.
As per the outcome of the discussion, on the EVM base token, the EVM runtime will maintain native balances in Ether (ETH). This means that a user should move his ETH over the Rainbow Bridge to NEAR before sending any other transactions to NEAR EVM.
In order not to confuse a user, we decided that the EVM contract will implement a fungible token interface, which will represent the user ETH balance in both the NEAR base runtime and the EVM runtime. Besides this, a user should be able to withdraw and deposit ETH to NEAR, and this will be implemented as a separate bridge connector interface, which underneath will speak to the core bridge contracts (see more on the bridge architecture here).
The code for the EVM contract and adjacent tools can be found in the NEAR EVM repository. The Token interface is at the moment implemented in a bridge connector; however, it will be merged into the aforementioned after the development is done.
Using ETH to pay for gas fees
One important side of the NEAR EVM design is how users will be paying ETH for the transaction execution.
The approach is the following:
- To understand the ETH gas price in NEAR EVM runtime, a JSON-RPC endpoint
eth_gasPriceis used. The returned value will be used for future ETH payment to the RPC node (see step N). - A user signs an ordinary Ethereum transaction with his tools (MetaMask, Wallet Connect compatible wallet, CLI, JS libraries, etc.) and sends it to RPC.
- RPC wraps Ethereum transaction into NEAR transaction and sends it to the EVM contract.
- On the protocol level, the RPC signature is verified and the initial Ethereum transaction is passed to EVM contract.
- EVM contract parses Ethereum transaction and executes it, calculating the EVM gas usage on the way. By the end of the Ethereum transaction execution some NEAR gas is already burned (acording to the rules of the protocol), while ETH gas is just a calculated number in the EVM contract.
- In order to pay for the NEAR gas fee, ETH is used: EVM contract calculates transaction fee and transfers it from the user account to the RPC account.
This approach is viewed from the user side as just paying ETH to the protocol, while in fact it is the $NEAR token which is used for the calculations, and RPC nodes acting as proxies/relayers between the user and the NEAR blockchain.
Note, that as the first step, RPC would be able to provide the ETH gas price that will be sufficient for paying for the relaying service. Moreover, based on the responses from the multiple RPC nodes, a user would be able to decide, which one to use. In future, relaying services can be structured similarly to OpenGSN.
Find more information on ETH as a base token in this discussion.
Rollout plan
The current objective of the NEAR EVM team is the release of a fully operational EVM version to NEAR TestNet by the end of March. This version will cover all features including ETH bridging (using existing TestNet bridge deployments), RPC proxy, and EVM runtime execution. We’re also planning to stress test the NEAR EVM with a custom tool named ‘EVM Bully’, that will replay an Ethereum chain (the Ropsten testnet, say) transaction-by-transaction to the EVM contract.
The following things will not be implemented during Q1:
- Advanced upgradability and governance plan
- Extensive testing and code stabilization
- Additional precompiles, if needed
- Massive 3rd party testing with bug bounties
Though the EVM release to the MainNet (in case no precompiles would be added) is fully dependant on the deploying party—which can be anyone, since the code is open—we would like to gather the requirements & metrics from validators and the community. We will use these requirements to fine tune the contract and eventually release a version matching the community’s requirements.