From High Fees to High Speeds: Optimizing the SVM For Ethereum - TOKEN2049 Dubai 2024

I don't know how to go back but okay um yeah so I'm Neil I'm the founder of eclipse and for folks that might not be aware of what we're building we're aiming to build ethereum's fastest layer to and the way that we're doing that is we for salana which is a layer one blockchain we're keeping the virtual machine intact so it's highly par Iz very performant virtual machine and we're settling it as a layer two on ethereum and what this talk is about is it's targeting folks that are probably familiar with the existing layer 2 Landscapes that's a lot of evm layer 2s like optimism Arbitron and what this talk is intended to convey is one what are some of the superpowers of layer twos and what are cases where layer twos can even outperform layer ones and secondly how that informs how we're thinking about Eclipse so this might be um this might be lost on some folks some folks that are familiar with the discourse in the ethereum ecosystem this might be old news too but for the longest time the biggest subject in the layer 2 ecosystem was Data availability and data availability is essentially bandwidth it's saying when a layer 2 blockchain executes a bunch of transactions or even a layer one blockchain it needs to propagate those transactions to all the full nodes of the network everyone needs to be aware of what was wrong and that's the first step for any blockchain so that was originally the bottleneck and that's why things like Celestia Avil igen da all these folks popped up and more recently we have 4844 on ethereum which is an upgrade to ethereum that allows it to more um conveniently support layer 2s by having some native capacity for da da is short for data availability so this was always the bottleneck and it's just because bandwidth is very hard to scale effectively all the nodes need to talk with each other and more than that you want to scale it in a verifiable way so if you're a lightweight device like a cell phone or something in enal you have no way to verify that a really big block that's being propagated by these ethereum flow nodes is actually being propagated correctly but with the Advent of this technology called Data availability sampling they were able to effectively scale this and this is no longer the bottleneck so now there's a new bottleneck which is execution so the first step is you say what are the transactions that are supposed to be run and the second part is you actually have to execute them and in that domain salana has always re Supreme so it's a parallelized VM like I was saying and now we're seeing all other layer twos are EXP exping the same bottleneck base is a great example which is coinbase is Layer Two now they have some goal of I think it's like 2.5 million gas per second so it's some measure of throughput for execution and it's just saying how quickly can you process op codes or operations in a layer two and in general the evm can be boosted substantially more than where it exists right now but it's a lot harder than taking a virtual machine that was built for this from the ground up so this begs the question now that we have abundant da and we have abundant with how can we best utilize this block space and that's the problem that eclipse is primarily thinking about so just to recap what eclipse is doing we took the salana virtual machine so we fored salana we're making a bunch of changes to that secondly we're using ethereum for our Bridge so we're going to have fraud proofs and in the future ZK proofs that settle to ethereum we use Celestia for data availability if ethereum were to scale its da capacity then of course we'd use ethereum natively and then there's this other P risk zero which is used to generate our fraud proof Which is less important for this presentation but this is where Eclipse lives right now and what I want to point out is that if you talk if you like listen to any of the discourse about these alt VMS like monad which is an L1 or some of the other layer twos like fuel or eclipse or um even like non-p parallelized EVMS like Mega E people talk a lot about parallelism but the weird part is that is not the most important optimization it's just the easiest to understand so I think it's at least mentioning what parallelism is uh for those who aren't familiar it's a concept that's not even from crypto it's just saying that when we want to execute multiple State transitions over the database which is the blockchain then uh how can we do these concurrently rather than doing them one at a time historically blockchains like ethereum or other Ean blockchains did uh execution sequentially so they did one transaction at a time whereas Sana has some capacity for parallel execution it's not super built out at this point and the reason why I say it's not super important is because it's rarely used in general not all the cores are necessarily used even in the most paralyzed VMS and that's why that's not typically the bottleneck anyway so what I want to do is take a step back and think from first principles in terms of what is the bottleneck and how would we design in L2 knowing what we know about what l2s are good at and what layer one blockchains are good at because to some degree Eclipse forked the svm so we forked the salon virtual machine but the salon virtual machine was built to be an L1 so first I want to talk about what are the advantages of the svm is if you were to build a perform in L2 s is a very natural place to start and then I want to go into why eclipse is not going to stop there so the biggest advantage of being the spvm is that we have access lists meaning that we know exactly what parts of state are going to be accessed during execution and that has two advantages one me is that you can execute in parallel and you can lock transa you can lock different parts of State you can know exactly what's going to be read from and ritten to and like I was saying that's not actually a huge advantage in practice but that is one theoretical advant AG the second is that it means that you can load all the state up front so if you have one transaction that's accessing like 20 different accounts you can load all those into memory and you don't have to fetch it dynamically and for those of you who have taken computer architecture you know about the classic memory hierarchy you of like SRAM and DD RAM and everything else down to your hard drive in general you don't want to go lower down that stack so if you can get something in memory sooner that's typically desirable and it can prevent a lot of wasted Cycles so that's the advantage of why um salana has these access list and that's why even if you take an evm uh L2 and you try to optimize it as much as possible it's going to be really hard to compete with this of course you can put all the state in memory or something but then your memory can only get so big and this going to lead to stap load so that's asvm versus evm and the way that I think about how Eclipse should be optimizing is by thinking in terms of North Stars so every ecosystem to me has some North Star that they're primarily optimizing on if you look at ethereum it's primarily sensorship resistance you could say that there's many other values of ethereum but to me this is what ethereum is the best at for Cosmos they talk a lot about sovereignty you get your own app chain you can make whatever customizations you can Fork it you can do whatever you want with it salana obviously optimizes on performance even though right now with the congestion it might not look like it salana first and foremost cares about performance and salasa cares about verifiability so this bags a question what does eclipse care about and this is what eclipse is Northstar is to me its performance with this hard constru of verifiability so this is a fundamentally more complex objective function than what Sana optimizes for given that Sana optimizing performance doesn't really care about verifiability and that you don't need to be able to run a light note at home you don't need to have proofs of execution and that's okay and it's actually really good that salana optimizes for that because it means that we can borrow a lot of those Innovations but that's not what eclipse is optimizing for we have this hard constraint meaning that we want the end user whether you're running a cell phone or a lightweight device to know exactly what was executed and have confidence that it was executed correctly so now the reason why the Northstar is important is because if you're really effectively optimizing for it it's really hard for any other type of blockchain construction to compete with it so if you agree with me that high performance and verifiability is what matters then you'll probably think that the way that we're constructing Eclipse makes a lot of sense so I want to start with the hard constraint of verifiability and talk about why it's not possible for a layer one blockchain to just start generating proofs and start providing the same Advantage as a layer two and it comes down to the simple reason that verifiability has a cost if you're a ZK rollup you have to generate ZK proofs for every single transaction right now the overhead for that is for a single cycle of execution in general it's something like a 100,000 or a million Cycles to generate a proof that that execution was done correctly so there's 100,000 to a million times overhead for a ZK roll up just to generate that proof of course that's going to come down over time if you're an optimistic rollup you have to include these additional commitment bites you have to publish more data in order to prove just it's just a quirk of how the interactive fraud proofer works but all fraud proofs require some additional data to be posted so if you're really optimizing on just performance you're never going to add this capacity so that's one advantage that Eclipse has which is that we own that we internalize the clost the cost and we're going to take advantage of it and the biggest way that I want to take advantage of it is that once the blockchain is proof-based you actually want to make the full nodes extremely expensive so it's okay to have fewer nodes or what some people say is a centralized sequencer set because everything's proof-based anyway so the end user still has assurance that things are executing correctly and you get all the advantages of having really beefy sequencers and executors so this is kind of counterintuitive and it's one of those classic dunks against layer 2 blockchains that doesn't really make a lot of sense people talk about how l2s are centralized because the sequencer set is not like a thousand nodes but actually that's a superpower and that's what eclipse is leaning into so we're going to have a smaller sequencer set and make the hardware requirements very very expensive and this way we can provide performance that even the salon L1 can offer and I'd be remiss not to mention that there is some sort of safety consideration here given that for folks that are familiar with optimistic rollups you probably remember that there's this one of end trust assumption you need at least one honest verifier to be running a full node and that's how you know that the safety of the system is ensured so in our case our full nodes are very very expensive so what keeps these verifiers running their full nodes and there's a handful of folks that can run full users are one it's unlikely that users are going to be running our FL noes because they're just so expensive salono FL nodes are already expensive and we're making them even more expensive there's indexers and explor explorers those guys provide a service they charge for it so presumably they could charge someone a sufficient amount and it could be economical for them to run a full node there's uh full node Bridges there's me Searchers so in the beginning we might actually want to incentivize some of these folks we might have some concept of inflation or emissions similar to what an L1 would have until Things become economical for these folks to run their full nodes on their own so this is uh one reason why Eclipse eventually has Ambitions to transition to a ZK rollup just given that this one of end trust assumption makes it really it makes the analysis more complicated and this is just a high Lev handwavy analysis but this is worthy of more more deep consideration so I don't have time to go through the whole deck here but um one last thing I wanted to touch on is that by having fewer nodes it means that we can push upgrades a lot faster meaning that fire dancer is a salana client that's being built it's designed to be ultra performant but actually the salana L1 will not fully benefit from fire dancer because not all the nodes are going to upgrade whereas because we have a small sequencer set we can upgrade these nodes faster we can Implement updates to the fee Market which is one of the criticisms if so Ona right now we can Implement all kinds of Cutting Edge features that in general wouldn't make it into the L1 but we can Implement them first so this is essentially what eclipse's endgame is I call it a thick sequence thck meaning that it's a really beefy expensive sequencer and it's going to be settling to ethereum meaning that it's settling to the most sensorship resistant L1 that exists and these are some other properties that are think that I think are desirable But ultimately this is all consistent with our Northstar which is that we want to offer high performance low cost and we want to have that hard constraint of verifiability so I hope that's helpful for giving an overview of how the LG landscape exists right now where Eclipse sits in and the kind of value that we're providing to the ethereum ecosystem and more broadly okay and then if you ever want to contact me I'm on Twitter so I'm Neil salami or you can reach us on Twitter uh Eclipse fnd um so yeah um if you're building anything that's like a consumer app a highly financialized app defi nfts that's all stuff that we're really interested in so feel free to reach out all right thank you