Neon Blockchain Development

Ethereum, the most widely used smart contract platform in the world, needs no introduction. The ecosystem brings together tens of thousands of developers around the world, thanks to its programming language, Solidity. Thousands of decentralized applications have emerged there, and it is a real revolution. Thanks to Ethereum, many applications have revolutionized the Web: decentralized finance, non-fungible tokens (NFT), etc.

Solana is an extremely fast and scalable blockchain platform. Thanks to its architecture, it is possible to execute smart contracts in parallel. This allows for very high transaction throughput, all with very low execution fees.

Neon Architecture

Neon EVM is an emulator of the Ethereum Virtual Machine on Solana, programmed in Rust (Solana’s native programming language).

The Berkeley Packet Filter is a code that is injected directly into the kernel of an operational system in order to perform network filtering. Concretely, this minimalist interface allows linking different layers of data: the BPF provides the possibility to integrate several virtual machines on Solana. The Neon EVM virtual machine is a smart contract, deployed on Solana thanks to the BPF.

The rules of Ethereum and Solana are not the same: a mechanism is therefore needed to switch from one to the other. The Neon Web3 Proxy then allows users to convert signed Ethereum transactions to make them compatible with Solana. In detail, given that the size of an Ethereum transaction formed on the Neon EVM can exceed that of a Solana transaction, the N-trx will be “split” into several S-trx. Each of them will be signed with a proxy key, and the proxy will send the batch to Solana.

The Neon Web3 proxy also provides an API so that client software (Metamask, for example) can connect to the Neon EVM without having to rewrite their code. All you have to do is enter the proxy address into the client. So dApps work the same way, and the interface is identical.

How Neon Works

The user generates his transaction using his favorite client software. It is then sent to the Neon Web3 proxy – an instance of the Neon EVM emulator. The transaction is therefore created according to the rules of Ethereum. More precisely, it contains the following information:

Nonce: corresponds to the number of transactions sent from the sending address.

Signature: It is created according to Ethereum rules.

Gas price: fee paid per unit of gas (set by the user).

Gas Limit: The maximum number of gas units the user is willing to pay for the transaction.

Value: the amount of tokens to transfer.

Receiving address.

The Neon EVM emulator must first make a request to the Solana network in order to obtain the blockchain state data. It is the proxy that sends this request. With the state obtained, it will perform a series of test transactions (N-trx).

The proxy then creates the new transaction, according to Solana’s rules. It includes all N-trx as well as the account data needed to execute it (sender account and other accounts involved).

This transaction is broadcast to Solana (participants are set by account data). The proxy operator is considered the issuer: they will be rewarded.

The transaction is finally transferred to the Neon virtual machine. Its signature will be verified according to Ethereum rules. If it is valid, the transaction is executed on the Solana blockchain. The N-trx have been previously tested, which means that Solana can execute them in parallel.

Benefits

From a practical point of view, the first thing that jumps out is that there is no need to change the code of the dApps to port them to Solana. No additional resources are required. Similarly, client software only needs to connect to the Neon proxy – no need to modify them.

Developers can now use Ethereum tools to create and deploy their smart contracts on Solana (or port their dApps). Neon’s virtual machine can be updated at any time (unlike the EVM).

Advanced Operation

The developers of the Neon Virtual Machine ( Neon EVM ) have focused on the speed of transaction completion. Similarly, they propose a solution to create liquid tokens for Neon EVM users, circulating on Solana.

There are different components within the Neon architecture:

User

He has an account on the EVM Neon and a balance in ETH, ERC-20/ERC-721.

S-trx (Solana transaction)

Transaction generated according to Solana rules.

N-trx (Neon transaction)

Transaction generated and signed according to Ethereum rules.

Neon EVM Client Software

The application has the EVM bytecode of a contract within the Neon EVM. N-trx transactions are generated according to Ethereum rules and sent to the proxy. In order to cover the costs of the operation, the necessary funds are transferred within a Solana deposit.

Neon EVM Operator

A Neon EVM operator has a Solana account and can deploy one or more proxies. They can configure them as they wish. It is also possible to use multiple Solana accounts and a single proxy.

Neon Web3 Proxy

This is the software that the operator uses. For reasons of transaction processing speed, it is a separate component, although it would have been possible to integrate it at the browser level for example. The proxy must be able to process multiple processes in parallel.

The proxy integrates a Neon EVM emulator to pre-test the transaction execution on Solana. These tests will determine the amount of coins required on the trader’s balance so that it can complete its task. Similarly, the SOL/ETH exchange rate is fixed at that time.

N -trx are transformed into S-trx. N-trx are signed by a user, but S-trx are signed by the operator. Messages corresponding to N-trx are stored on separate Solana accounts.

The features already implemented on the Neon testnet are:

