Neon EVM: The Limitations for Ethereum Compatibility

The Neon EVM is a full Ethereum emulation designed to process Ethereum-like transactions and execute them on Solana. Certain transactions, however, are not currently processible through the Neon EVM, so adjustments may need to be made to allow them to be processed. These limitations are a consequence of the lack of standardized programming practices across blockchains — a reflection of the fact that smart contract development is still in its early stages. Furthermore, despite Ethereum being the most popular layer-1 blockchain for dApps, it is intentionally designed to favor execution occurring on a separate network (e.g. Solana), and relies on itself primarily for security.

Neon EVM’s Compatibility with Ethereum

The Neon EVM is an Ethereum emulation built as a smart contract on Solana. Using the processing architecture of the Neon Proxy, the Neon EVM is able to comply with both Ethereum and Solana rules — making it capable of iteratively processing the parallel execution of EVM bytecode contracts on Solana. To accomplish this, EVM contracts built using Vyper/Solidity compilers are uploaded to individual Solana accounts. Signatures are then checked on Solana according to Ethereum’s rules. However, there are still some problems that remain unresolved — these will be addressed after the mainnet launch.

The challenges associated with integrating Ethereum native dApps and connecting them into Neon are twofold, namely: dealing with precompiled contracts and complex iterative transactions. This article will explore the rarely-used functions, precompiled contracts, and RPC methods that are not currently supported by the Neon EVM MVP release.

Unsupported Precompiled Contracts

Developers typically rely on precompiled contracts for complex operations that are not suitable for writing in opcodes, either due to their computational cost, or for other reasons. For example, the ECRecover precompile is a popular method of verifying the signature of a message and is compatible with the Neon EVM. Because precompiled contracts rely on things from outside the Neon EVM, not all of them are currently supported.

Out of Ethereum’s eight main precompiled contracts, the following four are not currently supported by the Neon EVM:

• bigModExp — Used for efficient RSA verification inside the EVM and for other forms of number theory-based cryptography.
• bn256Add — Performs addition on elliptic curve operations.
• bn256ScalarMult — Performs scalar multiplication on elliptic curve operations.
• bn256Pairing — Elliptic curve pairing operations required for performing zkSNARKs verification within the block gas limit.

Smart contracts written in Solidity will not work on the Neon EVM if they use any of these precompiled contracts on Solana. If developers insist on using them, they should make sys-calls in the Solana core — similar to the implementation of erc-recover. For an example, have a look at the implementation of bn256* Solana Syscalls here. You can also take a look at how the Neon EVM utilizes Ethereum precompiled contracts under the hood here.

Broadly speaking, developers can take the following steps to implement the aforementioned precompiled contracts via the Neon EVM:

1. Prepare the necessary changes to support precompiled contracts in the Solana core.
2. Create pull requests for the Solana core to make these improvements.
3. Test changes in Testnet.
4. Test changes in Devnet.
5. Test changes in Mainnet.
6. Update the Neon EVM to support these precompiled contracts.

Unsupported JSON-RPC Methods

For software to communicate with Ethereum, it must be able to connect to an Ethereum node. This communication is handled by a JSON-Remote Procedure Call (JSON-RPC). The Neon EVM interacts with JSON-RPC APIs the same way that Ethereum does, following the Ethereum JSON-RPC Specification.

Some of the most popular RPC methods are already supported by the Neon EVM and can be viewed here. There are some other supported methods that have not yet been added to the list.

Unsupported Tokens

In both Testnet and Devnet, Neon EVM supports operations with tokens that comply with the ERC-20 standard. Non-fungible tokens (NFTs) generated in accordance with the ERC-721 standard cannot be processed by Neon EVM at this time. Although they can be generated within the EVM, they will have no value and will be locked within the ecosystem as they are not recognized outside of the Neon EVM.

Restrictions on Iterative Transactions and Current Solution

In an iterative transaction, separate accounts execute different steps in a series. When using Neon EVM’s iterative mode, an error message may appear about blocked accounts after attempting to execute, which will result in a suspension of the transaction. This error message occurs as a result of the way Neon EVM processes iterative transactions.

Neon EVM processes an iterative transaction in the following manner:

1. Neon EVM receives a transaction for iterative execution and blocks the accounts specified in it.
2. When the next transaction enters the Neon EVM, the EVM views the list of accounts specified in it and involved in its execution. If, at this moment, any listed account is blocked due to its involvement in the iterative execution of another transaction, Neon EVM returns the error.
3. The first transaction must first be completed before it unblocks the accounts blocked by it.

The point of this implementation for mainnet is to have a consistent state for Solana accounts during the execution of the transaction until it completes. Since the transaction is executed in iterative mode, there are time intervals between the executions of each step. Therefore, this solution prevents the possibility of changing the data of Solana’s accounts located in the system state during these intervals.

Issuing the error about blocked accounts when starting a transaction is a temporary workaround. This error and a workaround solution will be implemented after the MVP release on Mainnet.

Despite these limitations, the Neon EVM remains a powerful emulation tool. It allows developers to effectively port their Solidity-based smart contracts onto the Solana blockchain in the vast majority of cases. Even when a contract requires some unsupported functionality, there are often ways to implement it in another, more compatible fashion. Over time, Neon expects to introduce more compatibility in the EVM for these currently unsupported functions.