Neon EVM is an Ethereum virtual machine on Solana that enables dApp developers to use Ethereum tooling to scale and get access to liquidity on Solana.
The Neon platform combines two blockchain ecosystems (Ethereum and Solana), which allows you to create decentralized applications on Ethereum, but with liquidity from Solana. This gives impetus to quickly scale all dApps.
Neon’s developers took from Ethereum ecosystem accounts and signatures, tools, infrastructure, solidity smart contracts and tokens (like ETH, ERC-20). And from Solana - liquidity, userbase, tx record and lighting fast tx. The platform has an average speed of 4500 tps, and average gas fees - 0.000015 Sol/tx.
This approach allows not only to create new applications, but also to integrate already known ones. So any Ethereum application on Solana without any changes to its codebase, including MakerDAO, UniSwap, 0x, SushiSwap, etc.
Neon Web3 Proxy is a service that provides a Web3 API to access the Solana blockchain. It acts as an intermediary for communication between Neon EVM and Neon EVM clients and can be started by Neon EVM operators.
Neon Web3 Proxy is optional for any Neon EVM client. His main goal is to help Neon EVM customers start using the platform without any changes to the code base of their decentralized applications.
To date, most current blockchains process transactions on a single thread. This means that one contract at a time changes the state of the blockchain. However, Solana can process tens of thousands of contracts in parallel using as many cores as are available to its validator. This feature is known as Sealevel and it greatly increases the throughput of the blockchain.
Parallel processing is possible because Solana transactions describe all the states of a transaction. This prevents duplication of transactions by allowing different transactions to perform several actions at the same time.
Neon transactions are executed by Solana as native transactions: in parallel with restricting access to shared data from Solana's state. However, in some cases, a Neon transaction requires more resources than Solana allocates per transaction. In this case, Neon EVM executes the transaction iteratively.
To allow Solana transactions to run in parallel, Solana requires a list of all Solana account transactions involved in the transaction. If there is a call to a Solana account that is not listed in the Solana transaction header, the algorithm aborts with an error.