Dawei (00:11) Alright, welcome to Degen Responsibly, Yuri. Glad to have you on.

Yury Yurchenko (00:14) Hello, nice to see you.

Dawei (00:15) Yeah, so I think this will be an interesting conversation today on Neon EVM. You guys are, to my understanding, essentially building an EVM layer on top of Solana. So I think this is pretty unique design that's not as talked about today, especially given how hotly debated Solana and Ethereum has been on crypto Twitter over the past year. So yeah, pretty excited to dive into this one.

Okay. before we, get started on it, can you give us like a quick overview of, what neon EVM is and, what made you interested in the project?

Yury Yurchenko (00:46) Yeah, I'd like to start from maybe the most simple explanation of Neon. In short words, in short term, Neon is a fast track for EVM developers to be on Solana. In more long term, it's like Neon EVM, it's Solana's network extension that allows to run EVM applications concurrently or in parallel on Solana, provides access for developers to Solana users. Technically, it's built like a smart contract on Solana.

Dawei (01:15) Okay, cool. So I guess the benefits of this is you're able to bring all the dApps that already exist on Ethereum today and the developers are easily able to bring them over to Solana without having to learn a whole new coding language.

Yury Yurchenko (01:16) written and rest.

Yeah, almost the same, just two points I'd like to mention here. Yes, Ethereum dApps can be migrated, deployed to Neon and have an access to Solana. But if application would like to interact more natively with Solana, what does that mean natively? Maybe discuss further. It means applications need to implement or utilize some features to be...

natively integrated to Solana, which means provide access to Solana users.

Dawei (01:59) Okay. And then when you say natively integrated, what does that mean exactly?

Yury Yurchenko (02:04) Let's consider two examples. For instance, if you'd like from Ethereum application to have an access to Solana apps, for instance, your Dex Aggregator, and you'd like to connect liquidity pools on Solana to your Dex Aggregator, it means you make some compatibility with Solana and you'd like to touch Solana liquidity in user base. Another example is, let's see.

From developer's perspective and user perspective, you'd like to allow Solana users to interact with your, I don't know, Uniswap fork or any other application to interact with Solana wallet without changing network, so some kind of app network abstraction. And this is second example of Solana native. So for apps being Solana native means like they have an access to liquidity user based on Solana.

And for end users means like without switching network interacting with all the apps on deployed on Neon EVM.

Dawei (03:05) Okay, got it.

Yury Yurchenko (03:09) This is... I called it Neon Native... Solana Native.

Dawei (03:11) Cool, cool. And then, on the topic of Solana versus Ethereum, they're two incompatible, blockchains. But like, what would you say are the key differences between the Ethereum EVM and the Solana SVM in terms of, how the blockchain is structured and how transactions are processed today?

Yury Yurchenko (03:33) I would say there are big difference in...

Transactions processing, especially Ethereum developers and Ethereum itself can process very big transactions. And Solidity developers, EVM developers used to use first of all big transactions, big in terms of compute units, a number of accounts, plus they no care about price of transaction and they'd like to combine a lot of actions into one transaction.

which means you execute in one transaction a lot of actions and lot of things within your application. Solana has very different architecture and principle. Solana transactions quite small in comparison with Ethereum transactions and designing Solana application, you have to take into account splitting your actions in application into smaller pieces or chunks.

and producing a lot of small transactions, you can achieve more throughput on Solana. This is the basic difference. What does it mean from the developer side? In Ethereum, you don't care about size of your transaction. In Solana, you should put your actions into a small chunk of compute units available for you from Solana.

Plus, Solana has a limited number of accounts that you can use in one transaction. Currently, it's 64 accounts. And you can use in one transaction only this number of accounts, not more. Which allows for Solana to process up to 5 ,000 transactions.

Dawei (05:21) When you're talking about these smaller compute units on Solana, is this related to the parallel processing side of Solana?

Yury Yurchenko (05:31) Yeah, exactly, exactly, because transactions are so long executed in concurrent space in parallel, which means the smaller transaction, the lower chance the transaction will intersect and be reverted.

