# [CLS] Ethereum Magicians Infinite Endgames: Ethereum Execution by lightclient | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 1:20:49
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-o8n-MCAnxso
- YouTube: https://www.youtube.com/watch?v=o8n-MCAnxso

## Description

A fishbowl-style discussion with core Ethereum contributors and community to publicly discuss the "endgame" of execution on Ethereum. We will discuss what the evolution of Ethereum’s execution layer will look like, L1 vs. L2, settlement vs. execution, enshrined rollups, consensus changes vs. client performance improvements, etc.

Speaker(s): lightclient
Skill level: Expert
Track: [CLS] Infinite Endgames by Ethereum Magicians
Keywords: Core Protocol, In-protocol Account Abstraction, Rollups

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] [Music] us here for this ethereum magician Community Le session I think that we have a lot of people in this room who care about execution on ethereum and I don't want this to be a panel of us disseminating information to you the idea is more to have an open discussion with the community but I have many prompts and I know that there are some people who have a lot of context on the questions that we're going to contemplate and so maybe it will make sense to think of this as a bit of a fishbowl where we get the opportunity to talk about the things especially some things that we may not get to talk about in our day-to-day jobs and you can have the opportunity to listen a bit and maybe take away some things but if you have something to say or ask feel free to come up take a seat up here and feel free to ask us a question with that said we've got a couple people on up here on the panel I don't know if you guys want to just go ahead and introduce yourselves really fast across hey I'm Alexi from RE I'm danaren I'm working on eof right now I guess I didn't say that I'm also like clients working on go ethereum and I'm G working on go ethereum and also heading state stateless consensus we we work on everything stateless so we've got a few people up here who are very involved with the execution layer of ethereum and I wanted to sort of start off this conversation by just asking each of you what the ingame for execution in ethereum looks like I think especially on the execution layer we think a lot about what the next Fork is going to look like what the next one or two years are going to look like how we can make incremental changes to the execution layer I wanted to give this as like more of a thought exercise what what could the world look like obviously it's very difficult to change the execution layer because so many people depend on the interface being stable but if you could say what you think the endgame might look like in an execution world what might you come up with lower block Time 1 second or some streaming approach where you send transactions and don't wait for the block to form uh higher through Poots where you have uh um higher gas limits or for example you have more optimized TVM and you can pack more um execution into one block into one transaction um it was about performance I think about um the notes itself the stateless or some kind of a light note that allows you to not run the Noe with a whole state because because we think about 10 20 years and uh state will be enormous even if we drop the history so we need to think about how to have a validating note or if you are not like inferior Alchemy how to run a note at home without 4 tab dis um for me I think these are the most important questions and um there's a whole lot of like things that l2s can do with experimentation on the evm um on the networking player I think for L1 this is my top of Minds um so for me when I think of uh the future of the execution environment um I tend to take a perspective not from the perspective of who's running the node but who's using the uh the environment that they're executing in much like uh computer programs you're in typical operating system today they operate in different user spaces they operate in different layers and some of those have different rules but at a certain critical level they all use the same language um the same operation code describe what they're doing um so like you know when you go into the kernel in ring zero there's things you can do and things you can't do and when you go into user space you have a whole lot more freedom to use things like absurd amount of memory and spend a lot lot of time executing things but when you're doing a video driver you have to do things quickly so for the future of the execution environment um I see standardization and uh probably a little bit of specialization depending upon um which ring of the chain you're running on if you're settling um thousands of transactions you're going to be in and out as quick as possible and if you're 3D rendering your pfp from your nft you're going to have a lot more freedom uh but it's going to com it's going to compile mostly to the same executable format and be portable and if you have enough money you could render your pfp in ring one I wouldn't recommend it but you could so I guess my answer to the question is slightly less developer or user Centric is maybe seems like you guys are you want the developer experience to be good you want running a note to be good and I guess for me I want running a node to be good also and I want want these things but when I think like what the ingame for execution is I thought there was this nice interview from vitalic a few years ago talking about what he thought the end World should look like in ethereum and the way that people should consume the chain and how he described it was that he envisions that every 12 seconds you'll receive a small proof over the internet and verify that proof and move the head of the chain forward locally one block and to me that that to me is what feels like the right endgame is we have simplified the process of getting of trustless interact like creating a trustless connection with the chain it gives us the route where we can now prove any anything that we need to prove about it of course there's many questions down the path like how can we get those proofs will what will those proofs look like will they be efficient but the core of the thing is that on basically any type of device you can efficiently verify that you are at the head of the chain and this even goes beyond like clients today it's sort of possible to do this by verifying the like client sync committee over time but it only gives you an honest majority assumption and what we want in blockchains to typically is that we want people to fully validate the chain and as long as the chain to fully validate the chain you need one terabyte two terabytes of history or storage or you need to execute you know tens of millions or hundred millions of gas it's always going to be something that is better left for you know more professional Hardware not something that you can do on the fly on your phones so to me it feels like moving towards that direction for the ingame I would love to see more ZK evm work more ZK VMS that's something that I think is where we want to go and the path to that point to me is not so clear it feels like it's a bit away if and yeah I don't know if you have things to say on CK evm or ckvm or stal lless but I am like very curious about how we can go from where we are today thinking about kind of incremental Forks to making a huge leap to something like a zkm and Stat lless um yeah there's a lot of unpack there but maybe um okay may maybe let me give my own answer before I plug into this uh what I'd like to have in ethereum is you know the promise has always always been the word computer and I just want that um and currently we have a lot of sillo between um between l2s what I want is for execution is I want to be able to call something from a contract on an L2 to go into a different L2 or L1 come back it doesn't have to be immediate uh you were talking about Ring zero ring one ring two those like Crossing those boundaries is extremely is extremely costly even on the on the normal computer um but we should we should at least integrate the experience like a user doesn't know oh I I did a system call to to switch uh to switch ring zero I want the the same thing I would like to have actually uh diverse execution environment so uh going back to to your question but I'd love to have r five I'd love to keep the evm because the evm is great um wasm you know I I've seen some former wasm colleagues in the audience um maybe not but you know RIS five evm uh I'm going to shock Dano but yes evm with theof that would be that would be great um and uh and when it comes to zvm uh sorry what was your question again the the zvm uh um I mean I was just curious if you have any thoughts on what needs to happen on L1 you know in the next 5 to 10 years to bring us either to having like core consensus clients verifying proofs of evm execution or what types of things need to be done to move us along that path right I mean does anything even need to be done because there's also a thought that maybe in the future the proving technology will be so efficient that nothing actually needs to change it will be uh probably um it will be probably no no yeah probably yeah uh the question is how long are you winning to wait and how much uh how much uh risk are you willing to take I mean it's it's always the same problem so if you have some claims I mean I'm I'm a bit skeptic of them but for example sp1 say they can they can uh create a proof for a block for at 20 cents uh like 20 20 cents per block um in my view it's not fast enough but we could get there right we could uh we could imagine like changing if we found the the tree structure that allows everybody to build their own ZK proof in no time then execution is you know you can do upgrades you can you can add r five you can add even was them uh it doesn't matter because everybody will be able to prove everything on their machine and uh send around proofs that are small enough so it everybody can receive those proof in a those proofs in a in a very short time frame could be a cross shards could be a well rollups sorry but I I have the vision that the Roll-Ups are going to be enrin into shards at some point at least some of them um so it's like a trial period for for becoming a Shard um so yeah what needs to happen I mean a lot of a lot more research a lot more discoveries we also need the the Z the pace of ZK Improvement to to stop because they keep churning new ideas but once we have something uh you know that is good enough and that is also not guaranteed to be replaced by something in uh in the next five months I think we should start uh we should start cting but I think that that future you describe is not too far too far off I want to dig into the native sharding aspect but I also want to mention quickly a lot of people are walking in this is a community-led session if you have something to contribute if you have a question to ask please feel free and take a seat we'll try and pass over the mic to you uh would love to just like hear more from what you guys have in your in your head and we'll add more if needed okay this yeah does anybody want to lock the [Laughter] doors it's only a fire hazard yeah if it's possible to increase the volume that would that would be great real quick yeah I would like to get yeah your guys's response to so I have a suggestion regarding the door maybe we can have like slot so every 5 minutes people are allowed to enter or leave and in between the door is kind of locked that would be nice slots can we get down a one minute slot just kidding so I want to riff really quick on the um this what I would add in the next five to 10 years on top of ZK I do think we need a bit of ZK um because let's take the scenario you got someone working at a coffee shop they just got paid and so they need the global State compressed they don't need to care that their coffee shop just executed a gigantic financial debt trade to make sure that they could pay their workers they just need to know that they had enough money to pay them and they don't need to know how it interacts with the rest of the market maret um to to get everything working they just need a ZK proof to say that the money that they have is valid but on the other hand I think it's something that I would add in the next 5 years is ways to increase isolation of transactions so you have this big giant ZK of every transaction on the chain and we need to have whether it's through op codes or whether it's through Witnesses like veral ways to take out just your transaction I just care that I got paid from my coffee shop and that I can prove that on my SmartWatch and I can run through and run through the entire execution locally without having to run the entire execution of all of Unis swap on for the entire block so my vision for the next five years is zking it to make sure that we only care about what you care about and isolating and executing that one part that you care about and having everything that you can need proven into that route that advances every 12 seconds um sorry if I may add okay when I said it's pretty close to happening five years might be a bit optimistic but yeah if it can happen they would be great okay I really want to dig into this we're kind of talking about Native shards we're talking about um isolation of execution but I wanted to one quickly ask before we in in that subject is does anyone feel that ZK evm does not make sense on L1 in some point in the medium-term future in 10 years are we going is there is something going to happen where we say maybe we should never ZK the L1 is that something that people generally feel is going to be in the end game no before going into the I wanted to introduce another teammate from RE hello everyone I'm Dragon AK I'm part of R mostly doing work on RM now uh glad to be here um yeah welcome just um no just going back to the to the thing um I think okay my view at least it makes no sense not to ZK uh the the VM uh because what we want is also I ZK might be the wrong term but we want we want privacy um like this is one thing that's really missing in the blockchain space we have zcash but actually I haven't checked maybe someone knows more about zcash than I do um they're not really popular I haven't seen on coin market cap for quite a while actually then okay doesn't matter the price is one thing but that doesn't make everything um we yeah like we need to have something that's going to step up for to replace zcash and or maybe maybe have zcash as a as an L2 why not um but yeah privacy is going to be a big Topic in the in my view in the in the coming years and we cannot not do um anything ZK related like we're going to want to push more ZK and as a result the ZK VM is basically the thing you need to like the step you need yeah I guess I was hoping to separate that from doing it on the L1 like do you feel do you feel that yes privacy is important yes distinctly verifying execution is important but do you think that it's something that we'll get to a place where it is going to be on the critical path for the L1 or do you think that it's something that may be relegated only to layer twos um yeah no I mean if it's going to be on layer twos okay once again I believe that shards are going to sorry roll uh rollups are basically shards on the trial period so we're going to need to need this that's uh I don't know what the future is made of but otherwise you would have such a disconnect between L2 and L1 um and dl1 being the least uh private uh private chain in the entire space that doesn't make sense to in my view um I think I feel that it depends on technology in 5 years ZK and every basically that industry is moving for very fast in 5 years it should be we'll see it depends of how fast it will be if I can prove full Block in consumer grade laptop or something like that then in 5 years it will the question was why didn't eum include the zkm so I think it depends on technology in five years it's very hard to say now if the zkm is going to be like um good fit for ethereum in 5 years uh I just want to add just a point everybody says ZK but what we're currently looking at is uh uh like Starks or snarks what what we're seeking right now is to get the S which is for S sickness uh I hope that was correctly pronounced um we want to be able to not redo the entire uh the entire execution uh ZK is zero knowledge this is where we add the Privacy layer this is way further off than uh than than just the Stark but yeah okay uh we also have Jared we were joined by Jared so cool thanks hey all I also work on the GU team um I guess I'm I would just be curious uh if the evm currently lends itself to uh being able to be efficiently metered from the perspective of approver seeing a transaction or a block to uh know that certain code uh knowing the cost of proving certain code I mean uh like for example we have various pre-compiled uh uh that depending on the ZK protocol may be uh expressed strangely in theover which uh such that the cost approve does not correspond to the gas they consume on the Chain um so like we for example I work on a proposal called evm Max which is a uh proposal to bring uh more efficient modular arithmetic to the base layer and I feel like in this case like if we can express pre-compiled uh more efficiently on the base layer in ter so that you can see from the pro perspective what is actually being done instead of just an opaque pre-compiled that would lend itself well to zkm so that was a large part of the motivation for removing gas introspection from eof um it allows us to do dramatic changes to the gas schedule um without breaking code that depends on particular values in the gas schedule because back before constants opal we had some some design patterns that depended upon specific amounts of gas being available to execute reverts and when the price went up those contracts broke in horribly unexpected ways and they were broken until we added um the access lists uh much much later so so getting rid of gas introspection prevents people from engaging in those patterns that make dramatically Chang Ching the gas schedule and if we can change the gas schedule we can do fancier things like have multivariable gas schedule to where the storage could cost different from the execution and then things like having the kak op code be completely unrelated to the price of the other op codes and depending upon whether you're executing um in a snark context or whether you're executing in a computer context it could be priced wildly differently so yeah um gas metering is important but I think also variability in the gas metering um is just as important because gas metering is how we solve the halting problem actually um maybe I misunderstood what you said but do we need like in the fully uh starky fire or snarky fight future do we even need uh gas metering because you know we we just have you need gas metering if you're going to force someone to create the proof for you if you create the proof it doesn't really matter how much execution you do yeah because you have created the proof so it's can be succinctly verified but if you just send a transaction to a bundler and you kind of expect that they're going to bundle it then you need to kind of pay commen to paying is a different is a different thing but like the metering itself you know you could just say uh pay a fixed price and if you go beyond you need to zero knowledge proof that or Sally prove that the amount of gas spent charged from this was a tangent maybe we we should discuss it my view was that precisely if you get the proof in in due time then you did not go overboard but okay let's uh that was just a tangent let's move on yeah um good introduction to split between the builders and verifiers sorry good introduction to the split between the builders and verifiers right I think in the future we'll see the split between between those two if everything like snar fight it would be more obvious but even now we are seeing like Builders being separate entities with M boost everything they building the Block in performant way they want to extract value in there is different back of discussion about that but I think in the future we'll see that split even even more I think it needs I think that it even needs to be included in like uh core protocols and in some way or form I'm not sure I'm not that familiar what exactly would that be yeah okay I think uh I think that we mostly agree we would love succinct verification we would love privacy on L1 these are things that from scratch we would try to build a system focused on that of course the technology is advancing rapidly we have to see what things look like in five or 10 years I do want to jump back to a point that was made both by you and Dano about isolated execution native sharding maybe you could try and Pitch the community native sharding and why it's important in the endgame I mean yeah I don't really okay let's say there was a always this uh this plan right uh a lot of other blockchains are are doing sharding we took a different route which is fine we don't have to do Native sharding I mean I'm not going to to die on that hill on that hill but I think the the biggest problem with rollups is that they can they can disappear so I think at some point like as long as they're backed by only one company those companies could go bankrupt uh I mean everybody remembers FTX so yes everybody could exit that's the point of the rollup uh anybody can exit at any time but uh then you lose some execution capacity it's like it's like losing a thread on your like a hardware thread on your processor uh so I'm trying to finish because Doo has something to say but um I think the reason why uh we kind of want to make this like we want to have this uh to create this space to for people to um to experiment but uh at the same time as more and more structure starts relying on those things we should make them somewhat official uh so that the community takes over it's like people uh out you know like companies open sourcing their software uh after a while software some software becomes so uh infrastructure critical that it it needs to be open S so that the whole the community as a whole maintains it and I think it's the same for rollups shards yeah so the concern about robs going away is is real when they lock it in with their keys but when they take the keys away in theory a single honest validator without permission could Advance it we're not there yet and a funny story that came to mind um fuel VM version one was one of the original optimistic uh uh rollups and someone tried to to publish a false proof of the block to test the system and they thought no one was using it was dead and they got proven wrong pretty darn quick so just because it looks dead doesn't mean that nobody's there trying to gain the um the the fraud proofs from people trying to do bad things but as long as as long as these chains are are um are held by required private Keys it's it's a huge risk right so I guess if we're thinking about what is the in-game for execution in ethereum to me native sharding doesn't feel on the that critical path because what we're talking about feels to me much more shorter medium-term issues with the infrastructure and the expectation of things being around for a long time I don't see an innate reason that we must have shs that are native to the protocol and I think there's actually a lot of good reasons to not do this especially if the endgame is you know more zero knowledge proof based things you don't have the types of issues where you have to have a live operator watching the chain all the time making sure that the transitions are correct I mean even in the sorry um I feel that we should leave that part the rollups to do their own things maybe there's future where we can help with that like to embed something inside L1 to help like some standard something like that but that's most like let's help them to do their own things but if there is I don't want to force anybody to do it in some way or some form I think the current system where everybody can do their own thing is pressures because um the next thing is going to be better and the next thing after that is going to be even better so Evolution improvements will happen on its own I would agree and uh add that if we agree that rups can uh evolve at the rate of of ethereum then it's fine but I think ROV can go faster and they want to go faster and that's uh what we want to have uh rollups innovating not at the same speed having different security uh trade-offs than L1 and uh you have more secure uh rollups you have um less secure for I know games or whatever and it should be fine I agree that maybe some form of U um a rollup or something can be enshrined for example for uh for private payments when you have a very simple use case uh or maybe it can be done on the L1 itself uh in some way but there is a huge kind of forums like with um the privacy on L1 and the legality of these and how it should be done properly yeah um I mean you know it's not like I disagree with what you're saying but you know you said something pretty uh telling for for me it's like should be good enough you know and like it should be okay sorry I think you said uh what I'm worried about with this whole rollup becoming part like enrin somehow is that um I'm more worried about the worst case you know I'm I'm hugely paranoid uh I'm always thinking about how things can go wrong I mean I think it's my job actually um so um like I want you know one second BL time I want uh I I want everything to be pachy but the fact is life life is not always perfect and I'm really worried uh about how things degrade when they don't work and that's why you know um I want something when something becomes critical enough I would like the community to take it over more than uh just trusting that everything is going to be fine but apart from that I completely agree I agree I don't argue with this I think that would be nice to have um how it's called like security hedge or whatever uh to withdraw your funds to force a state transition on the rollup uh but we if we say that okay optimism or like arbitrum is uh too important and we uh cannot uh like Let It fail um and we want to enshrine it then we um need to adopt ethereum L1 for this and uh I don't think we can do that um and uh if you think about users uh and we should obviously I don't think that a lot of users will agree um to uh make the execution of transactions worse to make the uh ux worse um for higher security assumptions uh that's unfortunately not something that majority of people worry and uh I think we should uh work from this somehow that people today use optimism arbitrum whatever rollups um because they unfortunately care less about having uh sensor censorship resistance or whatever decentralization that we have I mean ultimately this is a philosophical debate um you know like yes users yeah I'm aware uh me we're all aware um most people want are who in interact like with smart contracts are mostly are hoping to get rich that's I mean we all do I guess but um you know we have a philosophical responsibility I think to also say well okay the experience is not as good as uh as your bank although in many respects the etherum experience is already way better than any bank I'm I've been interacting with um but you know it's one thing but we also want to give you guarantees and I think that's part of the product and yes some people are it's not going to be good enough for some people and they're going to go away and it's it's a pain but um or it's at least it's a it's sad but uh you know those people just need to use Banks that's it uh and uh yeah I'm sorry for them but uh yeah I disagree I think we should do better uh than Banks and better than web to and uh do not compromise at the same time on the values that we have and deliver this like privacy decentralization whatever in uh like a tr horse uh with the batter ux and people will use it for some reasons like um no uh ge uh restrictions or better ux or lower price or better performance and get at the same time privacy and decentralization without actually knowing this because as I said I think most people do not care that much unless they live in some areas in the world right that's the thing like people don't care until trouble hits but okay no I agree we need good U ux no question about this we need better uxix no question yep so it sounds to me like what we're talking about is is we want to make sure that the platform or the product that ethereum is is providing is going to be around for a long time is going to be correct is going to provide ux and so the way that we sort of pivoted to doing this is the rollup Centric road map and I'm curious to hear from people up here and anyone who's sitting on the seats I think some more people have come in feel free to come up here and grab a mic if you have something to ask or something to say I mean we know each other so uh you know we'd like to see someone we don't know I was just going to say there's questions behind so uh we yeah we we'll get there eventually I think um but I wanted to ask at what point would you say or what would you need to see as a contributor to ethereum or a Community member to say this rollup Centric road map did not work and maybe we should rethink what the future of execution in ethereum is yeah for me think today ethereum L1 is not just for olops I think we were thinking that uh uh L1 is just for settling and we some people say that we should not improve evm for example uh because it's good enough for the rollups and we should focus on the U blobs for example or pieras I would I would argue that we want to have good experience for defi on L1 as well and uh we want to keep this value that protocols have on L1 and uh we want to provide the security guarantees that we have so it's not fully uh rollup Centric and we still think about the ux and the speed of inclusion and uh the Sens the sensorship resistance and especially the things like uh slot time or block time when we uh make the experience in defi better for users so I would look at this from the perspective of L1 for roll s and uh high value Defi and work from this yeah definitely um I'd also say that making L1 and the evm on L1 more expressive directly benefits rollups in the sense that those changes trickle Downstream um so anything we can do on to make the evm more expressive for example to implement uh more efficient cryptographic Primitives on the L1 evm that will naturally lend itself to making rollups better so yeah I guess maybe to reframe the question a little bit you know if we could go down to thought experiment imagine that you're in a more traditional company there's kind of a hierarchy you're managing a bunch of engineering teams and you're sort of tasked to do this research project try this thing and you're asked by the people who you report to to say what what are the metrics that you need to see in three years to know that this project was successful and I'm curious like what types of things would you want to see rollups to be doing in three or five years to say this is the right path is there anything that they could be doing to say that this is the wrong path because I think that we could probably all agree that in if five years the amount of users in ethereum is like much less than the the amount of users that we have today that something is wrong and maybe the role of centric road map was is still right but we have to be able to analyze the actual situation and not be stuck in uh stuck on an ivory Tower of theory and think about like the practicality of how do we bring the technology that we're trying to bring to the people that need it I think one metric I would look to I don't know if it would be a good metric or a bad metric but it would give information is how many rollups leave the ecosystem one way to view that may be that they've gained escape velocity and they can exist on their own and another one may be that they're leaving because they can't get what they need for support from the central L1 rollup um but that is that is one metric I'd look up to get measurement on how it's working and another thing I would get measurement on is um how the rollups are differentiating themselves if they're different any themselves and what that impact has on the ecosystem as a whole um you know is is this is this going to be the case of of you know giving away the milk instead of making people buy the cow you know that's that's some of the the things that I would look at to make sure that um we're not just um you know creating a new set of problems and and and the thing is like trying to judge the success or failure of rollups is is kind of difficult because whether or not vitalic posted that post about a rollup Centric road map these companies and these teams would have been doing Ro would have been doing rollups they didn't need l1's blessings they don't need l1's blessings and the real question I think is is what the relationship is between the L1 teams and the L2 teams and what we expect from each other and what we're going to provide for each other yeah that's well said any others I guess I would say like a to tack onto that a simple metric in my mind of of evaluating success uh overall is I mean can we find a use case that isn't just Financial right I mean so I think like I think uh uh the the Eve Online MMO they're they're they're pivoting they're they're doing a new project on optimism um so this is like something new that's coming out I'm not like Shilling that or anything I'm not with optimism but but uh is EV a gamer Financial simulation it's a somebody once described it to me I think as like uh like spreadsheet simulator I know there's a lot of spreadsheets involved but anyways I digress um yeah just like a a use case on a rollup that is not a gimmick and that is not Financial that is not just Financial right so when we look at these root use cases we also need to look at the amount of usage you're going to put on the Chain um like I think uh property ownership and like nfts um for f digital things I think it have huge value but you know like real estate doesn't change hands five times a second like some of these financially traded assets are so we can't just judge the use cases by how many transactions they land because a lot of the a lot of these use cases will literally use as many transactions as you can create for them as a competitive Advantage they don't change hands every 5 Seconds yet yet Eric yeah um to I guess to bring the discussion back to Native or in shrined rups whatever we want to call them are there I'm curious are there lessons we can learn from other ecosystems that have gone down this path and the only one I'm aware of is tasos they're obviously very different but I'm just curious from a technical standpoint from a I guess a bit of a social standpoint too just cuz I think I mean it is implicitly competitive with some of the rollup teams out there I'm just curious if you guys or anyone in the room has explored that I haven't looked at tesos in a very long time but it just came to mind the one I've seen as compared to is Cosmos and atom 2.0 and I'm not in franchised enough in that Community to even know what they're talking about so I would love someone to fill in the blanks same I feel like in Cosmos it's not quite the same idea and feel free for anyone in that ecosystem to come up and share but to me my understanding is that there is kind of some apis for communicating amongst chains but it's not you know an OP code that says deploy a new rollup to this slot and the rollup has to look in a certain way and maybe that's not what we're talking about we're talking about Native or in Shrine but to me most of my experience comes from thinking about what thinking about the world for phase two of ethereum back in days when we talked about ethereum 2.0 phase zero phase one phase two thinking a lot about Native execution for ethereum and having these like 1024 enshrined ethereum one execution environments and in those cases like we call this kind of like homogeneous sharding having the same sort of execution environment spread across many different shards and I think that in general having taking these types of approaches creates a very very difficult coordination problem that is has been kind of nicely solved via the rollup Centric road map you sort of let the market go and decide how to build the best rollups you give them the opportunity to do things where they have different security models because not everything necessarily needs to be private or not NE everything necessarily needs to have like the most robust amount of security and maybe it's possible to do het heterogenous sharding on the L1 but I think that developing a platform like that is quite ways away and at that point I have to ask like what what what is the thing that the L1 doing that what becomes possible if the L1 does this versus doing it within a smart contract I tend to think that most of everything that people can come up with that the L1 could provide I.E very qu very fast cross Shard execution can happen if you just have a an agreement amongst different shards or rollups to live within the same contract the same Bridge contract on mainnet and enforce rules upon all the people in that ecosystem I think you can sort of s see this with the super chain ecosystem developing we're supposedly going to see uh very fast cross super chain transactions or operations um just the previous block and the way that you can do that in an optimistic environment that you can't normally do is that they're sort of all agreeing to move forward and move backwards together and so I think that you can do this without enshrining those types of execution environments on the L1 I think what would excite me more rather than sharding or or rollups is multi-party proposers to have multi parties multiple parties proposing a block and um you know we could grow a potentially larger I mean if we look at some of the Innovation that's coming out of out of these parallel chains um I they think they're exposing some of the natural patterns that we already have kind of liquid sharding shards that are self-organizing already you have a lot of transactions that care about what's going on with Unis swap you have a lot of transactions that care a lot about what's going on with betting markets you have a lot of transactions that are completely uncollected so right there you could have three different proposers provide three non-conflicting sets of State changes and we could combine those and build it in a multi-party system so rather than forcing ourselves into into hard sharding Lanes I think what would be more exciting is to look and see how these these organic shards start forming and how we can facilitate them to be built and grown um through through multiple proposers and Builders yeah you kind of mentioned this at the beginning and I was curious to dig more into it how what types of things would you like to see happen on L1 do you think that these things must happen on L1 how can we facilitate a better separation of those different I mean totally different sets of transacting so when it comes to storage slots we need to have better ways to deal with with collisions within the slots um right now when you look at the way you do your ERC 20s and you send someone 20 bucks you don't say plus 20 and minus 20 you say 10 to 30 and 30 to 10 on two different chains so if there was a way within your transaction to express that as plus 20 or minus 20 um then you could have multiple of those collected across three different multiple Builders and then when you combine them together you can figure out does this violate you know do I have enough money in there do I have 80 bucks to do 60 bucks worth of transactions and then it doesn't care which one of the three shards come in and what the final order that comes in and it doesn't matter who gets 20 40 and 60 in their reads all that matters is they have the 20 there so whatever we can do to reduce these collisions and these contentions among the resources increases the ability to have you know this this this Nirvana world of of every every every person who runs a proposer could propose who runs a node could have one tiny proposal in each node comes in gets combined and it works or it doesn't and that's you know that's kind of where the fuzzy math comes in is it works or it doesn't but I think that's kind of the future I want to see towards is is not where there's one shared proposer every round it's where everybody proposes and there's one person whose task is to is to bring these proposals together without executing so it's kind of a half step towards where we're at right now where one person executes all the transactions the transactions have been executed and they just combine the results and make sure they're all compatible did you have something to add oh yeah to back up about the heterogeneity thing one of my concerns about uh L1 and just sort of um if it as it offies if we push everything to L2 is just that it'll start to fragment I think the diversity of l2s is great but we're already seeing um as you like there's different some of these l2s have they compile down to different op codes and it becomes harder and harder to reason about what the evm is and I think as they diversify one of the nice things about one of the great things about ethereum is how standard the evm is but if it starts to just get implemented with all kinds of different features everywhere it becomes really hard to build for all of that you kind of have to Target one of them or another and I think we'll lose a lot of the unity that we as an ecosystem have so uh I think that might be a coordination but I think rips is part of this but um it does seem like there's there's a an incentive for all these l2s to sort of just drive uh separately from the pack and differentiate themselves and I think that that does run a risk and so I think if we fragment too much you to your question earlier that that would be kind of a a failure case if we have to look too far down the road right uh this being said the fragmentation like if you think for example uh of having multiple osses right you you run something on uh on Linux it doesn't work on Mac right of the Box um now that's that's where proving execution really really rocks because you don't need to really call the library for example you just need to know that someone called a library for you did what they were that they they were supposed to and you know it's correct right you don't need to speak the same language which is amazing when you think about it you just need to know that at least yeah what they did what they were supposed to do and the result that you're being given is correct um I think you know there's a lot to explore in that uh I mean that doesn't invalidate what what you're saying clearly but I think like this pattern is going to prove very very uh very very powerful and uh hopefully uh you know like the problem disappears entirely I can't be sure right now but it would be uh it would be pretty amazing I agree and I would say that we should work on better tooling uh and be able to easier modify the for example C compiler uh without actually forking the Soul C uh and uh like doing some modifications be able to add your own op codes be able to add your uh own optimization or whatever for your uh rollup use case and then as was said uh you are able to prove it on L1 without even knowing that um you have some differences so I think um I actually saw rollups as a way to innovate and uh people started to stick to evm on L1 uh the implementation St uh that makes sense today and I hope it will not be the case in the future uh this a something that we do in Red basically R SDK allows you to extend the the main client with your like extensions be that new you can even like change execution if you need but that kind of future can be very like composable you can add your changes and still be uh still depend on the core implementation that follow the main main and basically it allows you to be to stay on the topic of the newer changes getting Implement on the ethereum I think it's inevitable for the l2s to innovate to add their own things if you have just copies from like the same thing it it will die out it doesn't make sense and I think Evolution and improvements are going to happen but we like it or not we just need for us is to enable that transition and for them to make it easier to do those stuff you guys want to talk about the beam chain real [Laughter] quick I've been looking at this question for the last 45 minutes uh who wants to take the first stab at how does the beam proposal play these ideal Futures is beam the Right Way Forward um full disclosure I am currently helping some beam chain project to see uh like the feasibility of it um it's an interesting idea um which is actually the worst thing you can say about something it's um no no no I I like the idea that you know we we have a governance problem with um with etherum it's not a problem but um maybe you know like uh erasing everything and starting over from learning I I used to have a mentor in programming that used to say every good piece of code has been Rewritten three times um I think at least the the intent is pretty good um I think also the I mean the spec is still developing we don't quite know what's going to land in there but I think the the effort has Merit and I also know uh that it will not be like it looks very ambitious but so did is 2.0 right we were supposed to have shards we were supposed to have multiple execution engines we we got none of that at least so far um we will get a much like more palatable maybe but also a much more a much simpler version of beam chain so I think it's a worthy effort um I don't know what will come out of it but basically currently it's me wasting my time so um yeah I think it's worth trying can I give it to ldr what is beam chain today what's the proposal uh so the beam chain I mean today uh the beam chain is absolutely nothing it's just an idea uh but hopefully with an interesting idea string idea in the next in the next 6 months hope hopefully it will be a complete spec or at least a good enough spec um and it's about doing the merge again um like we yeah I'm selling it really I might not um it's um the idea is to say well we did this uh we did this amazing thing with the merge we we ripped the consensus engine out of ethereum and we replaced it with a new one and we had a lot of ideas and some of them were really good and some of them were not so good um some of them were you know mistakes in retrospect like for example using BLS because BLS is not Quantum secure um we thought we had a lot more time to do this maybe we don't um we want to redesign everything that uh in a way that has inclusion list um like basically censorship resistance we want to build with Quantum security we want to change the like we did for example uh this um this finality that comes you know much later than the than the confirmation happens or at least that the that like that is way behind the head of the chain turns out we don't really need all that uh so it's a fresh it's a fresh start so it's okay think of it it's a bit uh it's a bit like it's a very bold statement but think of it as we're going to get rid of the beacon chain and we're repl it's we're going to replace it with something that we you know know that has the benefits of how everything we learn on the on the beam chain on the sorry the beacom chain would you say the merge was a research project as far as I'm concerned it was cuz uh you know we we we uh yeah it I mean it was very much a researcher project in the sense that they had this big uh to-do list and then uh Mikel Kini and Danny Ryan and I we we came together and how how do we make this happen like we had to change sorry push to production it was a push to production exactly um exactly it was it was a very uh ambitious research project and we we pushed it to production um and um no it was a good thing cuz you know like I keep saying done is better than perfect but when perfect becomes a reality as well uh we should look into it and try to make it happen and of course it's never perfect but uh I think uh we should keep improving so this is going to scare some people but do you think the beam chain is going to be the final form or will there be another revision of course there will be another revision yes based on my experience at Google I mean that's how they kept everything uh top level is they'd have someone write it it'd be awesome and they'd hire new people um they would maintain it and when you maintain it the only way you maintain is your best maintaining code you've written so they would rewrite it so whole portions of Google are re written on average every 2 to 3 years just because that's how long people tend to stay in their jobs um and the upside is when it's Rewritten every two to three years you know exactly how to fix it when things go bad and exactly what's wrong and exactly what to inform the next level the downside is there's like this MIM where it's like one road is like shut down and closed deprecated and the other one's under construction and it says not ready yet and like these are your two choices when you build something at at Google for what what you get to use and I hope we don't hit that sign of of a future um in ethereum um yeah at least currently I mean okay I I don't want to ask question uh ask people when they intend to retire but I I see myself staying longer in this position than just two years so that's the at least I'm projecting on other people but I think we we have a lot more stability in this respect uh but yeah it can be it can become hell absolutely um at the same time um yeah we we still need to find a way to evolve and the problem is we've been pushing it's it's really a governance like trying to address a decentralized governance problem um instead of you know making little changes that are going to take forever because and mind you this is not an excuse for not being able to do to be better at delivering incremental changes but the reality is ethereum has become more and more conservative in a way and um maybe not in spirit but de facto and uh we need to to be able to do a big leap again um we haven't been doing this since okay I I would contend we haven't done that since the merge we some people would say the blobs I I guess it's also a big change but um yeah like it's really how do it's a social thing and I think the beam chain has this um the Merit of at least trying to deliver a big change again I think we didn't have still like the clear answer and I get it that it's fine uh what has been chained today there is a question about ZK uh proof verification side car in the future in the beam chain I think that's like a big part of the plan of the beam chain right to have some sort of a uh ZK uh uh State transition function that you can verify and uh it has a dependency on the E uh to also have a zkm so this is like the big part of it and we can say that the beam chain is about ZK for example what you said also seem to be like beam chain about single slow finality or faster finality right yeah much faster um yeah so when I said we're probably not going to get the entire product uh right now this is exactly what I've thinking like ZK has so much Innovation right now that I think it's too early to jump uh so that's why when I saw the presentation I'm like yeah this is coming later and there might like Dan who said there will be a there will be another chain that that will do this uh but it's possible it it would be yeah and um and when you talk about the the the faster finality um yeah it would actually be nice to have because this is this is a great usability uh change and I think we're getting this one like there's been a lot of uh work done on this by uh by Franchesco for example from the research team at thef um this one seems way more realistic to me than uh and I can be wrong right I I'm just exploring right now and there is a think a bit uh question about Unstoppable transactions and it's about sensorship resistance I think uh and that the beam chain um as far as I know um does not have a proposal for like uh censorship resistance and we can do it actually faster we have fossil for example that can be shipped before be beam chain so not in uh 5 years uh hopefully right so that's a very good point uh the risk with the beam chain is that yeah people will say okay this is too complex so we're going to ship it with the beam chain of course the beam chain I mean just like East 2.0 this is exactly what happened with East 2.0 and why we needed to make it happen people where um yeah okay but you know like we have proof of work is working we have so many problems to solve this will happen after East 2.0 and in some respects it did but um but it also became an excuse and uh that's why I think my role and I think it should not just be my role it's going to be a lot of people uh hopefully in the community everybody should look at the beam chain and say okay this is nice but we need to we need to ship basically and yeah shipping fossil uh before the beam chain would be awesome uh I'm just yeah just be aware it's going to happen people are going to say too complex let's do it during the beam chain we have to fight that yeah I think that's probably my number one concern is the the there there's sort of two classes of big projects in ethereum there's things that we sort of know how to do and that it's difficult to do given the Legacy environment that we live in and then there's things that we don't exactly know how to do things that we have ideas to work towards but we wouldn't say they're like production ready we haven't seen them anywhere before and I think that beam the beam chain contains both of those topics and the things that I worry about are the things that we like don't know how to do yet and I think fossil is close to something that we know how to do but it's not really been implemented and so it's still in this idea and it's a very well fleshed out idea compared to some maybe other things like I don't know 4 second block times but it's not like address space extension where I think we have pretty good idea of how you make address space extension you just extend the value the number of bytes in the address by 12 it's just extremely difficult to do when the airplane is in the air and I think I would like to see more things on the beam chain fixing the stuff that we just can't fix easily in the current chain post Quantum I think is probably a more compelling one it's going to be very difficult to just Swap all of the cryptography out of the current chain and replace it but some of the things like like fossil is the main one that's coming to mind it's like okay you know you try to bundle all this stuff together we just don't the reason it takes a long time to iter iteratively ship things is it because it takes a long time to take something from yeah we kind of know how to do it to this is safe to ship onto a multi-billion dollar Network and I think that just bundling a bunch of that stuff together doesn't like we still have to do the work you know maybe we can create a strong shelling point for everyone but we still have to do the work make sure it's safe we're not going to ship the beam chain if we're not equally confident in it as we are to a regular hard Fork on ethereum right and just pressing the point the first thing I said about the beam chain at the moment it's nothing it's just an idea uh yeah like totally agreed um to move discussion more to execution yeah uh consensus layer on its own it it could have like a lot of improvements muscle finality uh like lower time time time between the blocks but for the execution I would like to list the things that are in execution that we can improve one of them is uh transection broadcasting how broadcast transection second thing is execution as the evm how to improve for the users evm in general uh third thing is the state proofs basically merket Tre veret Tre or something else and those are basically the and fourth one is the state how what basically we now have like a count storage should that involve something else we're talking about end game now I think the two pads that we need to basically at least in my mind that we should think about is basically ux on various fields and performance performance is basically how many transaction that we can execute those are the question or that execution layer needs to solve ux is mostly um there are even two parts there it's like the ux of the the the user that trans the node I want to run it to my phone for example and I I need to verify the section on my phone and ux ask in different sense how is it for me is to Center section that does the things that ask ask for example I have P 7702 is Small Change on in in in basically in how the impactful it is going to be it's like massive and I think the improvements in execution lay is most be hey what's the next reection that are going to have the same or bigger impact than s02 I don't know I'm just like asking Community yeah I I mean I definitely agree that we need to find these targeted changes that are going to have a broad impact and I think that further something we should look at is figuring out how to stem the proliferation of pre-compiled because I mean so we see the the BLS 12381 promiles are being introduced in the next hard Fork but we've been debating these for for five currently five years five years was it 29 19 I don't remember seven um proposal from 2020 right and at the end of the day like uh if you provide optimized modular arithmetic you can in G CVM you can get within 2x the cost of the BLS pre- compiles in both performance and gas well F time right sure yeah um so yeah I mean um yeah targeted improvements to the evm oh uh and something else uh so like if we look at the explosion of complexity in um uh on the cryptographic side of like all these new Stark Stark schemes coming out all these various flavors of algebraic hash functions it's a nightmare to try and coales around new pre- compiles and uh yeah we need to find a way to allow users to implement pre to implement contracts with pre-compile close to pre-compile Performance and cost I feel that the the framing user made precompile is very powerful in general I think we for the laes for something like that we will still need to have some kind of precompilers additionally to the evx but in general evx could uh unlock some things to the users the question is how how many New cryptographic Primitives do we need inside the evm not just should we just be fine with adding new pre compil that we need or enabling users to make their owns about a big unlock that's maybe not about L1 but about evm um EF allows you to have custom bite code format for example you can have not TVM by code but some other um B code like Risk 5 or wasm and that would be amazing if we ship euf because as we know today l2s depend on L1 uh making a change so we expect l2s also have EF and they can experiment with for example uh risk V uh for example there's a project by Leo r55 uh where you compile your rust smart contract into uh risk 5 and you executed lots of questions how to do the gas metering how to do it properly uh but I think it can be a big unlock for new uh ux for new developers to come and try uh play with ethereum was that a stabit answer in the first question yeah yeah um yeah that's uh that that's a good start I mean I you know there's it's not just rust uh I mean we we have rust CN here which is we love rust yeah oh really um but like the the fact it's a more General uh uh architecture although you know RIS 5 is unfor unfortunately uh from a user point of view a a whole bunch of AR architectures that are somewhat related um but even um even if you look at like higher maybe more like heavier programming languages like go or uh or I mean you could just compile cross compile the the python interpreter and run oh my God yeah yeah I mean it will happen know just be prepared it will happen python smart contracts python smart contracts um but yeah like ignasio and I we we love Zig for example it's also pretty it's also pretty good in this in this respect um and um yeah so that I'm looking forward to that uh the other big uh unlock I want I mean it's not it's not going to be a surprise for anybody but I want statelessness um there are so many uh so many things that will be possible uh just being able to exchange proofs among like small proofs uh among many many actors uh this is something I mean I don't even know what's going to happen but like this has the potential to be really game-changing it's going to be a a whole new new ethereum um I as another thing I want that should be the tagline that should be the tag stateless a whole new ethereum a whole new ethereum absolutely and can we get like The Aladdin theme s Go With It whole new ethereum anyway um so I do think that the changes coming in vertical for statelessness are essential for for the isolation that we're going to need but I think embedded in there is one tiny little thing that might be also unlocking optionality is we have account versioning there's a version of an account so other chains can do crazy things like they could have account version number 100 which uses utxos instead of storage slots and they could unlock things optionally and clearly signify that in their state and if you don't understand it well go use the client that supports it and that makes it clear in the state as you're executing it what's going on and I think that's the key to optionality is having places and hooks to say I'm doing something different and Main's going to see that I'm doing something different and refuse to execute this contract refuse to do this thing because that's not what mainnet does that's what your favorite rollup does and that's how they differentiate yeah I mean I think that is a cool aspect I we're starting to actually see L1 use that special domain and not quite in the way that you just describ but like with 7702 we're sort of reusing the EF bite this is something that just wasn't possible before a simple EIP that said you cannot deploy code that starts with BF so who knows what other types of um interactions we're going to be able to build with that super simple primitive on the L1 um back to this question I did have kind of a follow-up question what people think about this as something that could be a change that could unlock a lot of other changes one thing that we talk about on the execution layer a lot is we talk about Legacy and we talk about backwards compatibility and I'm curious what what would you need to see to say it might be okay to De enshrine the current execution environment like today we sort of have made a commitment to the evm to the eth1 evm as people call it is this something that we should carry on forever for the next 10 years the next 50 years should we have that expectation that contracts on the L1 will always be coupled tightly with the the consensus of the protocol or is it something that we might be able to delete transpile to a new world change the costs change the frequency how do you guys think about the enshrining so current eum uh I think if we can take a parallel from what happened with self-destruct where when we tried to remove self-destruct there were a number of contracts that were broken in a vocal user base that uh brought out the Torches and pitchforks um to understandably complain that their contracts were being broken and we were breaking our social con social contract isn't it just Casino what isn't it just a casino contract casin Casino yeah but like still like people were going to lose money as a result and we had to I mean in the end we ended up we ended up coming with coming up with a compromise that worked but I think that the transpilation of evm to eof seems like a much thornier thing and it I I I I feel like to to to to do it properly we have to force it through and tell people that look if you if you don't upgrade in such amount of time this will become deprecated and not work and the Fallout of that will be people getting mad I feel like there's a bit of a spectrum here though it's not necessarily saying that one day we just turn off the Legacy evm like I think it's a design space that hasn't been explored a whole lot but you could imagine I mean as an idea I thought of the other day like what if the eth1 Legacy VM only docks with the consensus layer once Epoch you you know we are able to transpile a lot of contracts to a new execution environment there's not a lot of operations that are still happening in this Legacy environment maybe we can push the new environment to be much more performant and say you know if you're still using this Legacy world the trans the throughput of the transaction is going to be much much less and then we rewrite the old stuff in Python and we run it into an emulation on this environment and then it end up being the exact same amount of performance as we had before exactly nothing breaks I think in general it will depend on on when the analysis starts if 99% of the contract can be transpired to EF amazing I'm not sure if that future is possible even it's like 19 percentage it would be big like move from moving for legacy to the UF but that will depend when the analysis starts and when we see the numbers when we see the possibilities problems are around it so uh just uh F I don't know if you're aware when you must be aware uh when um when we had this debate about veral vs e u i was like if you can compile because there's this big transition right in verle if we can at the same time compile e sorry Legacy into e that would be amazing and then I would be I would say UF has to go first um and um they looked into it didn't didn't come up with something that was very satisfying but if we can like I'm still I'm still saying that if we can make this happen then we need to make it happen so because of some of the things that we're Banning we can't we're getting rid of gas introspection and we're getting rid of code introspection and there are absolutely contracts that that very much depend on that another thing we're trying to get rid of is uh polymorphic addresses that can change your code where we've mostly broken it by the way we've ner self-destruct but we haven't completely broken it um I think a more realistic plan of what's going to happen going forward is we won't be able to ban and and rewrite all old Legacy op codes we'll be able to validate what's going on with the old contracts and ones that behave well like they always do a push before their jump um we can we can you know make it we can do sidecar analyses for those and have the ZK systems work fine for those but the the contracts that do the real nasty and ugly things like jumping from call data values into a destination within their contract um we let them do it we just charge them through the nose for it does anyone do that yes someone actually said this needs to be preserved eof and luckily we had the jumpy operation and the answer was you don't compile your code and figure out where your addresses are you just use Simple numbers like 1 2 three and four and that that solved most of their problem it's not just like transitioning for the Legacy to the UF is transitioning the logic and the problem is as the then yeah said is basically some functionality was were remove it by Design and we want them removed yeah I guess maybe at a bit of a higher level we have a social contract to continue running making sure that code is executing and both the op codes and the like higher level htics the way the system is designed and I'm just curious is that a contract that's breakable is that something that people up here people in the in the um audience is it something that we feel like this is an important social contract of ethereum that the people who are deploying to the evm to day we're going to make a promise it's always going to work or is there a world where we say you know what we're going to Sunset everything on EV uh eth1 evm in 10 years so think about that start migrating but don't deploy a contract that's going to unlock in 100 years I feel that the it depends on the cost if you're breaking something that's worth millions then it's not worth it if we're breaking like the the troll contract that's made because to make our lives like harder then that's fine it will depend on the cost and for the to figure out the cost we need some kind of analysis to say hey if you do this uh this kind of contract is going to like break not work and they will lose like Millions that's not something that you want to do but what if the troll is the third largest nft exchange I mean one thing when it comes to breaking social contracts we tried this when we talked about State expiry and I think it drove Alexi crazy was he's trying to analyze it so I mean if we're going to ask someone to to do the design for breaking social contracts we need to make sure that um they're willing to be a par if necessary um speaking of social contract yeah like you know we we had to tell like the blockchain was always you know meant to be like touted as a immutable layer um and then ethereum at D so we're especially you know under scrutiny for this because D we we made an for to go and modify the the state um the exception that proves the rule yeah yeah but sure but now we yeah we need to make sure this is the rule right um because otherwise I mean yeah like we we're building I mean uh I hope we're all building for you know 50 years from now 100 years from now we we don't know what the problems will be then but I think there should be a guiding principle that we should not touch the state and so if something was working the promise should still be that yeah it needs to to keep working basically and I think some options for don't touch the state is maybe we could go with that original Serenity proposal and have a layer one rollup that spins off and only only posts blocks once an hour wow um yeah maybe we should go in Rapid Fire and try to answer the question I was just thinking of doing that uh first up we have I think we have Unstoppable blocks I want to see Unstoppable transactions that also kind of plugs into the one below it seems like people want to talk about privacy does anyone want to comment on how privacy interacts with the uh can the person expand what uh does it mean unstable transactions so it's not necessarily censorship resistance it's more about how you propagate transactions the problem is at the moment you have an incentive to propagate headers and it sort of makes sense but nodes don't really have a an incentive to propagate transactions and the person building the block could decide to to censor transactions so you know if you run even if you run your own node you submit the transaction to your node there's no uh no real reason for that transaction to be propagated through the network I'm sorry I was sorry had to ask you something um do you mind saying it quickly very so very quickly how do you incentivize people to propagate transactions uh I think this is a super tricky problem that's why we build the transaction pool in a way that it's relatively light to run and we sort of enforce it for everyone to run by default I think yeah I think defaults are powerful and moving into a world where we start letting people easily turn off the transaction pool is going to create an environment where it's going to be difficult to incentivize people to run it I don't see any any innate uh incentive to do this it's kind of like providing a nice free facility to bounce your transaction around the world to eventually get it to a builder so I think that as we change the behavior of the transaction pool we need to be very cognizant that the people who are running these nodes it's like an alistic thing maybe this a longer term future is like there are different designs of transaction pools like maybe with the DHT type of network where we don't have to quite have the same number of people running it to have very quick propagation and the people who care can listen widely and the people who don't care can listen very shallowly but it's not something that's been looked a lot into um there's something called uh rainbow staking that people are looking into um we could add you know the idea is to like to break the the reward system into several aspects of doing the network we could have uh I mean this is basically what inclusions Leist do actually you could force people you could re also reward people to include like you know pick transactions at random and say if this one is there then you get a reward if it's not no it's beyond inclusion list because there's a chance that you've never seen the transaction so if you're building an inclusion list and it hasn't got to that uh validator who's building that list it hasn't got there um so you know the topic of the discussion was what do we want to see in 5 10 years time I want to see Unstoppable transactions I want to be able to submit a transaction to the network and it not get blocked from propagation not get blocked from being built I think solution for that is to have blind transactions basically you have blind transaction somebody's paying for the maximum gas that it doesn't matter who and you basically um expose that transaction when it is included inside the blockchain and then you're basically having you nobody knows who what does what does that transaction do and you can like trigger that execution afterwards any closing comments from anyone up here or sitting down about ingame execution for me for execution is most like improving ux how what's the next transaction or transaction type whatever it is that's going to improve the usage of ethereum under that is performance that's the that we already working on gagas but in general ux is the part that's not that explored and I think it's a little bit lacking great sorry I think that we're at time now but thanks a lot for joining us everybody thanks a lot you guys for coming and having this conversation uh hopefully people will find this useful to think about what the endgame could possibly look like rather than what the next one year looks like