Modular March EP 16: Where Eclipse & SVM Fit in The Modular Thesis

Transcript

welcome to modular March I'm handy this is Robbie and we are the rollup modular March is an educational experience about all things Moder [Music] enjoy [Music] [Applause] [Music] welcome back to another episode of maju

March we have Sydney from Eclipse presenting ethereum's first svm L2 Sydney welcome thanks for having me looking forward to this and uh this is one of the more interesting presentations because salana is involved in modular March so I love it I'm excited Hot Topics right now for sure um I guess I'll start off with a quick intro of myself so I'm Sydney I'm the product manager at Eclipse been at eclipse for a little over a year now um and maybe I'll start off with a little bit of background of how we even got to eclipse in this architecture um before we before we dive deep into it so Eclipse uh actually

started as a Ras provider so RPS is a service and at one point we were running dozens of chains ourselves um all these apps specific rollups and from there we just realize that there is something fundamentally flawed on this you know thousand rollup thesis because one core issue is first of all I think most apps are not going to reach the transaction threshold to make it economical for them to run their own rollup right and then number two the main issue is there's a lot of user experience um like fragmentation when it comes to every single app being it own rollup eventually maybe we'll get to a world where we'll have less interop issues but as it stands right now it just makes for a terrible user experience so that's

kind of when we started thinking more about this um rooll abcentric road map and how we can actually really scale ethereum right we actually think that um with something like svm which is highly scalable with a lot of throughput you actually don't need all these um you don't actually need all these different rollups that are fragmenting the state essentially and what I mean by that is the the rollup Centric road map Theses of having thousands of rollups built on top of ethereum really is kind of a byproduct of the single-threaded evm the single threaded evm can't handle as much throughput therefore you need multiple chains in order to really scale ethereum but the beautiful thing about

the you know modular thesis is you don't have to use the evm on top of ethereum you can use any execution environment you can use use whichever da layer you would like um so because of that we really started to design this this um architecture from from first principles so e clipse mayet is a general purpose L2 and we kind of combined the best pieces of the modular stack so like I said we are using the salon virtual machine um purely because you know it's been the most battle tested production ready parallel VM out there we've already seen um the capabilities of it on Solana L1 we're leveraging the security properties from ethereum so our canonical bridge is on

ethereum which means that this validating Bridge determines the fork Trace rule of eclipse um we're leveraging eth as the gas token now obiously eth itself has a lot of liquidity and network effects um for our da layer we are using Celestia mainly because of the verifiability properties as well as the bandwidth and for our fraud proofs we're actually leveraging with zero okay so why do we pick the svm so I think for for this presentation today I'll mainly be focusing on the svm and eth because those two are probably the most core to our infrastructure um and there's a couple reasons why we picked

the svm so the first and most obvious one being performance right the svm is designed to enable parallelism across transactions um other VMS have been single-threaded we've also seen some other parallel VMS but they just haven't been as tested and proven as the svm so far security is another big reason why we pick the svm the svm can easily protect against bugs uh compared to like solidity um for example like the Dow hacks or some of the most like famous hacks on ethereum has been this thing called re-entrancy attacks and the spvm doesn't allow for re-entrancy attacks because you can only you know self for curse um another big reason is ease of ease of use so that's one consideration we had that we kind of went back and

forth on like obviously solidity is easier to code in for a developer but the thing is solidity does not compile to all B codes right and Russ actually even if you take a step back from web 3 it's one of the most popular languages globally so there's a a really robust developer Community there um provability was a big reason so because the SPM is register based it's actually easier to ZK prove than something like a stack based VM so of course more optimized VMS such as um like Cairo or you know fuel which is like completely utxo based but regardless the svm is a little bit easier to prove than than something like the

evm um and the last and one of the most important reasons is really the community so popular blockchains like eth and salana ethereum and salana they've had they've done a great job at fostering a developer Community around those ecosystems um and that translates to better developer tooling and support compared to some of the newer virtual machines maybe such as fuel is is the um is is the performance from the svm responsible for solely the speed of of the transactions and then using like a modular da like Celestia that lowers the costs so you get both the like the high speeds and and the low

