How to Access Solana using Neon EVM - ETHGlobal Bangkok 2024

Hello everyone, my name is Daria and I'm a Developer Relations Engineer at Neon. Today, I will show you how you can connect to Solana using Neon. First let 's look at what Neon is, it is an Ethereum virtual machine located on Solana. What this means for you as a developer is that you can take your existing Solidity code and deploy it with us , and then interact with your project using your favorite Ethereum tools, especially the MetaMask wallet or any other EVM compatible wallet. Because we run on Solana , we combine the best of both worlds .

So we have all the benefits of Ethereum . Therefore you do n't need to change your code. You can use Vyper or Solidity . You can use all of the popular Ethereum tools like MetaMask, Hard Hat, Truffle, Remix . You can use the Ethereum RPC API for anything related to ZK, as well as Ethereum Account Signatures and token standards like ERC 721 or ERC20 .

Moreover, we also provide Solana benefits. Transactions on Neon are executed in parallel . We have low gas fees, high transaction speeds, access to the growing Solana system and liquidity , and use the Solana consensus mechanism without the need for any additional infrastructure or sequencer. Yes. We have been available on Solana since July 2023 , this is an overview of our tooling .

We have EVM, which is a proxy server that acts like an API. We have a Tracer API for debugging. We have Neon Pass to send tokens from Solana to Neon. For developers we have Neon Faucet and Neon DA, the owner of the Neon EVM program . Gas fees are very low and we achieve speeds of around 2,000 transactions per second .

And, this is a neon ecosystem. As you can see, we have all the standard EVM wallets available . MetaMask, Trust Wallet, Wallet Connect, we use the same RPC providers as Ethereum. P2P and Everstake, we have two explorers : Black Scout and Neon Scan; We support indexers like The Graph and Subsquid ; We have NFT tooling, bridges, multisigs, and most importantly, we support all the dev frameworks used by EVM developers . Hard hot, foundry.

There are also development platforms like ThirdWeb and the Remix IDE. This is specifically an overview of dev tooling. As you can see can see , we support all Ethereum-related tools, JavaScript libraries, Open Zeppelin standards, and more. This is an overview of neon architecture. First, the user interacts with Neon through the wallet.

It could be a Solana or EVM wallet. For example, MetaMask sends a transaction to a dev front end , and then this dev front end sends it to our proxy which acts like RPC . Then, RPC sends the Solana transaction to the Neon EVM program in Solana, where the bytecode is translated into Solana instructions and executed in Solana . This is the classic structure of the Solana program. You will notice that this is different than Ethereum.

It stores data in a different way . You will have separate accounts for your main account. There are also program-derived accounts and token accounts. So each of your tokens will have a separate account . Now let me show you how Neon uses this to support EVM .

This is a Neon EVM program in which we use the free space allocated in accounts to store some EVM information . Solana allows up to 10 megabytes of storage and Neon uses about two megabytes of that . This way we keep the EVM bytecode, Ether address, nonce, balance, and other related information in an account and use it to execute the transaction. This explains how a Neon transaction is built into the Solana transaction program. We have an accounts list, which we use to store a list of neon accounts.

We store the index of the Neon EVM program in the program index, and then store all the Ethereum transaction data such as nonce, gas price, gas limit in the data field . This is a diagram showing how parallel execution works on Neon and Solana. Because of the way Solana manages data and the way it separates accounts and programs, we can also perform parallel transactions in Solana . Also, this way we achieve speeds of up to 2,000 transactions per second . Another amazing feature is composability composability .

Composability is the ability to call Solana transactions through your Solidity code using the Neon EVM . Here is an example of how this works. You have your Neon EVM account, represented by your MetaMask or other wallet, and then you send an EVM transaction to call a Solana contract, which is an interface for pre-compiling inside the Neon EVM . So you call the execute function, you can think of it like a delegate call , where you pack your instructions, the function name, and the parameters you want to execute , which is passed to the pre-compiler inside the Neon EVM program, which is then passed to any Solana program that is marked as a destination in this execute function . And this is what I'm going to show you , it includes functions like Get Resource Address or Get Neon Address , which can retrieve relevant information from Solana, and mainly through the Execute function you can call a specific instruction in any program in Solana.

Now this is a picture showing how to transfer tokens from one account to another in Am Neon . In this case, we are transferring USDC coins using composability . So we have a Neon EVM account and we call Solana directly through the composability feature to send some tokens to the Solana account. you can see that we are preparing a Neon EVM transaction, where we identify the token program as the destination and want to call the transfer function , and we have inputs like destination, token source, and amount . This goes to the Solana pre-compiler inside the EVM program, then to the Solana Token program, which contains the USDC token program , and together these two handle the transfer from one token-affiliated account to another .

Um I also want to show you one of the composability transactions to show you one of the composability transactions . This is a transaction that sends some Solana from a Neon account to a Solana account using the composability feature. So we can go into our block explorer Neon scan and we see that one transaction on Neon is equivalent to one to two transactions on Solana. We can open it and see that it is actually doing the sending process . So this sent a SOL from the account owned by the Neon account to the destination account, all this was done using just the Solidity code and that's how it works.

You can use Hard Hat and Web3JS for this . You need to set up your transaction, get some information like the public key, for the sender 's account, the receiver's account, and then you can call the Solana instruction via web3js. And we have two tracks in this hackathon, and one of them focuses on the composability feature. So, from what I said , you'll be eligible for this if you call Solana through the Neon interface, and the other one focuses on Memecoin and Den Toolbox. So for this you don't need to interact with Solana directly through Neon, you can just deploy on it using the Neon EVM .

And finally we have some insight into how communication works from another EVML2 to Solana and from Neon EVM to Solana. For example, if you are bridging tokens from Ethereum or Polygon , you should use a bridge called de-bridge in this case . And if you are sending tokens from the Neon EVM to Solana, you can use our Neon Pass , which converts tokens from Solana to Neon, and when you send them back, it works the same way . Also, if you are building on Neon , you can join our developer resources . We also have GitHub where you can see all the examples of our code, which can be useful if you want to participate in one of our bounties in the hackathon useful if you want to participate in one of our bounties in the hackathon .

Thank you. Sorry, I was a little late , so I didn't see the contract for the Solana call. There's metadata there and as I recall, account meta is account information from Solana. Yes. Yes.

As a user on Neon, you interact with your EVM account , but the Neon program takes care of creating a Solana account for you . And when you use composability , you need to use a struct to pass some Solana account information , especially if you are sending any SPL or Sol tokens from an EVM account in Neon to another account in Solana. So this is what it's for. Okay. So, again I'm late but apparently you have an abstraction of paying for Solana gas using Neon, right, or do I need to have some Sol in my Solana account to pay for gas?

The Neon EVM is not L2 and each of your transactions is actually executed on Solana , so you pay gas in Neon, but the Neon EVM program handles the gas payment on Solana . You will pay for this mainly. In fact, the same thing happens when you deploy a contract in Solana, because that's how the account model and rental work there . It will cost you a little more , because we want you to pay two years of rent to keep your account permanent . You don't have to pay rent for this .

Okay, very good. Thank you.