Dawei (05:42) Okay, and in comparison for Ethereum, everything is sequential, right? Like all transactions have to happen one after another.

Yury Yurchenko (05:47) So yeah, it's a bit...

Yeah, it doesn't make any sense for Ethereum. Just smaller your transaction. Try to concurrent with other transactions.

Dawei (06:02) To paint the analogy here, would you say Ethereum is a highway with one lane and then Solana is a highway with multiple lanes?

Yury Yurchenko (06:11) You

I would compare Ethereum itself, not like highway but a small road with one lane and Solana a lot of parallel highways.

Dawei (06:16) Okay.

Okay, makes sense. there's also the topic about, blockchain modularity, modular blockchains versus monolithic blockchains. Ethereum and Solana have really kind of diverged on these, on these roadmaps for how they believe blockchains should be scaled in the future, right?

Yury Yurchenko (06:23) transactions per second, SSR.

Dawei (06:38) Ethereum is going more of the modular approach where they're scaling through layer twos, they're letting these other L2s take the load of the execution processing and scaling this way while Solana is trying to do it all on the base layer chain. In terms of how that relates to Neon EVM, why build

Why not just build on another layer 2 versus build this EVM on top of Solana itself?

Yury Yurchenko (07:01) Very good consideration, very good question. Let's say, here are two different approaches you mentioned. First of all, like if you're stuck with performance or if you have scalability issue on Ethereum, you can launch your own rollup and scale Ethereum. This is the third approach and I guess everyone knows drawback of this approach. You have liquidity fragmentation plus like user -based cannibalization.

The second approach and I would say this is the only approach for Ethereum to scale nowadays because you can't scale Ethereum itself in short or middle term time period. The second or additional, let's say second approach to have monolithic but very fast performing blockchain. And on one hand you...

can't, let's say, replace any of layer, but on the other hand, you have a lot of computational resources or a lot of transactions per second, in simple words. Especially for Solana, why Solana more stick to monolithic approach instead of modularity, more or less due to Solana plans to have one million transactions.

in near future with their fire dancer. And why Neo decided to launch on Solana and not to launch our own rollup? Let's say we believe in Solana and we believe that Solana can produce this one million transactions per second in the near future. Having the same liquidity and the same user base without any cannibalization, fragmentation.

So we believe in more in this future.

how it looks like on the Ethereum. I guess we can open some kind of L2 bits or something like this and see 200 EVMs on the horizon. Growing like a mushroom of terrain, more and more.

Dawei (09:03) Ha

Yeah, you're talking about, yeah.

Yury Yurchenko (09:12) From any user perspective, especially from Web2 or Generation Z perspective, it looks like hell. You don't understand what to use and why.

Dawei (09:18) Yeah, so you're saying mainly from the user experience perspective, the Ethereum roadmap is more, it causes too much fragmentation of liquidity across the hundreds of rollups that are constantly coming out today.

Yury Yurchenko (09:31) Exactly, exactly.

And the Twitter battle you mentioned before, was named for these rollups, like parasitic rollups or something like this.

Dawei (09:38) Yes, so I think that's what Anatoly said, right? Like L2s are parasitic to the base layer because they're extracting all the users and they're getting most of the benefits without paying. They're just paying small DA fees to Ethereum at this point.

Yury Yurchenko (09:44) Yeah, exactly.

Exactly. And cannibalizing the same user base and liquidity.

Dawei (09:53) Okay. But yeah, I guess I'll be curious what are your thoughts on the long term future of Ethereum with this roll up centric roadmap.

Yury Yurchenko (10:02) Yeah, it's very hard to speculate anything here. My own perception, I would say there should only remain several roll -ups in the future that have found the niche with proven end user and real use case or with let's say market fits. So I'm expecting more or less not 100 but maybe 10s.

20 rollups who have found their niche. Plus I see Solana as a big player here, strong competitor. All these rollups, why? Because potentially with 1 million TPS, Solana might cover the whole computational demand.

in Blockspace.