costs is that kind of the thought process so so I think eventually we will evaluating moving to e da um we've already seen some improvements with 4844 but even with 4844 I don't think it has enough like throughput capabilities to handle kind of the numbers that we want to hit and Celestia will allow us to to do that right they don't have execution they're purely da layer um so yeah so from a cost basis because we're using Celestia the transaction fees will be comparable to transaction fees on salana and also it will allow us to hit like the throughput that we want to hit yeah and maybe I'm thinking about this in in the wrong way but isn't like uh costs of transactions on chain and speed

almost like the same like the same idea where if it costs a lot it's because the the chain is congested or that there's a lot of demand so it's gonna you either pay more or you uh wait in line but so they're separate like things but but ultimately they kind of converge on the same on the same end state or the ideal end State um so I think with the the fee stuff I think that's more around like the fee markets how like um the salon fee market and ethereum fee markets differ in design right I think ethereum with 1559 I think there's um it's a lot more incentive compatible in many ways whereas the salon of fee markets are somewhat broken right even if you put in

a priority fee on salana it's non-deterministic and doesn't guarantee that you know just because you put in a higher priority fee that your transaction is going to land before someone else so I think that's somewhat separate in that you can design the transaction fee mechanism to make sure you know certain things happen like they're supposed to okay um I guess just quickly breaking down kind of the benefits of parallel execution I feel like parallel execution has kind of been a buzzword lately um but in at its core basically just means that multiple transactions can run simultaneously as opposed to one transaction at a time and really any VM could theoretically be paralyzed right

like we've seen parallel evm um that's becoming like a like a Hot Topic and everything like that um but the difference is that the svm is built from the ground up for parallelism so the salon a wire format actually specifies which state will be read or written while executing in the runtime um another big thing actually is is like State growth the SPM doesn't really have issues around State growth growth management whereas for evm that's definitely a a bottleneck before they even hit like the execution bottleneck and that's why even if you hear some the other protocols doing parallel evm I think a lot of the focus will be around this the state growth aspect um but yeah like I said the svm has been battle tested you know Sana has

been around for years and it's really been um we've kind of seen the performance of that and of course it has a robust Community around that already around the svm so this actually trans reles to a couple things when it comes to user experience so of course like fast and cheap transactions that's a huge one um fee spikes for a single app Don't impact the rest of the chain so this one isn't super black and white but I think salana has done a better job at like an approximation of a local fee market so it's not a true local fee Market where you know one con you know congestion on one part of the chain doesn't affect another but it's much easier to have an a true local fee Market when you have um a parallel VM as opposed to single threaded one so yeah

and obviously the best example of the fee spikes thing is um like the Yuga mint right that basically impossible to use ethereum a couple years ago and even recently with 444 I think a lot of the l2s have been um have been like have have had like sub one cent fees which is amazing but even I think yesterday or the day before there was I think $5 transaction fees on base because it was just like this execution bottleneck right so you're still seeing fee spikes um on the entire chain and the last one is the reduced attack surface area so it's a little bit safer with the SPM gotcha does the SPM use optimistic parallel execution or

deterministic um it's so so the optim so it doesn't just C so it doesn't just um execute and then if it fails it calculates again I think there are a lot of issues with like fail transactions on salon but it's a little bit different than than trying to paralyze the evm gotcha from what I understand yeah the optimistic is a bit easier I think for developers to understand but perhaps less uh less um kind of as you described less sturdy in a way deterministic is a bit harder but it offers a better solution so uh I don't know yep exactly yeah I really want to see how kind of the whole optimistic parallel evm execution actually looks like in practice um so well that's like say

right um yes although I don't know if they've I know it supposed to be V2 I don't know if they've launched soon soon integrated chains soon I'm just messing that's what everyone say yeah I got a question about um the state bloat and the state frag State fragmentation which is that in this post 4844 World we've got uh we've got these this IDE a of like ephemeral data availability where like this the data doesn't persist on the Chain it doesn't live on the Chain indefinitely like the data is available um basically just to make sure that it that it's correct and

it's valid and there's no fraud and then it kind of the data just kind of like disappears it kind of dies so is that helping this state bloat thing or is there a is there a difference between like the state bloat of like current addresses that are on the Chain unique wallets with their own balance or is this state bloat thing and this data uh is it a data blo PL problem or is there like a different state that is not concerned with data that is the issue with the evm so yeah so on this like State growth like management thing um I think there's been a lot of research into how to stop it on the evm right and like for for

