Neon: An Ethereum Virtual Machine on Solana

Neon allows developers to build dapps that can process Ethereum-like transactions on Solana and realize all the functionality native to Solana, such as parallel execution of transactions and low gas fees.

Reading time

8 min. read

Image: Neon: An Ethereum Virtual Machine on Solana

Summary

Neon is a fully compatible Ethereum Virtual Machine (EVM) that lets developers utilize all of the familiar tooling of Ethereum and build seamlessly on Solana. Part of the challenge of developing an on-chain economy is attracting developers to build on it. This can be compounded when a network has tools that are much different from the norm and can place an inherent bottleneck on scalability. Developers using Neon, however, can avoid such challenges. Applications can process Ethereum-like transactions on Solana and realize all of the functionality native to Solana, such as parallel execution of 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 changes to its codebase, making it an incredibly powerful way to build on Solana with scale.

Overview

Networks compete for limited resources and end users. Building applications on different blockchains, therefore, can be quite challenging for a variety of reasons. One hurdle involves developer inflow and tooling. A network must not only attract a cohort of skilled developers to build applications and infrastructure, but it must also provide tooling that is familiar and easy to use. This allows developers to build without rigid barriers. When developers must learn a host of new tools and cannot easily port over existing smart contracts, the original challenge is compounded and places a bottleneck on the speed at which the ecosystem can be developed. Significant learning curves limit the scale at which applications can be built as it takes considerable time, effort, and dedicated resources to make this effort possible. Given that much of the existing Web3 infrastructure as well as the most popular applications have been built on Ethereum, porting these constructs into a new ecosystem often requires a complete overhaul.

Neon EVM attempts to overcome these challenges by introducing truly Ethereum-like transactions on Solana. This is important for many reasons, especially because it allows developers to seamlessly build Ethereum-based applications on Solana and unlock the network's performance and liquidity. Users can then benefit from lower gas fees and higher throughput. On a more technical level, Neon EVM is built as a smart contract of Solana written in Rust, Solana’s native smart contract language, and compiled to Berkeley Packet Filter (BPF) bytecode. This gives Neon many unique advantages and enables it to leverage Solana’s core functionalities, such as parallelization of smart contract execution. It also allows Neon to be able to easily upgrade and keep track of any Solana hard forks and updates to Ethereum

EVM and Neon's Approach

To better understand Neon's utility, it's useful to delve into the core functions of the Ethereum Virtual Machine. EVM is the environment in which all smart contracts on the Ethereum protocol live. In short, EVM stores and maintains all smart contracts, manages their deployment and execution, and defines the rules for processing Ethereum-like transactions. So in a very basic sense the EVM can be thought of as a mathematical function in which an input is given and a deterministic output is returned.

One fundamentally limiting factor of EVM is the way in which transactions are executed on Ethereum. Smart contracts written in Solidity need to be executed in sequential order to ensure deterministic behavior. So EVM looks at one smart contract at a time and modifies the blockchain state accordingly. This is partly because Ethereum smart contracts do not have separate references to shared data. Solana’s design and Sealevel functionality, however, allow smart contracts to be processed in parallel. Under ideal circumstances, Solana can support over 50,000 transactions per second (TPS), while Ethereum is generally limited to 1,500 TPS.

Neon EVM is an on-chain solution that brings native EVM to the Solana network. It operates by wrapping Ethereum-like transactions into Solana transactions, and then sends them to the Solana network where they are then processed for parallel execution. Currently, Neon achieves throughput of roughly 4,500 TPS and gas fees of 0.000015 $SOL per transaction.

Ultimately, Neon EVM enables any Ethereum native application to run on Solana. This can be accomplished without requiring any changes to its codebase and includes all of the standard Ethereum tooling. Developers can continue write smart contracts in Solidity, utilize MetaMask to fund dApps, or use the Truffle environment to deploy dApps on Solana. So anyone using Neon EVM can seamlessly port Ethereum transactions over to Solana. Part of the appeal of this approach is that popular applications such as Uniswap and Curve could be built natively on Solana with much less friction. As a result, developers can expand their user base to reach new users on Solana and gain access to Solana’s massive liquidity.

Key Features and Functions

