Neon EVM in practice — Andrei-Silviu Dragnea | Neon EVM

yeah there does okay hello everyone again uh I'm Andre I'm part of neon evm I'm a senior rust engineer there and today tonight I'm going to talk to you a bit about neon evm first of all what is neon evm neon evm is a Solana program implementing the eum virtual machine um and we built this project because we want to exploit the benefits from Solana like parallel execution low gas fees and high transaction speed uh in order to allow developers who already have solid smart contracts to deploy them directly on Solana uh inside neon evm and be able to reuse their code existing code from solidity uh of course we also support uh all well-known ethereum tools uh and also provide an etherum RPC um compatible RPC where you can u i mean the user sees uh an ethereum chain when interacting with it but behind it it's still Solana we oh we have been live on mainnet since July 2023 and of course apart from the salana program we have a whole infrastructure around uh that salana program to make it work at least easily for our users so first of all is the evm Solana program then is the proxy server which is a very very important component because basically when you interact with RPC endpoint of course the RPC is not part of Solana it's a separate web service where you send your um uh send transaction request for example and U proxy analyzes it packs it into a salana or more salana transactions and submits this to salana for execution and also collects the salana receipts and extracts um eum data from that uh from those receipts and another important part that the proxy does is is um neon transaction emulation because as you uh as my previous speaker showed um Solana has to give all the account inputs for a transaction before actually executing it even you have an iner call in a Solana transaction you have to know all the accounts from all the iner calls that will be used in that transaction and ethereum of course does not require that so we basically have we have evm implemented in two ways first as a Sol program itself with the same code base and secondly it is also part of our proxy server app where you can call it through a web service and that web service implementation will uh Trace all the Solana uh accounts that are actually used by our implementation and we'll provide them as input for the uh Real Solana transaction that will be built the Tracer API component is also very big part of our system uh oh okay and it's responsible for example for Co light Deb transaction where you want to replay a transaction from the past in ethereum you can use this you can do this because ethereum stores historical data but Solana doesn't basically uh you cannot answer a question easily in Solana like what is the state of an account at a certain slot in the past so how we do that is that we uh sonana has um um plug-in system they are called Giza plugins there are some small rust libraries that you um hook into the validator so validator when you start it those um gizer plugins add some um custom uh logic to the validator when uh the transactions run we store all those uh transactions and account changes into a database in our system and then we use that database in order to query it when we want to replay preview um neon transactions uh neon pass is um used to bridge Solan SP tokens on onm because of course since Sol SP tokens are the equivalent of ERC tokens on neon on ethereum and uh of course we can use them very easily in neon evm because we are on top of Solana um neon foret is a devet foret that we can U use to give our developers Neons to work with and neon da is used to coordinate all main net updates on our system okay as I said this is our ecosystem and what we support at the moment we support all the dev tooling that people are familiar with I myself use remix a lot for example for uh deploying and uh debugging transactions on neon evm and seeing that they behave the same as the ones on uh on the real ethereum chain we support the known wallets of course apart from the our native Bridge neon pass we also support the bridge um and this way you can um exchange any any uh token from any VM compatible chain on top on neon VM 2 uh we also have two block explorers uh neon scan is very um similar to the E scan actually I think it's built by the same team um okay we have two proxy operators because our proxies can be run by anyone and [Music] um this is it when it comes to our infrastructure let's talk about about a bit more about the architecture so we have a the frontend that interacts with an rpcn Point U etherum convertible RCN point that is the neon proxy it submits to it ethereum like transactions um the proxy as I said emulates it first collects the Solana accounts that need to be used to build that salana transaction and submit it to the salon node the salon node has the neon evm program inside it the neon evm program executes the transaction and then um proxy also uh analyzes as I said the Solana resist in order to collect the ethereum metadata from it this is May the most U one of the most important slides because is the structure of the Solana accounts that map all the eum chain State let's start from the neonian program it's only one is the uh Solana program containing the eum virtual machine in the data field of that um account and from this we have um hierarchy of program derived addresses what what program Drive Tes are they are a concept specific to Solana and they are basically some Solana accounts whose addresses are derived from the newm address and only uh can be modified by the newm program so there is um ownership relationship between them and um let's take the each field of ethereum account and see where it's stored for example if you have have a normal ethereum account of course you have a nons for it you have a balance and this is stored in a normal neon account like this one in the data field of a Solan account and for example when you uh submit a transaction that is a simple transfer on evm it will just access two uh sonana accounts for each balance basically they are called balance accounts it will access two balance accounts for those uh neon accounts and uh do the change in the balance the most the interesting part is how contract data is stored because uh for a contract we have to store the bite code of the contract when you deploy it so we have a special contract account for that and we have to store the storage slots the etherum virtual machine uh stores uh the contracts data into the sto some storage slots which is a basically a big hash map for each contract itself uh by itself and um the solidity bite called high LEL it looks like it has variables but behind the scenes all those variables get down uh compiled down to story slots and we have uh an optimization some story slots are stored in the same contract account here as part after the bite code itself of the contract and um other story slots are stored in their own Salon accounts and we have uh quite complex program deriv logic because we need to be able to uh map the addresses of those Solana sorry of those story slots to the Solana accounts themselves I won't go into details now but it's it's maybe the most complex part of our account logic and basically if we have balances nonis the code of the smart contract and the storage slots we can store the whole etherum chain uh inside the Solana account model okay now this is is the thing that makes this project complicated um as you know ethereum transactions can be big from two points of view the size they can uh for example go ethereum I checked recently it can process ethereum transactions as much as uh one megabyte in size theoretically at least and um on the other side sonana transactions have a fixed maximum size of only 1,332 Byes so very very small and we need to somehow be able to execute a very big ethereum transactions using very small sonan transactions and how we do that apart from that there is another restriction uh of Solana transactions they have a fixed number of compute units basically the gas from etherum world has an equivalent in Solana in compute units one uh son transaction can execute at most 1.4 million uh compute units and I think the maximum uh gas limit for a block in ethereum is 30 million gas or something like that they are not one to one because for example our ethereum virtual machine for doing a basic operation in ethereum it can run a rot of compute units on Solana so it's there is a no oneon-one um mapping with between these two but basically we cannot store um ethereum transaction inside the instruction field of a Sol transaction so the first um change we have to do is to store the ethereum transaction inside the Solano account itself so basically when we uh submit uh sonan transaction to the newm program we one of the input accounts will contain the transaction itself for the E on virtual machine to execute and the second um magic thing that we have to do is uh iterative transactions basically the evm doesn't have enough time and Computer Resources to execute the whole etherum transaction inside one Solana transaction so how we do that at the moment we serialize and deserialize the evm state between iterations of the same uh ethereum transaction and we um let the VM continue execution from where it left so basically we have to store all the changes uh that the evm does what during execution because you also have to be able to revert them evm has quite um complex uh features when it comes to how much you can revert of a transaction compared to Solana where is something like if some anything bad happens all the transaction fails you cannot recover from anything and um in case of iterative transactions we commit those change those changes only in the last iteration if everything is successful and otherwise we could revert some changes and that's why for example all the change that we do like setting a storage slot or incrementing the NS or incrementing the balance we are storing them as um a list of changes into the evm itself and only at the end we commit them to the chain or maybe just drop them completely okay um and of course here it's the thing that I talked about the fact that um you have to give to the Solana transaction has input the list of Solana accounts that contain the states of all ethereum accounts used in that transaction um okay uh about parallel execution basically if you have I mean this is the difference between evm and eum uh if you have two etherum transactions that for example uh transfer some funds to two different people that are unrelated to each other I mean the two transactions of course they will be executed in parallel because this is how Solana works this is actually why Solana requires you to uh declare all your accounts beforehand and also to tell if they are only read read or also written in that transaction because if it doesn't see any data race between the two Solana transactions it will execute them in parallel and we are striving to create Solana transactions that are uh as decoupled as possible in order to um allow evm new evm to run more transactions concurrently and um okay this is an incoming feature that is not uh I mean it's U specific only to Neon evm but uh it's not very evm Centric basically because neon evm is a Solana program and Solana programs can call each other of course we want to be able to allow people to call Solana programs directly from from inside uh solidity smart contract let's say it will not be easy will be very limited but it can be done and basically how we do that is that we I think you know about the promiles of ethereum we have some additional pre-compiled addresses that are actually accessing Solana specific features for example we have also you can also deploy an erc20 contract on our Network and we have some predefined ones but um how we Implement rc20 on our side is by using the SPL token Library behind the scenes so basically there is a precompile in our bite code in our neon evm implementation that delegates to the SPL token Library so basically ic20 is only an interface to SP token uh in case of neon evm okay so this was overall my presentation I think it was very technical but I hope I CAU your interest at least a bit if you have any [Applause] questions hi hello um in case uh this transaction wants to access some storage slots let's say uh do I have to know the exact storage slot uh for let's say I want to execute a transaction that modifi some state do I have to know uh St in advance to specify it as a as a input yeah yeah and also I guess if you could just can validate this but if two transactions are accessing the same toot my guess is they cannot be executed in parall right yes they won't be able to execute in parallel because Solana won't allow that yeah but uh if I want to have some transaction to alter the St I have to know the storage slot as a user or does that um neon Rel solve that problem uh you can anyone can call neon evm Sol program directly but it's very low level it has some very lowlevel operations that are very hard to interact with as an ethereum developer and that's why the proxy component in this case first emulates a transaction and basically executes I mean executes the transaction itself uh as um API call and it uses actually the Solana rpcn point to retrieve all the Solana accounts that are used in that transaction and see if you can emulate it successfully and after it emulates it it will know already all the accounts that it needs and yeah you're right you will it will not be able to execute two smart contract calls that access the same uh storage slot and actually we are working on making this very granular so even if you access the same smart contract but the storage slads are different you should be able to run them in par yeah yeah thank you that my question welcome questions okay thank you and