those who I guess aren't familiar um it's basically if you have you know if you're spinning up like a full node you have to get information from the entire chain from the the the entire history right so since the since the day it started you kind of have to start syncing the entire chain and that's a big issue especially when you have like low Hardware requirements like you just aren't able to to catch up to whatever the the current state is and so with this whole um like so for salana it's a bit different because of the higher Hardware requirements so as you know you benefit from more cores and state grow just really isn't as much of an issue whereas the evm the lower Hardware requirements it's going to run into that bottleneck much quicker and I know there's been like some talks about um

maybe like having paying like State rent or something like that um where because it gets really expensive right to keep to be every single time you have to sync the entire history of the chain um so maybe you have to pay some additional fee to make sure that it always persits on the Chain um yeah I'm interested in seeing how blobs kind of like changes is that because like all the al2 data essentially is affirmable for aeral for like two three weeks I think um but all just get moved to a data storage later but I'm sure you'll have like fraud proofs in the interim or whatever commitments in the middle that will kind of prove that at that point the data was available yeah I've heard I've heard conf like mixed messages on this because

some some people I think refer to State just as the the the current balances in all of the addresses on the chain and then there's also like the data that is getting you know offloaded to blobs and then is going to disappear eventually and if that contributes to the state bloat problem too and I I'm I'm curious to see if it helps like kind of like red like decelerate the growth of State um but yeah I'm not I I still haven't gotten like a very clear understanding of whether or not it's like this state bloat thing is just concerned with the the addresses and the current balances or if it is also concerned with historic balances in in all of these

addresses um it's it's historic yeah huh okay so so then uh okay yeah and I I mean th like so when I when I first tried to get some eth I had to like I was it was like 2016 and to run uh to to even own Ethan a wallet I had to run a full node and like download the entire blockchain which there's a funny story that I'm not going to get into but like basically took days to download because it was like multiple it was maybe like a a bunch of gigabytes um so that's obviously an issue for anyone who wants to run a full node um and I'm yeah I'm also curious to see if

like now a lot of this data is going to disappear from the chain uh if that's going to make it basically easier to run a full node because you don't have to download as much data yeah yeah potentially I'm interested to see how that plays play out as well especially you know trying to scale theum so even if you have like high throughput and get a lot of transactions like you still have to solve the State issue right so I am interested seeing how how blobs can contribute to that yeah yeah it's just funny to me that we even need historical balances like if the state of the chain is like a current snapshot of like this general ledger like why do we care like how we got there well I think it's about like

that's the whole point of like data availability and like versus data storage storage yeah it's like two different things where it's not only that you have to prove that like what the current state is but say if I want to if I'm trying to submit like some kind of proof some kind of um validity proof or fraud proof or whatever it is you have to have it's like the data is available at whatever moment it was executed so have to keep it can't just be like the current state has to be you know at the mo in in the moment what was the right inputs and outputs yeah okay it's like if you're it's like accounting going all the way back right right so like so the fact that like we're gonna try to download

all of that data and like you know ethereum is storing all of that data just seems a bit ridiculous like to download the state you know it seems like we can just pick up at a certain point and then keep running this keep running the chain from that point forward um to run a full node like we don't need all that data to to be stored on each node um so to the whole state bloat thing it's like yeah let's just get rid of the historical balances it seems like a no-brainer yeah but you gotta put it somewhere about that I feel like yeah that's a hot can't just toss it away dude what are you talk because like there could be like malicious attacks you know what if they're arbing something in the middle of it so even if you end up in like the right balance

maybe in the middle they did something weird to to extract some value from it I think there are definitely ways that it could go go wrong if you don't have the historical like data of something it's not just historical data right it's like making sure that something was to prove that something was available at that time or something was executed correctly at that time Andy's clowning me DMS but honestly I feel like I feel like there's a hill to die on I like ethereum proves State transitions from block to block if we know that like we we validly went from one block from block a to Block B then like we can just pick up who cares what block a did like we're on Block B we know that it's valid we can just go from B to C I think there are something

