Hello everyone! We continue to talk about interesting projects that have got our attention. Today we have Neon Labs in our sights.
The idea to create Neon was born out of necessity: Solana have been having difficulties to find developers, while the creators of dApps on Ethereum suffer from low scalability and other network costs. At the same time, it was needed a technology that would be “friendly” to developers, and would not force them to rewrite contracts. This is how Neon Labs was created. It builds an EVM that makes it easier for Ethereum-based applications to deploy on Solana.
Neon EVM is a virtual machine through which application developers can use the scalability and liquidity provided by Solana and tools from Ethereum. This symbiosis provides the creators of dApps with low gas rates, high transaction speed, parallel execution of transactions, high throughput, and also opens access to the growing Solana market.
The number of active dApps on Ethereum is now above 300, and the number of active users of these dApps is approaching 6 million, while the number of transactions is growing. It is obvious that Ethereum remains the dominant blockchain protocol for trading smart contracts. Therefore, developers simply need such cooperation that combines the advantages of both projects. The Neon EVM cross-chain solution opens up new opportunities for developers, such as arbitrage or high-frequency trading, allows them to expand the user base. They can also take advantage of early users and attract new customers to Solana. The project has its own NEON token, which will be utility token used for gas payment at first and later it will serve as governance token as well once they switch from council to compound governance. To pay for services, users can use NEON (later ETH/ERC-20 tokens as well).
Neon EVM is built as a Solana smart contract. In addition to the advantages listed above, it is also worth noting:
· Applications can be written using familiar languages: Solidity and Vyper
· The deployment of Ethereum dApps applications is carried out without any changes in the smart contract tools
· The usual Ethereum tools are used in development, such as MetaMask, Truffle
· Neon EVM is easily updated with new Ethereum features
Neon EVM is written in Rust, and, like Solana, uses a BPF virtual machine. A Neon EVM user is any user who has an account in Neon with a balance in NEON (later ETH/ERC-20 tokens as well). Client is any application that has an EVM byte code contract (Solidity/Vyper/etc.) uploaded to Neon on Solana. The network operator is any Solana account that pays for the execution of a Neon transaction in NEON token (later ETH/ERC-20 tokens as well) and receives payment for his work from the user. Management is decentralized.
To implement the plan, something was needed that interprets transactions and wraps them in Solana transactions. The project team wanted developers to be able to interact with Solana’s internal contracts and its tokens, which could fly through contracts to the Solana ecosystem and back. Neon Web3 Proxy acts as an intermediary between clients and Neon itself. This is a service that provides a Web3 API for accessing the Solana blockchain, and it can be managed by operators. However, a proxy server is optional, it can be replaced by a client library. Its main task is to help customers start using Neon without any changes to their code base. Proxy has become an intermediary, it services and wraps Ethereum transactions in Solana transactions that go back to Solana nodes, and Solana validators verify and process them, and then call the Neon EVM contract.
Neon EVM Functions:
● Uploading EVM contracts (created by Solidity/Vyper compilers) to separate Solana accounts.
● Verification of signatures in accordance with the rules of Ethereum on Solana.
● Execution of Neon transactions
● Calculation of gas consumption in accordance with the rules of Ethereum.
● Receiving payment from the user to the Neon EVM operator for gas consumed and fees
● Calculation and withdrawal of commissions in $SOL tokens to the Neon EVM management pool
● Storing EVM data of contracts in the form of a hash table using a matched hash array Algorithm Trie (HAMT).
As we have already mentioned, Neon EVM performs Ethereum and Solana transactions in parallel. To do this, several strategies are implemented: each smart contract stores its data in its own Solana storage, and account balances used to pay for Neon transactions are also divided. The solution allows you to run any Ethereum application on Solana without any changes to its code base, including UNISWAP, SushiSwap, 0x and MakerDAO.
About parallel transactions. Neon transactions are executed by Solana as their own transactions: in parallel, restricting access to shared data from the Solana state. When transactions are sent via proxy, Solana validators receive them in parallel, then the Neon contract is connected, and they are executed on many Solana nodes. However, in some cases, a Neon transaction requires more resources than Solana allocates per transaction. In this case, Neon EVM performs the transaction iteratively, and the advanced mode of restricting access to shared data in Solana is used.
About iterative transactions. We know that Ethereum transactions can be very long. In Solana, you cannot combine an Ethereum transaction into one Solana transaction, so you need to separate them and wrap them into several Solana transactions, but then you still need to complete one Solana transaction and an Ethereum transaction. To solve this, it is necessary to complete all these Solana transactions and get the final result. This is called iterative transaction execution. The Neon team strives to ensure that iterative transactions are executed in parallel. Iterative transactions call accounts (as well as Solana transactions), and evaluation functions are used to prevent them from being blocked. Solana transactions are executed without final evaluation, without recording the state before the last transactions. This is done in order to be able to see if something happened between these steps. And you could go back and check.
About the independence of operations. Transactions received by Neon EVM cannot be discriminated against because they do not have any attributes that determine their priority. Immutable nonce fields and user signatures verified by Neon EVM guarantee the consistency of Neon transactions and protect against repeated execution.
“Ethereum is a thriving blockchain ecosystem that has a lot to offer dApp developers and users in terms of tools and infrastructure. At the same time, Solana is attractive to many due to its technical characteristics and is perceived as an emerging market”
Marina Gureeva, Director of Neon Labs.
So, Neon EVM has a high level of decentralization, since it is regulated using a decentralized protocol, and any user can set up a Neon Web3 proxy server and receive payments for performing transactions through Neon computers. The project offers an interesting solution for developers. And the team behind it gives us no doubt about the quality of the final product.
On December 7, Neon Labs announced a $40 million fundraising round led by Jump Capital, which included IDEO Colab Ventures, Solana Capital, Three Arrows Capital and others. Neon Labs raised funds through a private token sale, and the proceeds “will be used to rapidly expand the Neon Labs team in categories covering research, core development, marketing and business development”.
Community test of Stake Service operator
The launch of the main network is planned for January. In the meantime, we would like to ask you to participate in testing our NEON EVM operator. To do this, you will only need a MetaMask wallet and 2 minutes of time.
- First you need to connect MetaMask to the NEON operator of the Stake Service command.
Network Name — NEON
New RPC URL — http://18.104.22.168:9090/solana
Chain ID — 245022926
Currency Symbol — NEON
2) Now let’s get NEON tokens for our MetaMask adress
We connect MetaMask and type the amount of test tokens to receive from the faucet.
!attention! This tokens live in devnet Solana chain
We can get no more than 10 NEON at a time. There is also a cooldown of 60 seconds between requests.
3) Now let’s try to send tokens to another address. For our test, we will need an address that we can track to understand how many people took part in our study. Here is our address: 0xbBA6Bc5c6eAfC06b5640C1cdD731e86811910a20
But you could use your alternate address or your friend’s address.
Click send, then enter the address, the number of tokens and confirm the transaction. Have you ever seen such a transaction rate in MetaMask? That’s right, this is the speed of the Solana blockchain right in the MetaMask!
That’s it! Thank you for helping us in testing our Neon EVM Operator!
Welcome in our new web site!
We are a young team of enthusiasts who have set a goal to help in the creation and administration of…
Please follow the news on our Twitter: