How to scale EVM dApps on Solana - Simeon Kotashki | Neon EVM

one more Applause for Simeon thank you so hello everyone uh my name is Simon kki I'm integration lead for neon evm um couple of words about me I've been software engineer for 10 years the last six years I've been blockchain engineer solidity developer and currently I'm leading integration with neon evm so uh just a quick question how many of you I know it's it's belr but today we're going to talk about uh Solana so how many of you uh Solana and evm not only Solana but how many of you have actually interacted with Solana okay that's good we have some Solana D here trading meme coins uh and and yeah basically what neon evm is uh neon evm is actually um smart contract on saana is not a layer two I would say it's more like of a layer 1.5 and it provides like a compatibility extension uh for um for saana ecosystem what does that mean it means that from one side it combines the benefits of the evm so you don't need uh to change your code uh you can deploy any evm DB on um on non evm and at the same time you can leverage low gas fee local markets uh parallel execution and access to Growing saana ecosystem uh I will go back to to some of them but I can give some some example for example uh low gas fees and local gas fees which is very important so in ethereum how gas market works for example currently in Belgrade you try to order an Uber but in Bulgaria or in some other country there's a concert and everyone's ordering Uber so the Uber will cost you in Belgrade five times more because in some other country it's congested right so the gas market in in ethereum is global for for the whole network how it works in Solana is a little bit different the gas market is local so if for example you have uh One DB that is congested the gas Fe will go on up for for this DB not for the whole network so you can leverage this uh and this is because of the parallel execution of transaction and we'll see how how Solana handles this because we run we use Solana as execution and settlement layer we are like um an application layer evm so our smart contract can understand um evm by code executed and perceive the state in the form of some metadata inside Solana so what we are trying to achieve is 2,000 transaction per second currently we have achieved 700 but uh we are doing some tweaks and upgrades and currently uh a very very big upgrade is uh is coming we just deployed it on devet and we're testing it uh so we'll reach around uh more more than 1,000 transaction per second uh gas fees here it may not be very relevant in dollars because Solana went up a lot so it may be five times bigger but it's still um a lot lower and uh on the upper side you can see what we have like the evm which is actually the smart contract the proxy server which is actually our RPC we're going to see in a moment what is it does Tracer API that you can use for historical data our neon paath that is basically a bridge why I say a bridge it's because it's actually not a bridge it's um SDK and a tool to transfer natively your assets from salana to nonm and because nonm lives inside Solana you can do it even without this bridge uh if you want you just need to be able to compute your instructions and because most of the users and Builders are evm uh come from evm background we make the tooling for them to to use non evm seamlessly and not be able to worry on how Solana works because Solana is very different some of our ecosystem as you can see we support all the de framework truo which is deprecated brownie hardhead Foundry uh we support web3js all open saing contracts remix IDs metamask and so on uh also we support uh chain link price feeds but we read them from saana natively um I will explain to you in in a minute how and yeah this is another representation of the death tooling and this is a very important um uh diagram it shows in a nutshell our AR chitecture so you can see on the right hand side we have the evm program which actually is all transactions always hit first our program and it knows how to execute this EAS and bite code inside the Solana virtual machine and this we also have some composability features currently they're limited so for example you can see SPL token so what you can do this is very interesting you can use an SPL token uh for people who don't know what SPL token is SPL token is the equivalent of ec20 but on Solana and it's um a very different standard there you have one registry one program that basically um uh commands uh all tokens right you don't have like in in ethereum you have one contract one year C20 another contract another ec20 so in ym you'll be able to have a SPL token with erc20 interface and be able for example to deploy a Unis swap Fork pool with meme to uh with meme tokens and so on so this is our first case of composability and Native interoperability with Solana and also the other really really important part is the proxy our proxy as you can see it receives it like transaction it composes a Solana transaction and submits it to a Solana note as I mentioned we don't have a network of nodes uh also um we started with um with uh I would say uh only permissioned list of proxies that can run but this is because of security reasons on on our road map we have um um we are going to decentralize proxy operation so anyone will be able to run their own proxy and to earn fees from submitting transaction to non evm and so on so let's just go a little bit deeper and see how Solana programs smart contracts differ from evm and basically the whole architecture so the whole architecture of Sana is actually um made in order to scale more and the first and most important part is that programs in Solana are stateless they don't have state smart contracts don't have state but they save their state in data accounts you can see program derived accounts on the top so you can imagine Solana being as a very big file system and you have two types of accounts you have executable accounts and you have data accounts in data accounts you have metadata that programs create those accounts in order to be able to persist data and readed and in executable accounts you only have the bite code in the context of neon evm neon evm is the only executable program in our infrastructure living in Solana everything else is in the form of program derived accounts and metadata you can see on the top Corner we have neon account this is actually represent an externally owned account uh your metamask account and you have uh in the metadata you have the address the balance and and everything else and is the same with contracts you can see we have a contract account we store the metadata inside this account and also its storage we persisted in program um in pdas uh there are a lot of uh specific here I'm not going to go into much detail but if there are any builders for example um the first 64 storage slots are are stored in the PDA that contains the bite code and the next ones are just if if for example you need to persist a uh something on slot 65 or 66 you need to create a new PDA actually not you but neon evm will create a new PDA for you and uh basically it will persist the the the data for this storage slot so everything is abstracted away from the user and from Sana perspective these are just accounts that hold metadata let's now see how a Solana transaction uh differs from an ethereum transaction and we have a couple of important things and one of the most important thing that I want to talk about is the account list so account list is actually a list of addresses of accounts that this transaction is going to access why do we need this and why Solana team decided to put account list into the the transaction is because of parallel execution so this account list shows a list of accounts that the transaction is going to read or write from and the most important thing is that if you don't have an overlap in two transactions uh basically because of this account list the Solana not can very easily filter out and Order transaction that can be should be ordered simultaneously and transaction that can be uh B basically uh should be um executed one by one sequentially and uh our proxy as I mentioned is very important because the proxy takes receives um evm transaction performs a simulation on a local environment uh and finds out which accounts this transaction is going to read or write from then puts this into the account list creates the composes the Solana transaction and submits it to um uh to a Solana note as you can see the program index is also the nonon evm program this is the only program in our ecosystem and also we have some metadata which is uh just related to the uh evm transaction we have nons we have gas PR value data and so on and basically this data is read from the nonm program it knows how to decode it knows how to uh for example you know in inside the data we have the function signature um uh and so on and on so yeah this is just a very simple diagram showing how basically the uh Solana node uh decides based on this account list which transactions can be executed simultaneously as you can see inside the note we have a lot of transactions not only for neon evm we have old Solana transactions and basically transactions that are uh accessing different parts and different contracts will be executed simultaneously that's why we have local gas fees and and and local gas markets something very important about incoming features as I mentioned we have our first use case of um composability and interoperability is SPL tokens uh but uh we have some more things to come uh Bridges we we already have the the bridge which is uh actually uh supporting us and you can uh transfer assets between I think 18 EVMS maybe they're more to Neon evm and also from Solana but for from Solana you have the neon pass our native Bridge which is actually very secure because you don't have um you everything happens in one transaction neon paath only computes the instructions for um that uh that has to be uh basically passed to the neon evm uh program multi token gas payments this is something cool um users will be able to pay with their gas token of choice for example you'll be able currently you are only being able to pay with neon but in the future you'll be able to pay with Solana usdc usdt and uh maybe some more other tokens will be added but um and how this happens we abstract the away the whole Logic on our site and we'll have different rpcs so let's say you will have a network that will basically when you connect to it it will show you your native balance in Soul and you'll be able to pay with so uh same thing as for usdc usdt and all other tokens and uh personally for me is the most important feature is General composability as I mentioned you can currently have uh natively erc2 tokens that underlyingly are SPL tokens but but we want to achieve General interoperability what what does that mean that means that from any from your evm smart contract on neon evm to be able to call any Solana program uh for example you can build a DEX aggregator on neon evm that can basically route the users not only through neon evm um dexes but also through sonana Dees for example Orca radium you can um also um uh you know the use cases expand a lot and um currently what we this future is deployed on devet uh the integration team is actually testing the boundaries of this feature creating uh some tools for Developers for example we have built solidity libraries on how to encode the code instructions on how to uh and um because in in Solana everything is uh base 58 and base 64 and coded is not hex and coded and uh yeah we're trying to build initially the tools tutorials before uh showing it to the uh wider audience and um yeah yeah that was basically it so I didn't want to overwhelm you with a lot of technical details because it's it took me around three or four months to understand what the heck neon evm is doing and it's actually really uh uh really complex thing but uh yeah if you have any questions I'll be happy to hear them now or after my speech um if you find me anywhere just say hi and we can discuss and think thank you any questions uhhuh just wait for the mic please real quick so I just missed the start of the presentation so I wanted to confirm like uh essentially what's going on is that the evm bite code is only being executed on the nodes themselves never for example within the context of a salana program right what salana is being used like as a storage layer essentially not not quite like that so basically even all the execution is executed on Solana so yeah on on offchain we only do a simulation of the execution in order to determine the accounts we are going to access in this transaction and to compose the Solana transaction yeah yeah yeah okay great thank you very much M maybe something to add oh yeah okay yeah uh some something to add about the composability we have our own pre- compiles and for example we have a pre-compile that you can read data from any account actually I showed this uh two days ago on my workshop uh in East Belgrade hackaton that you can read from your solidity contract any data from from Solana this is how we read chain link price feeds and pit price feeds from from Solana yes what are the security risks of the neon evm approach and how did you address them what are uh security issues security issues uh basically if we try to compare neon evm to any Layer Two I would say that we are way more secure because we don't have a separate Network we don't have a sequencer uh as you can see two days ago I'm not going to mention uh one of the L2 they stopped their sequencer because there was um there was a hack so uh currently we cannot do that in uh partially because uh the security risk are in the proxy currently and why is that it's because as I mentioned we started with um uh centralized approach and WID listed approach of proxies currently we have P2P and ever stake to operate our proxy we don't share it with the public and this is because of um how do we manage to um how do we manage to execute iterative Transaction what does iterative transaction mean Solana in order to scale is very limited in how many uh computational resources one transaction can use in the evm it's 30 million gas it doesn't matter how big your transaction if it's up to the block gas limit you you would be able to execute it for Solana is not like that so sometimes and a lot of times in defi one neon transaction actually um equals to 20 30 50 saana transactions so uh we have divided it into into two stages the first is the evm execution so you execute all your smart contract code you on a separate data account in Solana you write all the state mutations that you have to perform and after that you uh in the last iteration you perform those State mutations and when uh whenever this uh whole uh process goes on WE lock all those accounts in order to achieve atomicity because Solana noes you submit all the transactions in batch and Solana Noe doesn't give you um so Solana doesn't give you a guarantee on how it will order the transaction it will uh it doesn't give a guarantee so we lock those accounts and the only security risk is if we open source everyone to be able to run a proxy there may be a malicious proxy that will lock some key accounts for example some assets some contracts and so on so we are with the new composability feature we are pushing uh an upgrade that will be basically an optimistic locking and we are going to remove this uh locking from the contracts and optimistic locking means that uh in the um beginning of each transaction we are only going to save read and write revision of each account and at the end of the E execution we're going to compare this WR and write revisions and if they match if if the the data was not corrupted we can finish the transaction if not we will retry it so we will not lock any accounts after this upgrade so the only uh in in in wordss the only security issue and security precautions are in the proxy and uh currently after this upgrade um there will be no real security issues and also we have uh six five or six audits I'm not sure you can check on our website uh of our evm does that allow front running front running of transactions or no uh front running from uh basically yeah you can front run transaction but you can front run transaction in an evm this is not a security issue uh by itself it's just a mechanic of uh how the network works so uh you can but we are also pushing EIP 1559 which implements uh uh gas uh um PR priority fees so users can decide what priority fee they want to put and if they want their transaction to be front or not I mean that's they just a mechanic of of of of of how de centralized networks work thank you thank you do we have any other questions all right thank you Simon