Digging a bit deeper, Neon’s performative power lies in its ability to seamlessly operate on the Solana network while checking for a transaction signature and calculating gas consumption in a way that is compatible with Ethereum-clients. This helps preserve smart contract structures and creates an Ethereum-like experience in the Solana environment. Moreover, users can pay Neon EVM operators for completing transactions in an ERC-20 token that the user designates. This adds an extra layer of flexibility and liquidity, since users are not restricted by specific token types. Over time this functionality will be extended to include more tokens and will let Neon operators choose to accept payments for transaction execution from a wide list of tokens.

Neon also employs other core features, including a Web3 proxy, a token wrapper, and a token bridge. Collectively, these features guarantee transactions on the network, secure Neon’s infrastructure, and create user-friendly, frictionless interactions.

For instance, Neon’s Web3 proxy acts as a service layer between EVM clients and the Neon EVM. It allows clients and operators to communicate with one another by providing an Ethereum-like Web3 API to access the Solana blockchain. This lets users start using Neon EVM without any changes to their codebase. Moreover, the ERC-20 SPL-Wrapper lets users wrap their Solana ($SOL) tokens to Wrapped Solana tokens ($wSOL). This provides utility that is analogous to Wrapped Ethereum ($wETH) on Ethereum. Finally, NeonPass, the native bridge of Neon, allows users to easily transfer tokens between Solana and the Neon EVM, and gives Ethereum users the ability to transfer and withdraw SPL tokens from the Neon EVM.

One particularly interesting design is that Neon EVM’s Web3 proxy is decidedly permissionless and left ungated so anyone can join the network and run a proxy. Neon is also flexible in that any client can replace the proxy and choose to run their own library. As a result, the Neon network operates in a truly decentralized manner since the transactions it receives contain no attributes that would determine their priority.

Another interesting design is Neon’s approach to achieving parallel execution of transactions. Neon accomplishes this in a way that aligns with standard transactions on Solana, but also includes a novel way overcoming some of Solana's optimization parameters. In specific, a key challenge of building an EVM infrastructure on Solana is the fundamental differences between Ethereum and Solana and how each protocol processes a transaction: Ethereum processes each smart contract one-by-one to deterministically achieve the blockchain state, while Solana processes multiple smart contracts in parallel. Moreover, Solana allocates network resources to a given transaction in a way that attempts to ensure hardware optimization. In some instances, a Neon transaction may require more resources than Solana allows.

Neon has built-in flexibility that enables the transaction to be processed with minimum impact on the network. This is achieved by executing the contract iteratively and restricting access to shared data in Solana state that is being used. So Neon blocks the Solana accounts used in the Neon transactions and if any of these accounts are already blocked, then the new transaction is queued for execution by Neon’s Web3 Proxy. This iterative process involves Neon EVM transferring the deposit in $SOL tokens from the operator's account to a separate deposit account. A portion of this deposit is then distributed as a reward to Solana validators for executing Solana transactions. Another portion is paid to the operator that completes the request and iteratively executes the Neon transaction. A final portion of the deposit is sent to the Neon governance treasury, which helps maintain the network.

Furthermore, a general constraint in porting EVM to a non-native blockchain is standardizing payments in such a way that is both in alignment with the native process yet flexible enough to handle various service requests and liquidity. Neon EVM transaction costs are calculated according to Ethereum rules, but are based on Solana fees. So overall, the cost of a transaction on Neon is significantly lower than it would be on Ethereum since ultimately the user is paying for Solana gas, not Ethereum gas. As mentioned above, a portion of the transaction fees are sent to the Neon operator that executes the transaction Fee denomination is by default set to $ETH, however the Neon user has the option to 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 signal their terms and rates on the market, allowing Neon clients to choose which operator they want to service their request. Moreover, any Neon EVM user can deploy Neon Web3 Proxy and execute a Neon transaction using Neon EVM. Again, this can be done entirely permissionlessly and without any help from Neon EVM operators. One aspect here, however, is that the user has to cover the transaction execution on Solana with $SOL tokens.

Conclusion

As more blockchains enter into the ecosystem and the efficacy and limits of a truly multi-chain future are tested, composable solutions will become even more critical. Developers and end users alike will require systems that are easy to use and involve minimal friction. Neon EVM is particularly interesting because it operates at the intersection of Solana and Ethereum, leveraging their performative power and market dominance, respectively. The prospect of higher throughput, faster block time, and lower gas prices without any accompanying changes to existing code is massive. Neon's infra layer of composability has the potential to unlock access to the userbase and liquidity of Solana for essentially any application on Ethereum. This gives developers the freedom to build between networks and end users the ability to reap the benefits.

Sources and Further Reading

https://neon.aleph.cloud/