A Brief Analysis of the Main Features and Functions of the EVM-Compatible Network Neon in the Solana Ecosystem

Original Title: 《Neon: An Ethereum Virtual Machine on Solana》

Author: David Shuttleworth, Consensys

Compiled by: Biscuit, Chain Catcher

Abstract

Neon is a fully compatible Ethereum Virtual Machine (EVM) that allows developers to leverage familiar Ethereum tools and build Web3 applications on Solana. A significant part of the challenges in the development of public chains is attracting developers. This situation can become even more complex when the development of public chain networks requires tools that differ significantly from the standard and may create bottlenecks for scalability. However, developers using Neon can avoid such troubles. Applications can handle Ethereum-like transactions on Solana and utilize all native Solana features, such as high-frequency concurrent transactions and low gas fees. Developers also gain direct access to the Solana ecosystem, resulting in more users and greater liquidity. Ultimately, Neon allows any Ethereum application to run on Solana without changing its codebase, making Neon a powerful tool for most developers on Solana.

Overview

Public chains compete for limited resources and users. Therefore, building applications on different blockchains is very challenging for various reasons. One of the challenges involves attracting developers and providing tools. Public chains not only need to attract a group of skilled developers to build applications and infrastructure but must also offer familiar and easy-to-use tools that allow developers to build without hindrance. The initial challenge becomes more complex and turns into a bottleneck for ecosystem development when developers must learn a plethora of new tools and cannot easily port existing smart contracts. The intensity of the learning curve limits the scale of applications in public chains, as development work requires substantial time, effort, and dedicated resources to make applications feasible.

Neon EVM attempts to overcome these challenges by introducing an Ethereum-like development process on Solana. This is important for many reasons, particularly because it allows developers to seamlessly build Ethereum-based applications on Solana and unlock Solana's performance and liquidity. Users can then benefit from lower gas fees and higher throughput. On a technical level, Neon EVM is built using Solana's smart contract language Rust and compiled into Berkeley Packet Filter (BPF) bytecode. This gives Neon many unique advantages and enables it to leverage Solana's core features, such as concurrent execution of smart contracts. Additionally, the technology allows Neon to easily upgrade and track Solana hard forks while maintaining updates to Ethereum.

EVM and Neon Approach

To better understand the utility of Neon, it is useful to delve into the core functionalities of the Ethereum Virtual Machine. The EVM is the runtime environment for all smart contracts on the Ethereum protocol. In short, the EVM stores and maintains all smart contracts, manages their deployment and execution, and defines the rules for processing Ethereum-like transactions. Therefore, the EVM can be thought of as a mathematical function that takes external inputs and returns deterministic outputs.

One limiting factor of the EVM is how transactions are executed on Ethereum. Smart contracts written in Solidity need to be executed sequentially to ensure deterministic behavior. As a result, the EVM must examine smart contracts one by one and modify the blockchain state accordingly. This is because Ethereum smart contracts do not independently reference shared data. However, Solana's design and Sealevel feature allow for parallel processing of smart contracts. Ideally, Solana can support over 50,000 transactions per second (TPS), while Ethereum is typically limited to 1,500 TPS.

Neon EVM is an on-chain solution that brings native EVM capabilities to the Solana network. It operates by wrapping Ethereum-like transactions into Solana transactions and then sending them to the Solana network for parallel processing and execution of transaction data. Currently, Neon has a throughput of about 4,500 TPS, with a gas fee of $0.000015 per transaction.

Ultimately, Neon EVM enables any Ethereum-native application to run on Solana. This can be done without requiring any changes to its codebase and includes all standard Ethereum tools. Developers can continue to write smart contracts in Solidity, fund dApps using MetaMask, or deploy dApps on Solana using the Truffle environment. Therefore, anyone using Neon EVM can seamlessly port Ethereum programs to Solana. The appeal of this approach lies in the fact that popular applications like Uniswap and Curve can be built on Solana with less friction cost. Thus, developers can expand their user base to reach new users on Solana and gain significant liquidity from Solana.

Key Features and Functions