Dawei (10:53) I think this also leads into another recently debated topic on crypto Twitter is we've been hearing this new terminology coming from the Solana side about network extensions. Can you talk a little bit about what network extensions are? Because to me, sound like, it just sounds like essentially it's a layer two on Solana. Is that the right way to think about it or is there more nuances there?

Yury Yurchenko (11:18) It sounds like it's a different topic and different concept and good topic to discuss. Coming back to rollups, you have besides of scaling issue, there is another reason to run your own rollup. Let's say you'd like to customize classical EVM. You'd like to have, I don't know, different block production time, guaranteed settlement time or add private transactions.

or any new features. One way, if you do a separate roll -up for them, that, modify EVM and launch your own roll -up with modified version of EVM. But again, you will face the same issue with liquidity fragmentation or user -based fragmentation. Another approach, means network extension. What you can do, can add some unique features to blockchain.

for instance, for Solana and didn't change basic layers of this original network. Let's say from original network, you have execution settlement consensus data availability. And just to simplify example with Solana, you have all these layers combined and you'd like to extend execution layer because you have on execution side only SVM compatibility.

you'd like to extend this execution layer to EVM compatibility. You add something, a new module that extends to EVM execution, which means still you utilize consensus, data availability, settlement, execution, SVM execution, but extends to EVM execution too. Generally speaking, network extensions like specialized module or lega that once...

once connected natively, broaden the cork's capabilities of this blockchain, like execution, settlement or consensus.

For instance, Neon EVM. It was a general perception of Neon EVM, like we are L2 on Solana or sometimes someone joking like L1 .2, 1 .5, but no. As a Neon EVM, we have consensus of Solana, settlement on Solana, data availability on Solana, and only we extends the same execution to EVM compatibility, which means we are a network extension.

Another example, for instance, you have basic SPL token, which provides you ability to launch NFT on Solana, but you have MetaPlex on Solana, which extends Solana NFT capabilities. So you can consider MetaPlex as network extension tool. So generally speaking, we can define network extension on basic, based on simple criteria. Don't fragment.

basic network liquidity and user base, add some specific features and don't compete with basic blockchain functionalities such as settlement, data availability and consensus.

Dawei (14:16) When you say don't fragment liquidity, that for these network extensions you're saying you don't have to bridge your funds to outside of the Solana base layer?

Yury Yurchenko (14:20) Is that clear?

It means you don't run your own separated blockchain and you execute within the main blockchain and you have liquidity of main blockchain.

Dawei (14:35) I see. OK.

Yury Yurchenko (14:38) It extends, yeah, extends SVM execution to EVM compatibility, which means all transactions executed inside of Solana, we utilize in Solana liquidity, Solana user base. We are not creating another one. Roll up for Solana.

Dawei (14:40) Yeah, okay.

I see. So how exactly have you guys implemented this EVM layer on Solana? What's actually happening under the hood

Yury Yurchenko (15:04) I will try to explain quite technically but...

if something needs to be clarified, just let me know. so EVM under the hood, it's a smart contract written in Rust. And you can consider it like a native Solana application. Container. Native Solana application in terms from the perspective of Solana and container for a EVM applications in terms of EVM builders. And when you're running EVM applications instead of.

Inside of NeonEVM, it executes Rust code or executes SVM inside. Which means at the same time of launching EVM bytecode, it executes inside of SVM virtual machine.

In terms of programming languages, it's called interpretation.

Dawei (15:49) Okay. are you able to like kind of go through like a, maybe say a transaction, how that would flow from the neon EVM to the Solana, a base layer, like what's happening in the steps?

Yury Yurchenko (16:03) Mm yeah.

question, it might bring the light on the neon EVM magic. Right, you have Ethereum transaction.

Solana for sure doesn't understand Ethereum format of transaction. We have our RPC API, Neon RPC API, which provides by one of the components of Neon called Neon Proxy. Ethereum transaction comes to Neon RPC API, Neon Proxy. Then Proxy just wraps these Ethereum transactions into Solana container or Solana envelope and send to Solana.

Solana sees like a Solana transaction, process it and pass this Solana transactions to Neon EVM application on Solana or Neon EVM smart contract. Neon EVM smart contract unwrap it from Solana transaction and execute EVM bytecode inside of this transaction.

