How to Access Solana Using Neon EVM - ETHGlobal San Francisco 2024

Thank you all for joining. I am Sukanya , a senior integration engineer at Neon EVM. Today we're going to show you how to access Solana using Neon EVM with your own Solidity smart contracts without writing anything in Rust. First, let's find out what Neon EVM is. Neon EVM is basically a smart contract in Solana.

In Solana, smart contracts are called programs. Therefore, Neon EVM is a program in Solana that can execute EVM bytecode within the Solana virtual machine. Basically, we're not a layer two or a bridge. We are simply inside the Solana virtual machine. Solana can host executable files up to 10 MB.

And since the EVM is about 2 MB in size, you can integrate the entire EVM within it. This is how Neon EVM works. With Neon EVM is how Neon EVM works. With Neon EVM , you can get all the benefits of the EVM ecosystem. Like all existing Ethereum tools, they can use all Ethereum development tools.

Like Hardhat, Foundry, Remix, and you can also use existing wallets like MetaMask, and we've also integrated Trust Wallet. We also have all the RPC methods that already exist on Ethereum available RPC methods that already exist on Ethereum available , so everyone can use them. They are all compatible with Neon EVM. They can also benefit from Solana, such as low fees, high transaction speed, and, most importantly, parallel execution. We have been operational since July 2023.

We have all these components at Neon EVM. First there is the EVM, which is basically the Neon EVM program. Then we have the proxy server, which is the fundamental part of the transactions that take place. The proxy server is what receives Ethereum-type transactions, simulates them Ethereum-type transactions, simulates them , converts them into Solana-type transactions, and sends them to the Neon EVM program. Then we have the tracer API EVM program.

Then we have the tracer API for debugging. Then we have Neon Pass, which is our native bridge from Neon EVM to Solana and vice versa. We also have Neon Faucet for development. They can obtain Neon devnet tokens from there. Finally, we have Neon DAO, which owns the Neon EVM program owns the Neon EVM program .

Well, in theory we can reach up to 2000 TPS and, as you can see, the transaction fees are really very low. Yes. So, basically, this is the ecosystem. We have all wallets integrated, such as MetaMask and Ledger, plus Trust Wallet and Gnosis Safe. As for operators, we have two: P2P and Everstake.

Then we have the Block Scout and Neon Scan explorers. Indices such as Graph and Subsquid. We have Chainlink and Pyth oracles. And then we have the NFT tool from Solana, which is Metaplex. We also have our own bridge, the native Neon Pass bridge, and we also have deBridge integrated.

We have many DeFi protocols already deployed on Neon since our launch in July of last year. We have lending and borrowing protocols like Lend OS, Lumen, and many other DeFi protocols. As you can see on the board, there's IceCreamSwap, which is a fork of Uniswap V2 in Neon. We have Vibrant Finance, MoraSwap, Liqid Finance and many more. We also have many NFT platforms and games already deployed right now.

You can see the full list here, which includes Versus X, Battle Dogs Arena, and a few others. And we have launch platforms, such as Mintpad and Pixel Riem, that are in the rollout stage. And yes, we have all the development frameworks already available: Hardhat, Foundry, Truffle, everything that is compatible with Ethereum. And also all the SDKs and APIs. So, yes.

These are the development tools already known in the EVM ecosystem. This is basically the architecture of Neon EVM. So, when you have a front-end application that uses a MetaMask wallet to sign transactions, you can perform an Ethereum-type transaction, which then goes to the proxy that is within our operators, who run the proxies. The proxy basically provides an Ethereum RPC API to connect, interacts with Solana to convert the Ethereum-type transaction , simulates it, converts it into a Solana-type transaction, and sends it to the Solana virtual machine, where our Neon EVM program is located that can execute the bytecode. This is what the Neon EVM architecture looks like.

Hey. Basically, the Neon EVM program, just so you know what the Solana architecture is like, because Solana is a little different from Ethereum. It cannot store...programs cannot store any data. Therefore cannot store any data.

