Challenges & Advantages of Parallel VM Layer-2s | Neel Somani - Eclipse

[Music] hey everyone I'm Neil and I'm the founder of eclipse and what we're building with eclipse is it's an ethereum layer 2 and the goal is that we're making the most performant L2 so while other l2s are trying to be the most evm compatible or focusing on CK proving the entire chain right now our focus is just maximizing throughput minimizing latency and the way that we're doing that is we forked salana the layer one blockchain which is a highly performant layer one we added in fraud proofs we're adding in data availability sampling and other verifiability features and we're turning salana into an ethereum layer 2 instead so that's what eclipse is building and this talk is all about parallel VM l2s and we're not the only one there's fuel there's Mega E is coming up some of you all might have heard about that and this introduces new advantages to the ethereum ALU landscape but also new challenges so just to rephrase what parallel execution is parallel execution theoretically could be applied to any evm even the evm could be parallelized and there's folks like monad and Mega E that are working on that and the way that you would do that in practice is you'd optimistically execute rather than knowing the reads and writes up front like for other VMS the difference is that vmss like the solono VM are built from the ground up for the purpose of parallelism so that means that in the wire format itself it mentions which accounts are being accessed and that means that the scheduler can more effectively optimize the execution of transactions to Leverage The parallelism so that's one advantage another optimization Salon makes is that it doesn't uh update the global Merkel tree after every transaction so this and many other reasons are why Solana's virtual machine is essentially optimized for parallel execution and like I was mentioning there's there's other folks that are working on similar problem spaces and one thing that parallel execution enables is new types of fee markets so here I'm just going to define local fee markets briefly and it's that for each account or each resource that's being accessed you might price that differently rather than using some Global fees such as EIP 1559 so EIP 1559 has some Target resource utilization which is essentially the block size limit and they'll adjust how much uh the each transaction costs in order to meet that Target resource utilization salana on the other hand it's very rare that transactions actually hit the block limit but in the case that there is a massive nft Mint or something they want to make sure that those transactions don't congest the entire chain and this means that other transactions like defi swaps or maybe games that are running on chain can still pass through freely and they won't be impacted by those High transaction fees and the way that that works in practice is they essentially price each smart contract separately uh and that's how it work ideally instead they have this approximation where they've they basically make the assumption that the salon executor has four cores and then they prevent any specific transaction from using more than 25% of a block so they're basically assuming that let's say there's a big nft Min then that would eat up one of those four cores and the other three cores will continue to process transactions freely and that means that if a transaction bids maybe a penny or a fraction of a penny then they don't have to compete with those nft min actions that are fully occupying some other core so that that's a high level on how sana's local fee mechanism works as it as it exists right now it's not built into consensus instead it's just a feature of how the scheduler is implemented there are a couple of quirks on how that's implemented and we'll get into that later but that's essentially what what salana is um building toward so there's other advantages this is not really something about parallel runtimes but the reason why I mention it here is that parallel run times often hit this bottleneck very quickly before execution becomes a bottleneck and this is the issue of Stow growth which is frequently cited in the ethereum community and state growth is it's solved in this Salon virtual machine in kind of an unusual way and that one the Merkel tree is not globalized is not merized after every transaction so that's one advantage and the second is just the way that that things are accessed so because everything's specified up front so the reads and writes are specified in The Wire format you can fetch all that information up front and therefore you don't have to repeated make these disc accesses throughout the execution of a program so in general this is more efficient than for example the ethereum for the evm you have these dynamic memory accesses that are frequently accessing new parts of state and then that's going to substantially bottle and act execution because you have to make disk accesses and if you look at the classic memory hierarchy SRAM is 10 times more efficient than Dam and DD ddram and hard drives accesses so you you really want to minimize any accesses that go all the way to Ram or or even worse um all the way to to dis Spas so overall this this is all to say that parallel run times can get cheaper fees for users and the way that l1's typically enable that is similar methodology they reduce those binding constraints such as the number of cores that are being used let's say there's four cores being used and a transaction tries to request a fifth core then um obviously you'd have to charge a premium and that trans transaction is now competing with all those other transactions so in general it's binding constraints that cause price to go up so my point here is that because these beefier paralyzed run times just have higher resource requirements that means that the costs in general are lower and then the other advantage that layer one blockchains have is that they can inflate the token which obviously as a layer two we can't do given that at launch we won't even have a token we're just using eth for gas but um but theoretically that's another way that you can make transactions cheaper too so this is all to say that parallelized l2s given their beefier Hardware requirements can offer lower fees that are sometimes even competitive with the highly performant l1s that exist so here I just want to give a brief comparison between parallel runtimes and single-threaded run times and I'm just using the evm as an example of course like I mentioned you could parallelize the evm but I'm just looking at existing run times like arbitrum optimism and so forth and on most axes the parallel runtime is superior except hard requirements obviously imply higher costs for running that Hardware so that's a downside of course that cost is amortised across all transactions and all users State growth typically paralyzed runtimes like fuel move svm have optimized State growth in ways that single threaded EVMS have not yet uh there's safety advantages move is probably the most popular example with their type system uh the svm has some restrictions on re-entrancy any kind of re-entrancy has to be self reentrancy meaning that if it's not possible to have a smart contract that let's say a smart contract a that invokes B that then invokes a again the runtime will prohibit that from being executed whereas smart contract a can invoke to Smart contract a again that is allowed so that's just one minor re-entrancy protection there's other types of safety protections and then for proving um this is an svm specific thing because it's register based a lot of existing ZK VM literature typically is based on register based VMS so so uh so this is one reason why the spvm is slightly simpler to prove the biggest downside is that there's just a ton of spam and this is making an it's partly an issue with the implementation of the fee market and that's what we're going to be talking about for the rest of this presentation but the the obvious downside of lower fees is that the griefing cost is much lower anyone can just start spamming your chain if there's some incentive to do so they might be airdrop farming they might be trying to claim an nft mint and at which point you'd figure that that there's some optimal bidding mechanism like an auction mechanism that can remove the incentive to spam but in practice a lot of these parallel run times have not implemented something like that so this is just reemphasizing that core issue that this is probably the biggest issue that salana has grappled with and this is Whata seven eight outages in uh in 2022 or maybe that's 2023 but um but this is basically that there's there's a few factors involved which I'll get into uh here one is that it's the low cost like I was talking about the second is quirks on how the scheduler is implemented so one factor there is just straight up Network Jitter the salon of blocks are constructed first in first out so as they're received the leader starts including those transactions in a block but that's not great because it means that if you submit two transactions one after another if transaction B arrives before transaction a then it will actually be included first so it's not a property of a fee Market uh if you look at like Arbitron for example they have fairly short block times but that's not an issue because blocks are constructed at the end of the block time I think it's like 1 second block times or something whereas someon blocks are constructed continuously so that first in first out structure means that Network Jitter can actually impact the ordering of transactions and that LE that incentivizes you to submit as many transactions as possible so that you're most likely to get at the front of the pack and then there's also like Jitter within the schedule itself so even when two transactions are received it's not um it's not guaranteed what or each transaction will be assigned to so let's say you have like a nft mint transaction and a defi swap uh those might be assigned to the same core at which point they're competing with each other uh in terms of fees or they might be assigned to different cores and it's it's deterministic but it's not predictable for the average user and as a result folks end up bidding um very high amounts and might still not get included and then uh this last point is just this is an issue with just fee markets in general but when resources are mispriced such as the price to lock an account then um then that can lead to griefing attacks and we've seen that in practice on salana these are just a bunch of other competing goals and a lot of this comes from like elen Chi Tim Ru Garden um and I'll I'll just talk about a few of these just because no need to get into all of them but DC or dominant strategy incentive compatibility is probably the most important one which is that if someone bids $5 to get their transaction included then they should be willing to pay up to $5 no less and no more and that's a useful property because it means that we can quickly audit and easily audit whether a transaction fee mechanism is roughly operating correctly and there's immediate consequences of that that means that if someone bids X doll you can't always charge them X dollar because then that's an incentive for them to underbid and that's essentially what first price auctions do which is why first price auctions have all these game theoretic issues with them another one is uh mmic or my myopic mind Min incentive compatibility so this is about whether the block producer is uh is incentivized if if the block producers acting economically rationally are they incentivized to follow the rules of the transaction fee mechanism that's essentially what what m i is is optimizing for uh again a lot of these paralyzed run parallel run times have not achieved the mmic property and then the last one is welfare maximization and in ethereum world that's very well defined it's just maximize the utility of the transactions minus some well- defined measure of cost for parallel run times like Eclipse there are these subtle I'd argue the objective function is uh fundamentally more complicated because there's this informal notion that we also want to support uneconomical use cases even if there's a defi like if there's some meme coin where people are willing to pay a lot to trade that we still want to make sure that games are uneconomical applications can still flow through because if you don't have that property then you lose a lot of the benefits that the pel Run time is seeking to achieve to begin with so I'm going to skip this slide just because it goes into just the way that salana versus ethereum price things as they exist right now salana has some base fee which does not account for the amount of gas or compute units which are used uh ethereum's base fee mechanism does dynamically change but it's a global base fee and that is useful in extreme cases for example if there were many non-overlapping transactions of filled a salana block or an svm block then we might consider raising the global fee but in general we don't want to raise the global fee we want to keep the global fee really low and just raise the local fee for those applications that are getting a lot of activity so I'm going to go into a few different ways that we can leverage the fact that parallel runtimes um have separated accounts and separate resources to enable new types of fee markets and therefore cheaper fees and this first one is multi-dimensional blockchain fee markets and this is based on a paper from tarun chitra and Alex over at Bane a few other guys and they're basically observing that if you look at most fee markets they have some notion of gas which is an approximation of many resources gas is accounting for computes it's accounting for memory block size many other things and they're trying to average that out into some fungible unit whereas if you had a full optimization solver available to you then you might actually break those resources out so you might break out cores and have some Target resource utilization for the number of cores that are being used you might have some Target resource utilization for memory for um how many accounts are being used at once just every resource could be broken out theoretically and what they do in this paper is they formulate the problem just as you'd expect it so they say let's maximize the utility that each user is willing to is getting out of their transaction executing which is an unknown and subtract some measure of of cost where that measure of cost accounts for how far each resource utilizations um like how far each resource is being utilized in reality compared to the Target measure so they have this objective function they convert it to the lrange Dual problem they solve that and it turns out that even with some unknowns in the Primal problem you can still get the optimal solution so this is implemented in practice with Avalanche penumbra few other folks and what could be interesting is applying this to account or individual accounts of course that leads to a very complex optimization problem and maybe we'd have to have an approximation of the exact solution for for the resulting optimization problem this is another one that's being proos proposed for the svm and what they're basically doing here is for each individual account they're applying some notion some local EIP 1559 so they're saying if an account is being used very frequently we're going to increase the cost to access that account and if it's not use so frequently then we'll decrease it up until some up until some minimum fee so this is better than the existing local fee Market implementation just because now it's enforced by consensus so that's one plus the downside is that it does seem to lack um it it doesn't observe the differences between resources like compute memory things like that and it's also relatively complicated to keep track of all these moving averages of course there's pretty efficient ways to calculate a simple moving average but think if you're calculating this across millions of accounts and you have to do this on every single validator this is a runtime that's optimizing for performance first and foremost so anything that can impact like let's say it's Target goal of thousands of transactions per second then that's probably UND undesirable so they impose some limit on how many accounts would actually be tracked in practice and where this exponential moving average would be applied so this is the kind of stuff that we're thinking about at eclipse for our fee markets we want to balance the concerns of making sure it's economically optimal in the sense of welfare maximizing but we also want to make sure that we're supporting these quote unquote uneconomical use cases like gaming nft mins things that typically might cost an exorbitant amount on evm chains just because those are often not the most important transactions but this is one of the informal design goals of parallel runtimes so I think there's a lot of stuff we can take from the existing ethereum fee Market literature and apply it to the svm if you at how Salon has traditionally been approaching it I think the conversations are sometimes disorienting from for the ethereum community and vice versa when etherium mechanism design literature is Expo is shown to the Solana Community it can be disorient disorienting for them too so I think that eclipse is a good opportunity to bridge those two gaps and um and leverage the best parts of the theum fee Market literature and apply it to the sfm cool so I'll uh give those three minutes back unless there are any questions the audience um but yeah thanks thanks for your [Applause] time