Solana Native, Ethereum Familiar: Building Without Barriers

Transcript

[Music] All right. Hi everybody. How's it going? Hope you're having a great time here in KN. My name is Florian and I'm a head of product at Neon, the Ethereum virtual machine running on Solena. So at Neon, we're working on different products, but since the beginning of our journey, we always had one foot on the EVM world and one foot on Solena. And since there's still a bit of tribalism in web 3, some of you might be asking, hey, why is this son guy speaking at the biggest ethereum conference in Europe? I mean, I would get the point, but um this would also confirm the point that I came here to make, which is that we've been building too many wall gardens over the years, and we kind of force our builders

and and developers to pick side. We do have uh if you're many VM chains on one hand, Solana on the on the other hand, tens of layers one and two everywhere. And despite the progress we've made with uh cross trainin protocols, we're still uh pretty far from the target and many chains still feel like uh fragmented islands. So today I came to speak about how we can break that uh how we did break that neon on a very specific case and more specifically how we can allow developers to build without borders and so that they can on board users without friction.

But let's start with the uh let's start with the the builders. If I ask any web free developer in the room, what is stopping you from deploying application across different ecosystems? Well, it's not the ambition. It's not the lack of time or resources. It might be the lack of product market fit because we all looking for it in the space. But it's mostly the stack you um like many chains still today operate like their own operating systems with uh their own languages, their own uh security models, their own uh mental overhead. And you could tell it's actually the same in web two where uh

you can develop an application in different languages hosted in um different cloud providers like uh AWS uh Asia etc. But in reality it's completely different. Why? because everything is in web 2 is still very much interoperable with uh the HTTP protocol for instance and everything is standardized with the different uh runtimes in in web 3. Unfortunately, we're still a bit far from the target.

Um we do have chains that operate again with their own dialects, with their own uh smart contract conventions, their own languages, their own uh wallet compatibilities uh etc. So um how can we break that? Well, we we did work on neon on on on that side and basically so if the slide is a is able to move. All right. So let me give you a very concrete example.

If there is any EVM developer in the room uh that has been interested in deploying on Solana, well I'm pretty sure this slide is very familiar to you unfortunately. Uh too complex uh not worth the rewrite. I will stick with what works. Those aren't just random Twitter quotes. They are uh the reality for many EVM developers. And why? because well Solena has completely different architecture uh uh compared to what we know in the EVM world. Stateless smart contracts uh different tools different security model uh you have to learn Rust and from an EVM perspective this feels very different.

So how can we break that and how we did break that at Neon? Um well that's the challenge we have to face and specifically how we uh to allow EVM apps to on board Solena with like breaking these uh uh uh borders. For that we created a protocol Neon EVM and uh basically this EVM protocol allows any EVM application to be on boarded on Solana via Neon without having to change 99% of your codebase.

So you have to uh uh simply use your uh day-to-day tool. we uh abstract the complexity and uh you can easily create your application. So for EVM developers, you don't have to uh learn about Rust again. You don't have to understand how the Solana parallel runtime works or the rent system or the account model. No, you simply come as you would do in in Solana, sorry, in in the EVM world. Um you write your contract in Solidity or Viper. you just deploy your contract with uh your daily stack like Foundry, hard hat, etc. And uh here we go. Right.

So uh that's for the EVM development part. But at the same time, we wanted to make sure that the user experience is is uh not compromised. Why? Because as an EVM application, you basically want to get in touch with a new user base or a new audience which is in that case the Solana audience and for that you want to interact with the audience natively. You don't want some kind of middleman in the middle like uh having or forcing those users to use a different RPC a diff or bridge their assets or use a different token. No. So to be fair when we launched like couple

of uh like a year ago we did this wrong. We early on we we uh worked some kind like maybe like a nail user experience and after a couple of iterations we also came back with this idea of creating a native experience where any EVM application can integrate native Solana wallets. What happens is that uh Solana wallets or Sona users sorry are able to sign EVM transactions directly with their Solana wallet and use Soul as the gas token in that case.