Therefore , they are stateless. So everything is stored in accounts. You can see everything is stored in accounts. You can see , for example, Neon EVM, which is basically a program, an executable program. You have a Neon account; you can have a Neon account as your Ethereum account, which can store what is a program-derived address , such as from the Neon EVM program.

It's a derived address for your Neon wallet. And it can store data Neon wallet. And it can store data . The program itself cannot store data. Therefore, Solana is* data.

Therefore, Solana is* stateless*. This is how it works. This is the basic knowledge about how accounts are created and stored in Solana. So. This is how a transaction is processed.

This is how a transaction is packaged into a Solana-type transaction. You can see that Solana's transaction is completely different. You need to have the list of accounts, and that list is basically the set of all the accounts you need to access when executing a transaction; For example, when you have an Ethereum transaction, that transaction can access different accounts, such as different data accounts, in the same operation. Therefore, you must include that list of accounts in the Solana transaction within the proxy. This is what the entire Solana transaction looks like.

You can see that you have the Neon EVM program address and the list of Neon EVM program address and the list of Neon accounts, contracts, and data accounts in the account list. Then you have the Neon EVM program index in the program index and all the Ethereum-style transaction data, such as the nonce, gas price, value, and data; Everything goes into the data field. This is parallel execution , which is basically the main feature of Solana. So Solana can execute transactions in parallel. So, yes.

Basically, today, before we move on to the rewards or talk about how to access Solana or follow the tutorial, we just want you to know what Solana's composability feature is. Basically, Solana has the function that allows you to call a program from another Solana program. This is called the composability function, which also includes cross-program invocation, which is basically invoking instructions from one program from another. That's why our rewards today are also about finding projects that revolve around this composability function. Well, this is how it happens composability function.

Well, this is how it happens : in Neon EVM you have a Neon EVM address and you will have a Solana interface contract in Solidity, which can call an existing pre-build within the Solana virtual machine , and that pre-build contains all the necessary functions that you need to call from the Solidity contract. So you can have the interface and from there you can simply call those methods. So, this is what it looks like. We have the iCall Solana contract, from which you can call the pre-compilation that already exists in the SVM. Uh, yes, these are some of the bridges we have, like Neon Pass, deBridge, and a few others.

EVM chains. And yes, just before we begin the tutorial, I want to give you an idea of ​​our upcoming features, such as the multi-gas payment feature. We're experimenting with it and we'll most likely launch it soon with multiple gas. Currently, when making a transaction, you can only pay with the native token, Neon. But we are experimenting with it and trying to implement multiple gas payments.

You can make payments with SOL or any other ERC-20 token. So, yes. Let's first go to the tutorial to see how to access Solana. You can get the RPCs from chainlist.org.

Type Neon EVM and you can get the mainnet and devnet strings for Neon EVM from there. Good. Yes. So, just to reiterate what I mentioned about the composability function. From Solana you can access, from Neon EVM you can access Solana's liquidity .

So, from your smart contract on Neon EVM, you can make trades on any DEX that already exists on Solana. You can do a swap in Orca, you can do a swap in Raydium or in Jupiter. I'm going to show you how this works in Neon EVM, how you can access it from a Solidity contract to perform a swap in the Solana DEXs. As I already mentioned regarding the iCall Solana interface contract, this is what the interface contract looks like. We have the instruction structure and the account metadata structure, which are basically used when we are creating an instruction that is passed to Solana transactions.

This is what the structure looks like. Then we have the following functions. The Neon address, you can simply pass any existing Ethereum Neon address and get the Solana address from it. Then we have some useful methods like execute, batch execute, and also execute with seed. So, these functions are necessary when we execute transactions, when we send transactions to Solana.

Therefore, we will have to use these execution functions. When we send the instruction and the lamports we send the instruction and the lamports . The lamports are the smallest unit of SOL in Solana. So these lamports are used when we need a payer for a transaction. So, not all transactions require a signature, but some do.