like um I don't if you guys have looked into veral trees that's been that's been kind of a Hot Topic right of having some kind of commitment like you know some kind of ZK like witness or whatever um and it basically will prove that the data was was there at the time I want to say instead of trying to store everything like each transaction yeah yeah I think like some of these offchain um storage solutions to like K and E storage and a couple of these others are are interesting but but then yeah anyhow let's let's continue to learn about the uh the svm because I'm sure we have more questions y um I guess just a quick like to to kind of brown off the svm stuff just like a concrete benchmarking so we actually ran a

benchmarking on eclipse and just see how like Compares um and we ran this Benchmark runs about 10 instances of an amm and am performs 275 swaps so it's just testing you know how quick are the swaps um you can actually run this own this Benchmark in our in our developer docs so you can run on your own and and see what you get um but our average time is actually 34 milliseconds per swap so significantly faster than than really any existing al2 okay and then I'm going to move on to kind of the eth piece of it because that's that's the you know second piece of Thee infrastructure of eclipse right um actually I would argue is probably

the most important thing about Eclipse which is the ethereum settlement because the theum settlement really determines the entire chain in a way so what does settling to ethereum even mean it means our validating bridge on ethereum and it's enshrined into Eclipse so the bridge sits on ethereum and all the full nod full eclipse nodes will look to this bridge to figure out what the right um the canonical chain is and that's the bridge is also where fraud proofs will be submitted and you'll be eventually you'll eventually be able to do like force inclusion of your transactions via the validating Bridge um and concretely that just translates to so say the L2 sequencer for some reason decided to censor your transaction um you can go

through the bridge on the L1 and still withdraw your funds or just for you know Force include your transaction um so so when we talk about you know centralized sequencer and whatnot it is um obviously a big deal but it's not as big of a deal as people make it out to be because you're inheriting security properties from ethereum um a second thing that we think about a lot is kind of maximally using ethereum so ultimately we are a scaling solution for ethereum and we want to build for the ethereum road map so of course like I mentioned earlier if if ethereum da was a viable option I think eventually we would switch to ethereum da um there's also other ways of using ethereum potentially I know there's been a lot of talks around base sequencing um

a lot of interesting ways that we can involve the L1 and and contribute to kind of the E theorum road map and lastly I think developers really care about this but there is something to leveraging the ethereum asset base in users I think that's really hard to Discount the the network effects of eth gotcha yeah I just would push back on like the centralized sequencer isn't a problem uh conversation but we that that would take us on a whole another tangent but like is your core reing behind that with like a decentralized sequencer set like okay is one thing but then a shared sequencer is then you have to just trust another effectively L1 or another kind of like set of validators or yeah maybe you could elaborate a bit

deeper as it's just because you're using ethereum for settlement so I think that we've seen kind of a a lack of innovation maybe even on like the how sequencers are done and I'm I'm not saying I'm not disc counting shared sequencers anyway I still think shared sequencers are really interesting but I'm saying we've been thinking a lot internally about maybe having beefier sequencers so like thicker sequencers that's been kind of the meme I haven't seen me yeah thick sequencers um and because the whole point is you can have really um high like Hardware constraints on the sequencer and maybe not that many people can run the sequencer um but the thing is you have fraud proofs right whenever fraud proof is implemented you don't have to run um you don't have to

uh I guess have like a decentralized or as decentralized I should say of a sequencer set if any user can submit fraud proofs or you know you can um include your transactions from the L1 like there are certain benefits of a chain being an L2 as opposed to an L1 and I feel like we just haven't really explored those benefits right you inheriting security properties from L1 so why are we kind of reconstructing another L1 on top of it to decentralize um the network yeah I mean I I tend to agree um and perhaps thick sequencers are are the solution um I think I'm just interested in seeing more Innovation around that right so yeah thick

sequencers highly performant and if something goes wrong with the sequencer is acting maliciously you can still um you can roll it back you can force include your transactions or whatever it is and really take advantage of the fact that this is an L2 but like why would you do that like why would eclips from a business perspective ever care to decentralize their sequencer like how does it makes how is the incentives aligned this seems a bit of misalignment um I think decentralization is important I wouldn't even say like it's like a business alignment I think that's why a lot of us are in the space right like why even build a blockchain if you don't care about decentralization just use like a database it's GNA be way more performant way you know whatever so I think it's more of just like um maybe