• Receiving Web3 API calls.
• Training responses to these calls.
• Transformation of N-trx and S-trx.
• Read access to Solidity contracts.
• Token wrapper: method for linking SPL contract accounts to ERC-20.
• Converting tokens to pay gas fees.
• Ability to execute a Neon transaction without pre-testing.

The EVM Neon

The Ethereum Neon virtual machine is compiled in BPF bytecode. This VM is deployed on Solana via a multi-signature account. It is from this multisig account that it is possible to change the parameters and code of the Neon EVM.

Neon Governance Participants

Actors participating in the governance process can update contracts, add features, and change important parameters (fee value, Mn value, maximum number of iterations, etc.)

The ERC-20 wrapper

Token “coating” process involves creating tokens on Solana that correspond to their ERC-20 equivalents on Ethereum. The corresponding contract is deployed in the Neon EVM but is independent and contains all user balances.

Tokens created on user request are only liquid within the Neon EVM. In order to make tokens liquid on Solana, ERC-20s and SPLs must be interoperable: this is the role of the wrapper.

Operators and economic incentives

The process of executing a transaction involves several steps. Each step can only be executed once the previous one has been completed. Of course, the number of steps depends on the complexity of the operation.

The transaction is considered complete once the final step is executed. The Mn value defines the number of blocks allocated to operate this transaction. If the duration of the operation exceeds this period, it is considered incomplete.

The trader must allocate funds to execute the user ‘s request . He has a deposit account within the EVM Neon, which is locked (no one can withdraw these funds). Before the transaction is executed, the EVM automatically debits the trader’s account, and places the funds in a deposit account.

If a transaction fails to be executed during a step, the next operator will take over. This new operator does not have to deposit funds to perform his task: if the execution encounters problems again, it is still the next operator who takes charge. The funds present on deposit are transferred to the operator who executes the final step. This mechanism therefore encourages both customers and operators to execute the transaction correctly .

Information about Neon EVM transactions is available to all operators by consulting the state of the Solana blockchain. The proxy scans the blockchain and can thus know the incomplete transactions. An operator taking over will have to sign again with his key. If the number of blocks necessary to finalize the incomplete transaction does not exceed MN, the signature of the original operator is kept. Otherwise, the new operator signs the transaction.

Transferring tokens to Solana

The wrapper has a classic operation. It is a decentralized application whose contract keeps the users’ balance. Users therefore call this contract to deposit their funds.

The user therefore has two balances: his SPL balance concerning the liquid tokens on Solana, and his ERC-20 balance corresponding to the tokens exchanged within the Neon EVM.

This system therefore allows the user to transfer their SPL tokens to their ERC-20 balance, exchange them, then withdraw them.

Bridges: Transferring tokens from Solana to Ethereum

The SPL tokens created by the wrapper must be able to be transferred to the outside. A bridge system allows you to go from Solana to Ethereum. On Solana, the funds are locked in different addresses. They are therefore liquid on Solana under a different name. The process for creating their equivalent on Ethereum is as follows:

Tokens are generated on Ethereum as ERC-20. There is a wrapper deployed for each Solana token type. The system therefore allows Solana applications to interact with EVM contracts (Solidity, Vyper, etc.) and perform SPL – ERC-20 transfers via an Ethereum wallet like MetaMask.

A bridge is a separate contract, and bridge operators are rewarded in fees for the conversion.

Transaction Value tokens

Transaction Value tokens are the tokens that circulate within the Neon EVM.

Indeed, ethers are not directly used within the virtual machine. The calculation of rewards would be complicated. TVTs are therefore the equivalent of ethers, and are generated from the two bridges Sollet and WormHole.

The transfer process is automatic and conversions can be performed in parallel.

The user ‘s Ethereum account is present in the virtual machine . It has two fields: ETH or USDT – the value token identifying the coins, and PAYMENT, corresponding to the tokens intended to pay the operators carrying out the transactions.

Solana accounts, on the other hand, are outside the virtual machine and only Ethereum accounts can access them. The balance of these accounts is in SPL and value token operations use these accounts. Only Solana accounts can manipulate the balance of the addresses concerned. In other words, only the Ethereum account can modify the balance of Solana accounts .

After creating an Ethereum account via the Neon EVM, the corresponding SPL accounts are created and the transfer of value tokens becomes possible.

Operator Rewards

As for the payment of operators, the user has the choice of the token he wishes to use. The account used to pay the operators is created in the EVM Neon: the user can transfer ethers to it using the bridges. The corresponding balance in SPL tokens will be automatically credited but be careful: the same bridge must be used to deposit the funds and then withdraw them.

Developing with Neon EVM: NeonSwap (Uniswap on Solana)

NeonSwap is an open source fork of Uniswap V2. The flagship decentralized application of DeFi is deployed on Solana. Migrating a dApp from Ethereum to Solana is disconcertingly simple:

• Deploying contracts in the Neon development environment.
• Tests.
• Deployment of interfaces.

Conclusion

NEON’s unique features, robust infrastructure and forward-thinking approach make it a project worth considering.