So we kind of break uh uh those barriers at the ecosystem and and and uh user experience level. So how does this work? because we're in a developer session and we speak a bit about the technical aspect. Neon is not an L uh an L2. It's not a side chain. It's a smart contract and uh it's a smart contract running on Solana. So like any other smart contract you could uh interact with or write in the Solana blockchain, but it has a very specific role. It's an interpreter which is able to execute EVM byte codes inside uh Solena.

In other terms, your EVM byte code is executed inside the neon smart contract and this smart contract is executed inside the Solana virtual machine like any other smart contract you could have in Solena. And because of that level of compatibility, it unlocks a couple of few critical things. The first thing is that the the persistent data what we call the state on the Ethereum on the Ethereum is um hosted or stored into Solana accounts and those Solana accounts are controlled by the Neon smart contract on Solana.

Additionally and again because it's compatible the uh uh we we unlock access to the sonar sys call and to make it simple we unlock parallelization of transaction even for EVM transactions. So let's uh go one step forward and focus on let's say the core of the neon EVM architecture which is the proxy. Let's say you have your application with um uh you know users connecting their Phantom or Solana wallet or EVM wallet executing a transaction. These transaction goes uh to our neon proxy and before it even touches the the

Solana network, it does a couple of critical things. First of course it accepts the EVM style transactions and it then simulates a few things like uh what accounts on Solana will be used. It will calculate the compute budget. It will package everything into a valid Solana transaction before sending it uh to the Neon smart contract on the Solana blockchain so it can be executed natively. Additionally, what was important as I mentioned the uh idea was to uh simplify and remove the complexity for developers because again there's a

huge difference between the two models and for that uh we thought that it was very important also to add libraries which is or to facilitate the developer experience. how uh well we created these libraries where we remove all the complexities as I mentioned for EVM devs so that they can feel like uh using any other EVM chain and they don't have to understand necessarily all the complexities. So uh with these libraries you can handle uh uh solenar errors but with EVM style. uh you can uh format Sana instructions like you would do or uh yeah uh handle the rent management

accounts etc etc. But um the most important part is you know besides the technical aspect of it well why is it useful and what use cases can we build and that's where you know after a couple of iterations and test well we uh we're currently working with different protocols and we tested a few things we have for instance dexes uh where we unlock a brand new uh uh set or well audience and set off liquidity for dexes where uh any EVM deex can connect

native Solana wallets and basically get in touch with the Solana um audience. So they can sign EVM transactions or do swaps uh uh without having to bridge to from Solana to any other EVM chain. So it facilitates the on boarding of the whole new crowd the DJ crowd also of Solena to be to to be familiar with it uh and and creates a lot of volume also on the on the deck side. Another interesting case uh for lending protocols while accessing new pools of liquidity from the EVM world is something that is uh super interesting.

we have this uh uh again composability feature where any VM application built on neon uh can easily access and interact with other Solana applications. So if you're an EVM lending protocol and you want to unlock a new uh liquidity or unlock the solan liquidity, you simply uh call it from your EVM application and offer you're able to offer uh new yield sources to uh uh your users on the EVM side without having to rebuild entirely uh your application or uh uh you know having to understand the complexity on

that side. Last point, um a token launchpad. So, we've seen a lot of uh launchpads starting recently and trying to uh compete with each others. Um the particularity in that case is if you're an EVM existing launchpad, you're able to launch SPL tokens with from the EVM application. So any uh launchpad on the VM side can have hits its own users launching new tokens also on Sonas side. So we definitely broke the borders between those two ecosystems. Uh and we facilitate well the user experience and the

liquidity flowing between the two. I think I'm uh getting uh at the end of this presentation uh a bit ahead of time but if you have any question uh feel free to ask and I will be happy to answer. Thank you. Yep. Okay. See, thank you. I was curious uh if you have your own EVM uh it means you it comes with an overhead in terms of processing time or gas cost. Can you uh give us