Dawei (16:58) I see.

Yury Yurchenko (16:59) and how Ethereum transactions are executed on Solana.

Dawei (17:01) Okay.

Yury Yurchenko (17:03) And all storage, all change in state, persist in solana.

Dawei (17:08) Okay.

Yury Yurchenko (17:09) So as soon as transaction executed, it's stored inside of Solana.

Dawei (17:10) Okay, gotcha.

And so with this current architecture, Neon EVM fully decentralized at this point? Are there security limitations that you still have to account for at this stage?

Yury Yurchenko (17:19) Basically, it's decentralized in the same way like Solana decentralized because consensus layer is Solana layer. The only thing is proxy, like entry point. For sure, you can write your own proxy or launch your own proxy, but currently it's a -listed number of proxies that can be launched, wide -listed, and we have currently two proxies here.

But we have plans to just remove this white list.

and allow everyone to launch proxy.

Dawei (17:50) When you say

Yury Yurchenko (17:51) It means it's something that receives Ethereum transaction and wrap it into Solana transaction and send to Solana. Something that provides Ethereum API to Ethereum applications.

Dawei (17:52) Okay. Okay.

I see. OK. So

Yury Yurchenko (18:03) yeah, only whitelisted proxy can do that. But yeah, we have a plans to remove this whitelisting. And this whitelisting mostly came from like previous model for parallel execution. We had to do it in previous, but currently as we switched to another parallel execution model, we can in near future just get rid of this whitelisting.

Dawei (18:23) OK. It'd be interesting to see if you have any protocols you can talk about, like what's currently being built on the Neon EVM today.

Yury Yurchenko (18:36) Let's say currently we have mostly all basic types of DeFi primitives like forks of Univi 2, Univi 3, forks of Aave, Compound, some yield generating protocols plus also we stepped into gaming plus NFT space and we have several games and NFT marketplace.

Dawei (18:58) Okay. Nice.

Yeah, sounds like you have the whole suite there basically. I'd be curious to know what types of protocols do you imagine would be the biggest users of Neon EVM? Would it be DeFi or is it more like gaming, like you said, something that needs that quick scalability and cheap transactions?

Yury Yurchenko (19:01) currently this

I would say both of them, current deployment of all the apps or protocols, they currently launched, let's say in Neon EVM and utilize only common liquidity of Solana. what we're trying to do, we're trying to all exist as well as for all existing protocols plus all newcomers to...

discuss with them more deep integration with Solana, which means like for dex aggregators to have access to Solana liquidity pools or for Solana users to interact with forks of Uniswap or forks of Curve. We'd like to step deeper into more native Solana interaction. It's like our, let's say next strategy.

Dawei (20:08) if a user wanted to use, one of these protocols on neon EVM today, could you walk through like how they would be able to get their, their assets onto that protocol? Like what would be the process there?

Yury Yurchenko (20:20) I'd like to split into two segments or two audiences. Let's say you're a Solana user, you'd like to step into Neon EVM and interact with EVM applications. As of now, you need to transfer your liquidity inside of Neon EVM, which means transfer from one Solana account to another Solana account, technically. It's not a bridge and not a lock -in minting. It's just transferring from one account to another account.

Dawei (20:44) Is is that all happening within the phantom wallet?

Yury Yurchenko (20:50) Good question. Currently you have to transfer from Phantom wallet to Solana account and then switch your network and use MetaMask or another EVM wallet. But what we are trying to do, we are trying to get rid of this switching and transferring to use your Solana assets without switching network. Still, currently, currently you're using Solana assets. If you have Solana USDC...

Dawei (20:56) Okay.

Yury Yurchenko (21:15) you transfer it to Neon and use Solana USDC. It's not a replica, not a wrapped token. It's Solana USDC. But you have to switch your network right now. But we are trying to get rid of this additional step to simplify user experience. If you're EVM user, another one segment, you can bring your liquidity with mostly the bridge directly to Neon. It's a bridge.

