Neon EVM 🛠Ethereum dApps Deployed & Run on Solana
ETHGlobal·Wed, Oct 9, 2024, 12:00 AM
Join us for a NEON EVM Workshop! From November 17-19 2023, ETHGlobal welcomed developers from around the globe to take part in shaping the future of Ethereum at ETHGlobal Istanbul. Over $600,000 USD in prizes were given away at the prestige Istanbul Congress Center... thanks for an amazing weekend hackers! ----------------- Follow us: https://x.com/ETHGlobal?s=20 Check us out: https://ethglobal.com/ Email us at: hello@ethglobal.com
Transcript
[Music] today I will show you a very cool demo of how we can have how we can support a single token existing uh natively on both chairs of neon and salana without the need of always bridging when you have to interact with the contract from the other chain but first two or three words about what is new evm what are we doing so basically new evm is providing a solution which is combining the adoption of uh ethereum tools and Solana's fast and cheap transactions so uh NE evm is is not a side chain or or a layer to protocol it's actually much simpler it's a smart contract living inside uh Solana so uh basically uh uh how we manage to support entire evm inside Solana well basically because Solana allow allow us to uh store a bit more executable data compared to ethereum I think I think it's somewhere around 10 megabytes which is pretty much enough to store the entire evm uh basically we have uh we call it neon proxy but it's basically uh ethereum like RPC which is listening for ethereum like transactions and basically what happens is when when such transaction appears our Ren proxy unwraps it and wraps it again as a Solana like transaction and because we rely on soana because beside the fast and cheap transactions we also benefit from the parallel execution of the transactions and which means that all of the transactions run on newm are basically getting executed in a parallel way instead of sequential way and this is also happening because uh neon is stateless which means that the contracts on uh which means the contracts on this this is also happening because the contract on Solana is stateless because they do not hold any state but they they hold only their executable bite code uh and uh one more thing to mention is that we also support the majority of up codes uh next thing yeah so we we basically new evm is a very easy way to take to use your ethereum stock and use it to deploy on Solana you can use pretty much all of your uh most famous ethereum stock like Foundry like uh hardat like solidity Viper even the most famous uh wallet such as uh metamask wallet connect to basically uh Deploy on Solana which is pretty cool because me personally as a Sol developer I don't have to change my stock at all to deploy and Sol and benefit from the from the fast and cheap transactions yeah yeah now now uh going back to My Demo today I will be showing you uh a standard of hours which is called is24 SPL this is like the first use case of how we can support uh neon contracts interacting with salana natively so first we will be using a harut one of the most widely used Frameworks for depl pling on on uh on ethereum in harut config we have defined two networks which is first the neon devet the second one is the neon main net and for the demo we will be using the definite one now going to walk through the co contract as you can see at the top we have defined uh basically using two Li two libraries out of the open Z package this is this is pretty cool because just the other day I saw some random developer on on the Sal forums asking is there's something like open Zeppelin on but on Solana and of course there isn't currently but this is a option now how to basically use open zelin and Deploy on Solana the next two more interesting stuff are these two interfaces so uh basically what is the SPO token SPO token is the equivalence of earc but on sudana it's a bit more different because currently in ethereum we have a different uh set of Standards like earc 20 earc 721 and so on but in Solana it's it's a bit more centralized when it comes to this because there is like one central registry and this central registry is the protocols of SPO token which is used to uh deploy basically any token on Solana so yeah that's pretty much for token as you can see here on this line we are creating the interface for the SPO token registry and this metaplex right here is basically uh a set of protocols which you use on Solana for example when you deploy a new token on salana basically use metaplex to attach some metad data to it such as a token name token symbol for nfts you can use also Roes fees and so on and going down to the contract you can see that we support pretty much the ec20 interface we have name symbol decimals uh balance of transfer transfer form but I want to uh pay more attention to these two methods so basically approv Solana and transfer Solana are pretty much the same thing as uh transfer or approv in Arc but the only difference is that this would be used in the case where the receiver doesn't have a ethereum like uh wallet but he has a Solana like one so basically you can see that the two parameter right here isn't is not in uh a type address but instead is in byes 32 which is actually the Solana address and encoding this value into uh base 58 it will return you the r public key of sudana uh one more method that I want to highlight here is this one the Solana account okay so uh one important thing to mention is that when you interact with the contract for the very first time behind the scenes there is a there is a Sana key pair creation for your ethereum like wallet so but uh this is only happening the first time and this is why the first transaction is a bit more uh expensive but once done that you don't have to do it always and uh yeah I will show you in a bit how how is this happening uh going through my uh deployment script so the deployment script is very uh you can see it's very basic one at the top I have defined two users for the demo uh this is my deployment script of the ec24 SPL uh One Thing Worth mention here is that this this is the decimals of my contract so because the end goal here is to uh Deploy on Solana basically we have to uh adapt with the Sana limits and currently you cannot store more than a bigger value than un 64 so you are limited to using nine decimals uh here A bit down I'm I'm meaning uh the first tokens to the owner meaning a th000 tokens then a bit down I'm initiating two transfers uh they're pretty much the same with the same message sender with the same receiver and the same amount and I will show you why why I'm doing this and at the bottom uh I'm just displaying the ethereum like and the Solana like wallet addresses for each one of my users in this demo okay let me just run the let me just run my deployment script now as you can see the command is nothing special just like a usual uh way of deploying through harut just with the different network which is uh new divet uh okay we see that our Pro proxy has been minted uh we see at the at the beginning that nobody of the user has uh a balance by the time of the minting we have minted a th000 tokos to our owner and then after doing the the two transfers our owner is left with 800 and the user is left with 200 and these are also the ethereum like and the Sol like addresses for each one of the users now if we check this proxy in our devet new scan yeah we can see the proxy has been uh deployed successfully now if we uh scroll down to the transactions we can see this is the first one which is the deployment the second is the meeting to the owner and third and for are the transfer from the owner to the user uh the first one here the more interesting stuff is uh for this new transaction we actually have four different Sana transactions and this is happening because what I did mention in the beginning is that we have our new proxy which unwraps and wraps transactions but there there are uh differences in the limits between Solana and ethereum like chains basically uh if most of you should know that uh in ethereum you don't have like a memory limit of your transaction you're pretty much limited by the block gas limit but in Solana it's it's a different story you are limited by a bit more than than a kilobyte so in this scenario uh if our neon proxy has taken this uh neon transaction and submitted as one into Solana this was going to revert but because neon proxy is was smart enough to see that okay this is not going to work it splitted the main the main ethereum like transactions into four smaller Solana transactions now uh let's look at the other two uh the other two transactions yeah this is the meeting as you can see meaning from zero address to our owner a th000 tokens and the next two transactions are the two transfers which are the pretty much with the same data so this is the first transfer and you can see that the fee currently is uh 0.26 and for the second transfer the fee is 0.1 so the difference is more than uh 200 times and why is this happening uh let me show this is because what I have mentioned earlier behind the scenes for your very first transaction there is a a creation for your ethereum like wallet so going now to San scan and scrolling down to the instructions we can see that okay there was a token transfer with a with amount of 100 tokens and this is our source this is our destination and if we uh double check our Salan like wallet addresses we can see that the destination is our uh that the source is our owner and the user is our destination but why is this transfer a bit more expensive actually not a bit but 200 times more expensive the than the second transfer is because this uh user address hasn't yet never has has never yet uh interacted with the San contract and basically the first transaction is like initialization one as you can see we have a instruction here which is initializing the salanas account for the user and in the second transaction you can see that there is no such thing I mean once you do it you don't have to do it twice and this is why this transaction is 200 times more cheaper basically this is the the only the token transfer so yeah that that was that was pretty much our first use case of how we can have uh neon contracts interacting native with Solana contracts another use case would be okay for example in Solana there is a chain link deployed with the different price feeds and so on and because it is deployed there we don't have to deploy it also on nun we're basically taking the price feeds directly natively from new to Solana uh One Last Thing Before uh I finish my demo uh guys we're live on minut it since this July we have like a different set of products like the evm that I just mentioned which is a smart contract inside Solana the processor which is smart enough to unra and wraps again transactions the Tracer up which is getting a huge update very soon uh which is helping developers to debug their stuff the neon pass which is our uh Native bridge between uh neon and Solana the new faet for sending testing amounts to users on the defet so they can play around with their stuff and the de the new which is our governance so yeah that was pretty much about my uh demo for today uh please join us give it a try and start building your stuff thanks guys and what yeah thank you thank you and one more thing to mention is that we have our kakon today and tomorrow you can join up and try to win some real wordss the second one is very cool we would like you to basically destroy our devet we want to see how much it can handle yeah so yeah any any questions so far okay if you have some question just find me some somewhere here at the event and let's talk yeah yeah that that that that was a deploy on on on Solana true neon by using yeah uh so so currently you cannot uh you cannot rely on any of the etherum state we don't we don't rely on that we only rely on the Solana State yeah yeah but basically you can use any kind of ethereum stock to deploy basically newm is like taking your uh solidity bite code and transferring it into Sana
Automatic transcript — names and jargon may be misspelled.