even ideological stance like we do want to centralize the stack as much as possible and if Eclipse like Labs as an entity isn't there to run it like this the chain should still be able to you know um run and upgrade or whatever it is that governance or whoever determines yeah appreciate it it's all good just gon to push back a bit on the uh on the no decentralized sequencer part yeah I mean I think we'll we'll decentralize it to a certain extent I think it's like sufficiently decentralized but because you're experimenting with fraud proofs and all these other things I think you're able to do something a little bit more interesting and it's a gradual process you know yeah yeah

exactly um yeah I guess I'll just touch on ethereum liquidity quickly um so ethereum tvl actually this was this was from like a month ago so maybe it's even more now given given the craziness of the last month plumps yeah um but the tvl of ethereum is actually like 47 billion dollars which is pretty crazy and it's the highest you know higher than like any of the other chains combined so I don't think that the network effects of eth and just ethereum in general can be underlooked and quick comparison in terms of how Eclipse Stacks against kind of the more um the widely used l2s as well as salana so I think our

performance in in transaction fees will be comparable to salana um but the difference between us and salana is that we have this constraint of verifiability so we will we'll have fraud proofs and light noes I think totally at breakpoint last year said Salon alignment is like high throughput and low latency so for Eclipse I think we have a slightly different philosophy which is obviously we want to preserve as much of the performance as we can um but with this constraint of um verifiability could we uh could we hop back one slide and um like how does how does uh the alignment with ethereum here

mean enable easier liquidity like how do how does um the settlement onto ethereum enable liquidity to flow easy easier to Eclipse then it might something that settles somewhere else like it's a bridge one way or another yep so I think yeah that's a great question so I think East as gas has Network effects in that you don't have to hold a new token right and that's kind of been been the biggest thing about salana is you know if you look at the tokenomics of salana there's pretty crazy inflation I would say right it's like 8% or something like that every year um so you're holding this token and it's getting inflated every year and

you're kind of exposed to those risks whereas if you are already an ethereum user you hold eth um it's much easier for you to kind of Port it over to another um to to an L2 as opposed to completely like net new L1 with its own token with its own like ecosystem right for sure anybody ever Bridge the cosmos yeah that's a pain um and yeah like like could you could you speak a bit on the bridge element like uh is it an optimistic Bridge what is the canonical Bridge from from ethereum to Eclipse so the yeah so the canonical bridge is on so we have our own

canonical Bridge that's on ethereum and is it like how do you how do you prove uh you know because traditionally it's either like mint and burn mint and lock like intent based you know what what's kind of like the architecture of that bridge uh that canonical Bridge so it definitely we can obviously burn eth it'll be like we have to like lock it and it'll be mint on the other side um and it's also interesting with like svm which uses L ports as opposed to guay we have to do some like conversion there so that you can denominate in eth basically um but yeah it'll be locked on uh ethereum and then it'll mint some kind of token that's like eth as gas or E eth and that you can use as gas um on

Eclipse there is a uh an L2 which we will remain unnamed and we spoke about this on the zerit Andy and I spoke about this with uh with uh Jan from zerit and he basically uh enlightened us to the fact that there's an L2 out there that's pretty well known that just has this like this wallet of like trillions of eth that is that they use to settle Bridge transactions and that's like kind of this like gigantic pool of eth that they draw from anytime someone Bridges to that to that Network um yeah so it's just it's just curious to to like hear about some of

these designs where uh eth is up on the main chain and then it's minted on the new chain and some of the some of these protocols have taken the taken that as like oh we're just going to Mint a bunch of it on this new chain and then we're just going to distribute it out anytime that someone mins anytime someone Bridges to that new network yeah yeah I think there's a lot of ways to go about it right you having like a pool that you can pull from versus like minting it and I think there's like a lot of tradeoffs and all a lot of these designs um also you don't want to get exploited and and have like a bunch of e that is isn't supposed to be in the E Supply circulating on this L2 or like if people if everyone tries to withdraw at once like you're going to