some metrics about it? Yeah. So uh we so of course we have to uh deal with the performance and right now with the latest changes we've done on the EVM side we are slightly above the Solana native performance but in like milliseconds above. So it depends of course what kind of logic uh you want to execute because transfers are the simplest logic and we're very extremely fast like Sena. If you have uh heavier logic like because EVM transactions are way bigger than solan transaction we have to split this logic into multiple transaction and uh these processing time takes a bit more time than a native

Solana transaction but we're still able to compete and in terms of cost uh which is the second part of your question there like the gas systems between the two models are completely different. you have to handle priority fees for lending the transaction in Solana. So this adds um uh a bit of over cost but again the goal for us is to be very uh performing and if you compare the cost of an EVM transaction the price of it versus uh the EVM on Solana you're faster and cheaper uh regarding those two aspects.

Yeah. Okay. Thank you. Thank you for the question. Okay, thank you for the presentation. Do you know any uh team which works uh on the product for trading or whatever um real world solution which you can talk about? Real world solution. Uh real world. Yeah. Ah real world solution. Yeah. I mean we had you know uh many EVM uh applications dexes uh um lending protocols NFT platform etc that are already on as part of the ecosystem but we you know there were there were still

using the old or let's say the v1 of our product and as I mentioned in the presentation the user experience was not good. we were kind of like having this L2 user experience. I'm not criticizing L2s etc. but we know uh uh the user experience is the the biggest pain point. So since we on boarded uh native SA wallets which breaks basically this middleman feeling uh we're now trying to on board much more applications and we're in talk with uh top tier protocols uh to basically work on this integration. At the same time um we are you know having so this this new feature has been launched in

March and we're now also uh uh you know doing a lot of hackathons and and boot camps etc just to increase the number of vacations in the pipeline but we do have some and hopefully in the next two months three months you will you will see uh big announcements. Thank you. Yeah. Thank you for the questions. Okay. I just would like to know um when you say you're sort of translating the code is that done by hand automatic is there a scheme for it that does it automatic with AI or or how does that work? Uh so the complexity is uh so there are two two key pieces uh in in the architecture

maybe I can show it here in the image you can see the neon proxy and on the on the middle of the the scheme or the diagram here and you can see the neon EVM program on the right side here. Those two pieces are very um critical to the ar in the architecture. Why? Because on one hand you have an EVM transaction coming to the proxy and here is where the magic happens where you know uh we split the transaction into x uh uh smaller transactions. We wrap we we basically translate them into a Solana transaction and then we send those transaction in uh the neon EVM program here which is able

to understand the EVM what we call bite code in that case and from there it reconstruct the the translate the uh um transaction and then execute it directly on chain. So there is no AI etc. is just pure um bite code compatibility in that case and a lot of mechanism to make sure the transactions are not dropping or failing in the middle. Why? Because again the the compute logic of the EV or the size of a EVM transaction is 30 times bigger than a son transaction.

So we have to split those heavy transactions into uh lighter transaction and still be very fast. And that's the challenge. Okay. Thank you for the answer. Yeah. Do we have any more questions? Okay. Seems no more questions. There's one there. Let's see. So my question is about the token price. Did already TM sold all their tokens or still not uh token price? Yeah, I'm woring about token price and I'm woring about how TM is selling tokens. Uh yeah, so a couple of things. So from a legal

standpoint, I'm not supposed to be speaking about about token prices, but to not influence the price or whatever, but I can answer your question. um the token is used for gas fees in in if you're using EVM wallets in our case for Solana wallets it's not for that then you have the governance aspect of course but I mean the there are also new uh uh token usage that are in the pipeline and hopefully uh once everything the token economics are ready etc the usage will be increased but besides that it's all about in the end uh usage and onboarding new applications so that they can uh

attract more users and the more users we have the more natural flow will happen uh for sure but yeah I agree with you uh token economics in that stage are not toconomics it's very important much price of token you have you your team is selling so developers gain more salary more developers probably I hope yeah I mean it's the point for everyone like the more the more you can on board applications and users the more supposedly there's a direct connection with your the token price for sure. Yeah. Thank you for the speaker. Thank you.

[Applause] [Music]