Dawei (21:28) Yeah, for sure. Yeah.

Yury Yurchenko (21:41) It has no wrap and mint algorithm. has like you sell something on Ethereum side or L2 side and then you get native token on

In this case, you need to switch network. You are using the same wallet, but you have to switch your network and transfer your liquidity to Neon and interact with Neon.

Dawei (21:59) Okay, got it.

Yury Yurchenko (22:04) And yeah, I forgot about the third path. If you're a CEX user, have tokens on centralized exchange, you can withdraw it to just buy on CEX, withdraw to NEON or to Solana and then to NEON. Depends on the centralized exchange.

Dawei (22:15) Okay. I did have another few topics I wanted to get into.

So I think you guys are, the first ones to come out with this parallelized EVM layer, but there are a few others also working on this in the ecosystem, specifically Monad and Sei. I'd be curious to hear what your thoughts are on the differences between what you're building

And are there any major differences on architectural side as well?

Yury Yurchenko (22:48) I would say there more differences. I'm not so deep at tech level and I mostly would like to business or growth considerations here. First of all, all parallelization on Neon EVM and benefits from it come from Solana parallelization. And Solana already battle tested, already in main net plus in fact...

As we in mainnet with Solana, we are the first parallelized EVM. And we are battle tested with parallelization. So we've been running for more than one year now. So it's the first parallelized EVM in mainnet, battle tested for parallelization. It's the first thing. Second, it's liquidity. For more not saying similar networks, they have to grow their liquidity user base ecosystem from the scratch. Solana did it already.

Solana has very good position here. Third consideration, it's related to Solana plans to grow up to 1 million transactions per second with Fire Dancer. And I would say it won't be unbeatable by any blockchain.

Dawei (24:02) Yeah, so I guess you're saying the main thing is Neon is already leveraging the existing validator set of Solana, which is already battle tested and has billions of dollars there versus say Monad and say they have to get their own validator set and incentivize them through their tokens.

Yury Yurchenko (24:11) benefits of Solana.

Exactly.

Exactly. And incentivize validators and incentivize users and build everything from scratch. Plus potential plans to grow up to 1 million transactions. It's incredible.

Dawei (24:30) Yeah, I think there was a recent test shown at the Solana Breakpoint conference, right, with the Frankendancer showing 1 million transactions per second.

Yury Yurchenko (24:45) you heard about it.

Dawei (24:45) Yeah, it was I think a pretty hot pretty cool. there's also topics about another hot narrative this year has been BTCFi or Bitcoin DeFi. that's essentially bringing

EVM compatibility to Bitcoin itself, which is also, natively not compatible to these kind of smart contracts. I'm curious what are your thoughts there and like is Neon EVM looking to do anything related to the Bitcoin side?

Yury Yurchenko (25:16) Okay. Let's say some context here. We have two products in our product line. First of all, it's Neon EVM itself. It's EVM compatibility layer or network extension on Solana. It's the first product and we are trying to growth Neon EVM on Solana. Second product, it's more or less technical stuff. It's Neon EVM stack, which means it's EVM compatibility layer.

that can be installed on any SVM based rollups. For instance, have said Yona network, it's SVM based rollups with settlement on Bitcoin. Another example is Eclipse SVM based rollup with settlement layer on Ethereum. And for this product line, we use Neon just providing technical stack for every SVM.

builder who'd like to have this evm compatibility to just launch the SVM based rollup and provide not only access for SVM builders but for evm too. And here it's potentially, yeah, it might help such SVM rollup builders like Yona to compete in this battle for Bitcoin and evm compatibility on Bitcoin, but it's mostly up to these SVM builders, the only I would say like, still it's my perception like SVM Solana and SVM technology, it's the most technically superior technology for blockchain nowadays. And Yona can compete using this SVM plus having a EVM compatibility in the face of.

Dawei (26:54) Okay,

Exponential DeFi AI (26:56) Well, I think that's a good place to wrap it up.

Thanks for the chat, Yuri.

Yury Yurchenko (26:59) Yeah, thank you for interview. Pleasure speaking with you.