Neon EVM: Bringing Ethereum and Solana together - Hugo Cavaleiro | Neon EVM

Uh, hi everybody. My name is Julia. I'm a devo at new VM and I'm here to show you how you can bring Salana's liquidity and user base to your EVM DAP without changing a single line of your Solidity code without adding Rust or learning Salana architecture. So my question to you is how to add Salana's liquidity and users to your EVM DAP. Uh have you ever tried doing that?

I've talked to someone today who has actually attempted it and I'm curious to know if he's here or if anybody else has ever tried it. By a show of hands. No, nobody tried it. Uh are you familiar with Salana Salana architecture? Okay.

and uh other people are from Ethereum. Okay. Uh that's great. Uh then I'd like to present you how we are tackling this problem adding Salana liquidity and user base to EVM devs. And if you have other ideas, I'll be happy to hear them at the end.

So by asking this question we have created neonvm which is more than just EVM compatibility because it contains both Ethereum and Salana benefits and of course for EVM developers the main benefit is that you don't have to learn Rust uh to switch to Salana and you can stay within your EVM comfort zone using all the same tools that you're familiar with. hot hat. You can write in solidity. You can connect with MetaMask and use Ethereum RPCs and you can add Salana benefits all the at the same time. You can use the its parallel execution, its low gas fees in your app and access the growing Solana ecosystem with a huge user base.

So what is Neonvm? How does it do all that? Uh first of all, you might have thought that neonvm has something to do with a bridge, but in fact, it couldn't be further from the truth. It's not a bridge or an L2. Uh in fact, Neonvm is a Salana network extension.

It's a program on Salana that lets you execute EVM byte code within Salana runtime. And it does that by having two main components neon proxy and neonvm program and also by including different composability libraries and pre-ompiles that abstract away salana's architecture for EVM builders to incorporate into their solidity caller contracts. Uh so as I've started uh telling you there are two pillars of neonvm which are the neonvm program that lives on salana and executes EVM bite code and neon proxy that prepares transactions offchain and translates EVM logic into Salana constraints. Uh so the transaction flow for uh both EVM users and Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Sal Salana users would look like the native flows, the flows that they're used to because an uh EVM user can connect to a DAP using a MetaMask wallet and at the same time a Salana user can connect to a DAP using the Salana wallet like Phantom and each of them can uh uh use the functionality and the connect to Salana programs and use Salana tokens uh by just uh connecting to your DAB and sending their transactions and the neonvm user uh will send an Ethereum like transaction which will be uh let me show you here. So they will send an Ethereum like transaction which will be translated in the neon proxy with the help of the neon libraries into a salana transaction.

So the EVM transaction will be included in the data field of a Salana transaction and it will be sent to a neonvm program a program on Salana which uh where by the way your smart contracts should be deployed in order to do all that and it will execute the transactions so that you can use uh for example SPL tokens like USDC or soul or you can um connect to Salana programs like radium Metaplex or Jupiter or other custom programs as well with the help of uh the composability libraries that uh contain the architecture of Salana and these programs in them. So and for Salana users uh the whole experience will look like a native Salana experience because they will just send a Salana transaction and uh Neonvm will add EVM bite code to this Salana transaction when sending to neonvm program and again then the user will interact with Salana programs and Salana and SPL tokens. Now, how does Neon make sure Salana logic is triggered from solidity contracts in the most seamless way possible so that EVM developers don't have to suffer through the learning of Salana architecture. Uh it's all in the works of composability feature and composability feature by newvm is constructed of uh libraries and pre-ompiled contracts that allow the transactions to become atomic when sending to Salana that ensure interoperability of tokens by introducing a new hybrid standard ERC20 for SPL which is an ERC20 wrapper for SPL token and uh by including instruction in coding within the libraries so that when you import the libraries you get the instruction generation in a way that Salana expects to get them and also all the account and state management is also abstracted away from the EVM developer so that you don't need to understand what kind of accounts you need to make uh how to save uh the balances how where the balances are stored so uh everything is abstracted away by this library so that you don't need to even know what's going on there. Well, of course, it's better to know what's going on there, but uh I mean you don't have to learn.

Um and uh behind the scenes composibility consisting of the libraries and the pre-ompiled contracts starts from the caller contract that integrates that imports composability libraries and uh sends the um generated instructions to the pre-ompiled contract. uh sends a direct call to execute the instructions to the pre-ompiled contract which does that on Salana and again if we zoom out a bit from the caller contracts libraries and pre-ompiles we see how composability and Salana native SDK allow both EVM and Salana users to interact with Salana programs. So we have two main entry points for the users. On the left we have new NVM users or just EVM users who access Salena programs through uh the EVM wallets and on the oh sorry and on the right we have Salena users uh who access the same DAP but through Salana native experience because when they request a DAP action uh so for example send a transaction make a swap uh the Salana native SDK created by neonvm gets this transaction and sends it to data account. It transforms this transaction to include EVM bite code and uh the neonvm operators that run neon proxy uh get this transaction from the data account and send it back to Salana.

So that neonvm can execute it on Salana natively and directly. And this hybrid architecture does something very powerful. It unifies developer and user experience across chains. Uh DAB developers write standard solidity contracts and deploy to new VM and then both EVM and Salana users can interact with the same logic with no separate deployments or bridges. It's not a side chain.

It's not a bridge and it's not an L2. It's a Salana native runtime that unlocks full composibility between Salana and Ethereum apps. Thank you so much for your attention. If you are looking to build something crosschain or cross runtime, we'll be happy to answer your questions and talk. Thank you.

[Applause] Any questions? Yes. Hey, thank you for the presentation. I have a question related to the risks. Which risks as I as a developer have while I will use like neon VM comparing to like another uh L L1 or L2 chain?

Thank you. Well, I will need to check with our auditors and security engineers because I'm not uh specifically um yeah um working with the risks. Uh but you you should know that uh this is going to be uh slower. So you will need to accommodate uh that. And also um the integration isn't that simple.

So, it's great that you don't have to have two code bases that you need to maintain, but at the same time to allow for this to um integrate into your smart contracts, you will need to um understand how to use the composibility libraries and the pre-ompiled contracts. Uh but uh um yeah, again, this is uh simpler still than learning a whole new ecosystem.