Digging deeper, Neon’s advantage lies in its ability to run seamlessly on the Solana network while checking transaction signatures and calculating gas consumption in a way that is compatible with Ethereum clients. This helps preserve the structure of smart contracts and creates an Ethereum-like experience in the Solana environment. Additionally, users can pay for transaction completion fees to Neon EVM operators using user-specified ERC-20 tokens. This adds an extra layer of flexibility and liquidity, as users are not restricted to specific token types. Over time, this feature will expand to include more tokens and allow Neon operators to choose to accept transaction execution payments from all token listings.

Neon also incorporates other core features, including a Web3 proxy, token synthesizer (ERC-20 SPL-Wrapper), and cross-chain bridge (NeonPass). Overall, these features ensure smooth transactions on the network, protect Neon’s infrastructure, and create a user-friendly, frictionless interaction experience.

For example, Neon’s Web3 proxy acts as a service layer between the EVM client and the Neon EVM. It allows clients and operators to access the Solana blockchain to communicate with each other by providing an Ethereum-like Web3 API. This enables users to start using Neon EVM without changing their codebase. Additionally, the token synthesizer allows users to synthesize their Solana ($SOL) tokens into Wrapped Solana tokens ($wSOL). This is similar to Wrapped Ethereum ($wETH) on Ethereum. Finally, Neon’s cross-chain bridge allows users to easily transfer tokens between Solana and Neon EVM, enabling Ethereum users to transfer and withdraw SPL tokens from Neon EVM.

A particularly interesting design is that Neon EVM’s Web3 proxy is completely permissionless and unrestricted, allowing anyone to join the proxy and run it. Neon is also flexible, as any client can replace the proxy and choose to run its own library. Thus, the Neon network operates in a truly decentralized manner, as the transactions it receives do not contain attributes that determine their priority.

Another interesting design is how Neon implements transaction parallel execution. Neon achieves this in a manner consistent with standard transactions on Solana, but also includes a new way to optimize Solana parameters. Specifically, a key challenge in building EVM infrastructure on Solana is the fundamental differences between Ethereum and Solana and how each protocol handles transactions: Ethereum processes each smart contract one by one to deterministically achieve blockchain state, while Solana handles multiple parallel smart contracts. Additionally, Solana allocates network resources to a given transaction in a hardware-optimized manner. In some cases, Neon transactions may require more resources than Solana allows.

Neon has built-in flexibility to handle transactions with minimal impact on the network by iteratively executing contracts and limiting access to shared data of the Solana state that is in use. Therefore, Neon will block Solana accounts used in Neon transactions, and if any of these accounts have been blocked, new transactions will queue for execution by Neon’s Web3 proxy. This iterative process involves the Neon EVM transferring deposits of $SOL tokens from the operator's account to another separate deposit account. A portion of this deposit is then allocated as a reward to the node validators executing Solana transactions. Another portion is paid to the operators who complete requests and iteratively execute Neon transactions.

Moreover, the challenge of porting the EVM to a non-native blockchain is to conform to local processes while being flexible enough to handle various service requests and standardizing transactions in a liquidity-oriented manner. Neon EVM transaction costs are calculated based on Ethereum rules but are based on Solana fees. So overall, the transaction costs on Neon are significantly lower than those on Ethereum, as the end user pays Solana gas instead of Ethereum gas. As mentioned earlier, a portion of the transaction fees is sent to the Neon operators executing the transactions, with the fee denomination set to $ETH by default, but Neon users can choose any ERC20 token to pay for Neon transactions.

Finally, Neon has created a secondary transaction execution market to help scale and optimize the network. Neon operators can state their terms and rates in the market, allowing Neon clients to choose the operators they want to meet their requirements. Additionally, any Neon EVM user can deploy the Neon Web3 proxy and execute Neon transactions using Neon EVM. These operations are completely permissionless and do not require any assistance from Neon EVM operators. However, users must use $SOL tokens to execute transaction operations on Solana.

References:

https://neon-labs.org/Neon_EVM.pdf

https://docs.neon-labs.org/docs/about/introduction/

https://docs.neon-labs.org/docs/governance/governance_overview/

https://ethereum.org/en/developers/docs/evm/

https://docs.solana.com/developing/on-chain-programs/overview

https://neon.aleph.cloud/