have an issue there um so I think it's definitely um yeah it's definitely there's a lot of trade-offs in how you how you do it um but I think we definitely want to do it the safest way as possible I think you know any el2 should really think about all the different ways that things could go wrong and how do you protect against that um ultimately it's just about like user funds have to be have to be safe I think I just clicked that um you made a really good point here as well um with regards to kind of not only is is the Speed and Performance most important but you're also trying to kind of implement security and and

verifiability um with fraud proofs and light nodes how do how do light nodes how are light nodes implemented to uh your version of a rollup using svm and why does that make it more uh verifiable and kind of how does it work under the hood so for and that's one of the benefits of using Celestia because they have you know like native light node support basically since you know from day one um and light noes allows any user to confirm that celesa is not withholding any blocks and I know there was like a whole like there's a whole like meme that that went on that was like people running light nose on their toaster or like on their smart refrigerator um it just speaks to like how low the hardware requirements are to

run a light node so anyone can can confirm that the chain is acting how it's supposed to okay and I guess you know kind of to conclude the architecture piece of it um I think the way we think about it is honestly very very straightforward which is this is the most performant VM in a US is the best internet money right that's obviously a powerful combination and we've been thinking a lot about all the different types of things that you can build like net new crypto apps um net new use cases whatever it is that's kind of uniquely enabled by the eclipse architecture so I have a couple of ideas

that we've been uh that we've been thinking about um one of the ideas is a fully onchain clob that leverages lsts or maybe even lrts um so right now clobs on ethereum are you know a portion of it is offchain just because it's too expensive to for market makers to constantly adjust their position on ethereum um fully auning clobs do exist on salana currently and the benefits to end user for using like a clob instead of an amm is that there's you know usually like better prices lower slippage whatever it is the amm actually is in a lot of ways it's a byproduct of the single threaded evm right so without that constraint you can actually have better like di5

protocol or more efficient def5 protocols um so I think a fully auning clob for ethereum would be very interesting and um ethereum obviously has a really robust LST uh Network as well as now we're seeing a lot more lrts which are liquid restake tokens um and there's some interesting ways you can utilize them maybe you can you know stake an open position from a market maker and they get some extra yield on top of it or you know instead of fees to the protocol you can use those yields to pay the developer or you know the market maker whatever it is um so that's one thing and then in a similar vein is an onchain RFQ which is a request for quote so essentially you submit you know this is

what I want and people are kind of um bidding on on whatever you know you're looking for and there's a lot of uh um you need like high throughput because of like the matching matching on chain you want to make sure that there's transparency there so you don't necessarily want to do all that offchain um and so there's a lot of benefits to why an onchain RFQ makes sense and it's just not really possible on any single-threaded evm right now yeah the on onchain order book is really really cool and there's some there's some projects that are that are working on this and have been for a while like dgate um and I I'm personally excited for something like that to go to to go to market because you could you could picture like some really interesting

things where like you get paid for having an order like you know you put stink bids buy Bitcoin at a dollar on coinbase or something and you could actually use like an interest bearing token to like pay for that order um and like I think it would be cool to earn interest on limit orders um depending on like the kind of the kind of asset that you uh that you're using to post that collateral yeah exactly and you can enable kind of gas's transactions if you're using an LRT maybe I think that would be an interesting use case as well um some other ideas that we've been talking about is like continuous prediction markets right so something that you can you can have like smaller

scale predictions and you can constanty spam and it's like a live time live like real time um uh situation so obviously you need something that's low latency um you need frequent and cheap Oracle updates um that's a big thing and then of course low transaction fees and you need High liquidity um onchain uh foreign exchange Trading so that is a pretty fast-paced um at least in web 2 right it's a fast-paced it's a pretty fast-paced market so in order to bring that on chain you probably do need to use a parallel execution environment um and of course uh the liquidity aspect is important for for something like that as

well um and we had a couple more like consumer facing ideas so less defi um more so around nfts so like we talked about local fee markets I think this approximation of local fee markets and hopefully eventually an actual local fee Market a true local fee Market I think this will enable a lot more cool nft minting mechanisms right that combined with token 2022 where you can mint a million nfts for something like a hundred US Dollars which is pretty insane I think we'll see a lot more um interesting use cases for nfts outside of just the traditional you know 10,000 um pfp collection so I definitely want to see