So , for that purpose of signing, we need to have some lamports for the payer. This is how we pass the lamports to the execution function. So, here we have a configuration file. These tutorials are now available on our documentation website. So you can go and check them out there.

We also have a tutorial on GitHub. You'll find all the links there and you can build whatever you need with them. So, you'll find all that material. But yes, just so you know, we have a configuration file here where we've already written all the useful functions that will allow you to perform a swap on Orca allow you to perform a swap on Orca , Raydium, or Jupiter. So, it's already written there.

There are some functions like execute or prepare instruction accounts, about how to prepare all the instructions for the Solana transaction to occur. Then we have this contract, which is basically the contract that contains all the functions for a swap on Orca, for a swap on Jupiter, and for a swap on Raydium. So now I have this function that can be called through our script, which I will run in a few minutes. So, this is a script that processes two transactions in batches. One is a swap in Orca and the other is a swap in Raydium in Orca and the other is a swap in Raydium .

Then I can run it and show it to you. So, Raydium doesn't have a development environment, that's why we need to do it on the mainnet. So I'm going to run the script. I think something's not right. Just for a moment.

Yes, I think there are Mhms. Yes. Mhm. Yes, now we can see, we will be able to see how the transaction is transmitted to Solana from Neon EVM. It might take a little while, guys, because the main network takes a little while, but oh well.

Yes, you can see the SOL approval wrapped up. So, this is a script where we are exchanging SOL wrapped for USDC in Orca and Raydium at the same time. Yes. Sometimes querying the Raydium pools takes a little while, so I can show you one more transaction while it's happening, so we have this while it's happening, so we have this . Yes.

So, this was a transaction that took place last night. Basically, it's a SOL- to-USDC swap on a Neon EVM. You can see that there are seven transactions. We have about seven transactions from Solana. So why is this divided?

Because Neon EVM transactions are sometimes large enough that they cannot fit into a single Solana transaction at a time. That's why the proxy divides the transaction into smaller transactions so that Solana can process them and thus perform the iterations. If you click on the last transaction, you can see that we had an interaction with the Neon EVM program and you can see the exchange happening on Raydium and also on Orca. In the last transaction, you will obtain all the aggregated data from all transactions. That's how it happens, yes.

Let's see if it's completed. No, I think Raydium is still taking a while. But oh well, it's fine. I think I can show you Jupiter's pretty quickly then. Yes.

Jupiter should process very quickly. Sometimes the data obtained from Raydium takes a long time to, you know, be processed. So, yes. With this script, this is a Jupiter exchange script. Here we are exchanging USDC and USDT.

I already have a transaction happening like this. This is another transaction that occurred 3 days ago on Jupiter from Neon EVM. It is a USDC to USDT exchange. It's the same thing. We have three Solana transactions, divided like one Neon transaction into three Solana transactions Neon transaction into three Solana transactions .

And the last transaction gives them details that it interacted with the Neon EVM program and the exchange occurred on Jupiter. Let's see if it's completed. I don't think so, because it's the main network, so it takes a little while, guys. Yes. Let's review our rewards for now.

Just so you know. Hm, yes, these are our rewards regarding composability. Yes. They can build anything around the composability function, such as some cross-chain DeFi aggregator or yield farming that they can deploy on Neon EVM and then access from Solana using the composability function. Anything they can do with it, and we also have a bounty on a developer toolkit or SDK libraries that make it easier for developers to access Solana.

So these are our two rewards for this hackathon. So yeah, check it out guys and I hope you build something good on Neon EVM. Yes, I do n't know why this mainnet isn't working, but yes, I think it did work, it did work. Yes. So I can show you something quickly.

Okay, yes show you something quickly. Okay, yes . Okay, thank you very much. Thank you so much. Yes.

Yes, of course. I didn't understand your question. Yes. No, I don't think we have that function because these functions are already in our precompilation, and I don't think we can get a state from Solana. We have another pre-compilation called read.

To read, yes.