that there's some other like gamification of nfts that you can do on something like uh something like Eclipse which is like an nft per aggregator so maybe you don't have to Bridge Over the actual asset but you're able to trade quickly on different prices of nfts um from multiple chains I think that would be a really interesting use case for you know something with a parallel execution environment um and dpin also would be a really interesting consumer use case because it requires ERS low fees to continuously like stream payments of service providers I think that's one thing that people don't always think about which is you know these deepin networks which maybe I should explain what deepin is it's de centralized physical infrastructure Network so

something like helium or render where you know I can sell my extra bandwidth to you and vice versa or whatever it is um and there's a lot of benefits to that where you know certain things like 5G is only possible really through like a dein network and the reason is because like I'm not going to get into too many de details but it's like small cell versus like large cell towers you need more um for 5G you need like uh like a small cell like every mile or something like that it's much harder for like a big Telecom company to like build that out truly um so dpin has a lot of cool use cases but the thing is when you have all these service providers um say a million wallets a million service providers that

you need that you need to reward you can't do it with the Trans action fees are anything um or even like a scent right like even if the transaction fees are a scent I think if you had to continuously stream payments to a million wallets it gets very expensive very fast um so deepins I think are really well suited for svm and of course deepens care about liquidity right because you have um there's a lot of interesting like tokenomics when it comes to deepin to make sure that the network is aligned and operating how it's supposed to so you do need service providers to be able to trade the tokens whatever it is they can't just be like stuck with whatever um so liquidity from ethereum I think it will be pretty

important for deep in deep in networks awesome yeah there's a there's there's another use case for um like streaming payments for AI um storage basically you you have like a big power source you need to rent uh gpus for uh to power AI applications and you know the rental markets and the continuous streaming of payments and you know in web 2 or I guess in the normal AI world Google and things rent out all these contracts and um kind of these onoff switches which seems blockchains will be uniquely positioned for of Clips as well um syy any any kind of closing thoughts for I'm not sure if we have another

slide or two I just want to be respectful of of your time and kind of what you've talked about with us today um I guess this actually works out perfectly because I have a summary slide look at that it's almost like we planned it um yeah I guess just to kind of summarize um everything that we touched on today which is you know why parallel execution is is beneficial to the end user in a lot of ways right and how we can it can enable a lot of net new use cases especially for the ethereum ecosystem um and I think there is something to be said in very there's something very powerful about the ethereum liquidity in user base right and ethereum historically has has um you

know has more tvl than than all the other chains and and there's a lot of network effects from eth as the gas token because you you're not exposed to a second token or anything like that um and of course I think for Eclipse um we are offering a lot of ecosystem support as well so we're giving ecosystem grants to top projects so for any Builders who are interested in building building um reach out we also give marketing engineering support whatever in whatever way we can and we will be directing users to your protocol through incentives as much as we can yeah how uh what's the best way for for someone to reach out you know if they're curious to build like one of the examples that you mentioned today um and and and explore like an ecosystem Grant um what what's

the best way for them to get in contact and then I'm also curious if you know anyone's curious to like learn more about some of these ideas um are there any teams that you know of that are building like some some of these ideas that you mentioned yes so we're actually starting a a program in in Discord so I think the best way if you're interested in building on a clipse or interested in any of these ideas um definitely join our Discord um and we'll be matching kind of developers and maybe with some of the ideas or maybe with um a co-founder something like that um and will help you kind of through um any marketing or engineering things like that so yeah definitely join our Discord um we also might do some kind of ecosystem fund so for like top Builders who are

interested in building on Eclipse we can support in that way as well um and can connect you to to others to investors who might be interested Rob just loves prediction markets so that's what got him fired up is anyone building that like do you is there a team do you know like he want to ask directly yeah can you name names uh I don't know if I can name names there there is a team building that um but I mean if you want to build it I'm I'm open to that as well build it Rob I want to predict I want to predict okay you'll be the first person also on the prediction Market too awesome Sydney thank you for coming on and sharing some thoughts it's it's

been uh our pleasure and it's very very interesting to have salana thrown into the modular stack and I think uh I I'm personally very excited to start transacting on eclipse and just feel it all out thank you guys for having me