'What Happens After the Merge' - Vitalik Buterin

thank you so much thank you for having me with that we are ready for our final talk of the day uh i am super excited to be welcoming our next speaker and uh in in anticipation of this last talk we've seen a a really big uh surge in the number of live audience viewers so to anybody who's joining in um just want to remind everybody that uh this is a live chat and a live conversation so if you have any questions for our next speaker you can ask them out in in the chat and we'll relate them to uh to vitalik after the talk finishes so if you're tuning in right now be sure to log in say hi and ask any questions and we'll be able to relate those questions directly to our speakers so that's it i am super excited to welcome our next speaker the next speaker is vitalik buterin uh italic is going to be talking about what happens after the merge we've been on a long road from e1 to e2 but let's talk about what's next welcome italic uh thank you cardiac i'm gary are you hearing me okay everything is great okay great um then i am going to just turn on my slides and we'll get straight into talking about fun stuff um okay share um okay what's the second word happens okay and what's the second what's the second word now we've excellent okay um no no no thank you very much for doing the czech kartik um right here [Music] all right so i guess uh i'll just uh start talking um so so so far we've had a lot of excellent presentations about the process of the merge about all sorts of things um kind of having to do with the barge around the marge um and but uh today or right now i wanted to uh kind of finished off by going a bit into the far future uh so where is uh ethereum going from a technical perspective after the merge um so this is the kind of quick diagram of the roadmap that we know so far right so we have the execution layer currently it's a proof of work chain um but the uh proof of work part is going to be removed at some point fairly soon and then we also have the proof of stake in status lawyer which also exists as of december uh the berlin hard fork already happened uh the genesis of the proof of stake side already happened uh so next up we have the altair hard fork on the proof of stake side and the london hard fork on the um execution side that's going to introduce our beloved 1559 and then after that there's a possibility of a feature fork maybe a bit before uh with like one eip either before the merge or after the merge the um core devs calls are still discussing this but much smaller than like say yeah if 1559 for example but the next big thing is just the merge itself right and the merge is this kind of big topic but then there is the question of well what happens after the merge right so after the merge basically the execution layer is no longer an independent chain the execution layer is a thing that lives inside of the chain and the chain is run by the proof of state consensus lawyer uh so once that's done uh and uh proof of work is uh behind us where do we go from an ethereum consensus layer point of view uh from there uh so um first of the first uh big thing that will need to have is a post merge cleanup fork right uh so basically the idea here is that we've rearranged uh the road map so that the merge is done in this very minimalistic and uh simple way uh where as you basically um just kind of take the existing proof of work change strip out the proof of work and then just make it live as a chain inside a chain um inside of the proof station but it's like a very no frills merge right so like for example the eth1 voting data mechanism continues to exist even though the chain is basically just voting on the chain which is completely stupid because while the chain knows the history of the chain right um withdrawals are also not enabled there's also this kind of awkward mix of rlp and ssd there's a lot of kind of format issues there's uh theoretically the ability to read the execution chain but you don't have any op codes that can actually take advantage of that so the first post post-merge cleanup fork is this a fork that's uh expected to happen very soon after the merge that just fixes all of those issues right uh so some um kind of top uh priority items that could happen around here one of them is to remove the eth1 data voting mechanism so the if1 data voting mechanism is how currently the eth2 chain or the beacon chain is aware of the proof-of-work chain and it has to be aware of the proof of work chains and process deposits but we're not going to need this because the execution layer will just be able to read the consensus layer that it's living in uh inside or so the consensus lawyer will be able to read the execution layer that's living inside it directly right um so that simplifies the protocol a bit and it removes an honest majority assumption which is good um adding withdrawals so withdrawals will not be available immediately after the merge but they will be available um after the cleanup fork and that's just like a simple mechanism just need to figure out exactly the way to proce to uh process withdrawals um but not very technically hard potentially fully moving um actually this should not be the application chain that's um outdated terminology it's uh not politically correct as of april sorry guys um but fully move the execution chain to um sse so rlp and ssd are these serialization formats uh the existing ethereum execution chain runs on rlp the beacon chain runs on ssd and ssd is like in my opinion as the inventor of rlp rlp is kind of trash and s is that is better um so it's just more convenient it has these really nice properties in that you can prove merkle paths going into ssd objects that are inside of ssd objects very easily um it doesn't require any kind of weird dynamic positioning for most things so it has these nice properties and um the way that the merge will work is basically that the execution block that is embedded inside of a beacon block is going to have transactions and those transactions will just be blobs right and they'll still be rlp now you can't change them immediately because the format of the transaction really matters because the the thing that is signed in the transaction signature is a serialization of the transaction and so if you change the serialization like unless you add some awkward backwards compatibility layer you like it just that sort of like def reformats the transaction when you're checking the signature like it's just you know you just want to have a new transaction format and that's something that that what needs to be added later right and this would be a good opportunity to kind of clean up transaction formats a bit add something that supports access lists um supports uh the chain id in a very kind of nice and native way uh supports uh you know eip two nine two nine stuff uh potentially supports uh account abstraction related stuff just supports everything that we know uh transaction formats need to contain um and eventually all of the previous transaction formats can be retired beacon state access opcodes so opcodes to access the state of the beacon chain is also something that's important so they they're basically yeah um things like uh the randolph code to um or potentially remapping an existing op code to randow so you can access the random value inside of the chain and that can be used by applications for on-chain randomness also the beacon block has a root op code so a block hash op code that actually points to a beacon block and this is nice because it allows the chain to be aware or it allows apple things in the execution layer and applications to be aware of what's happening in the consensus layer it also allows them to be aware of history you can prove history more easily and its importance for when we add sharding because you have to prove that some shard data blob uh actually got included uh so and then the last thing is this is a kind of somewhat controversial thing of um agree that that we need to agree uh that the uh client at some point but hopefully clients just stop trying to download the pre-merge proof of work chain right so at some point like i think it's a good idea to break the invariance that the base ethereum protocol is responsible for trying to or for giving you the entire history all the way back to genesis and the first simple step to that is to just like at some point agree that we stop uh kind of providing the proof of work chain before the merge as part of the protocol and if you want that stuff then um you know you can go to the graph or you can go to some other uh protocol that someone comes up with right and it'll always be possible to access history but it would just kind of stop being the responsibility of the youth protocol that's mandatory for uh consensus nodes um so then right uh now apologize again for calling it the application chain in my writing it's the act it's called the execution chain now um so that's the first big thing right it's not very kind of featureful not very sexy but you know cleanup has to be done um and like it is sort of the technical debt that has to be paid um once uh this uh accelerated merge is finished and the reward is that you know the merge can come half a year earlier and uh the ecosystem can save like potentially many billions of dollars in resources from just moving over to proof of stake more quickly so after that uh sharding right so for those of us um who have been around in the ethereum ecosystem a bit longer you'll probably remember that the original plan was actually to do sharding before the march but now because we're prioritizing the merge we wants to do um sharding after the merge right and the um so of course it'll be developed in parallel um but uh it'll likely actually be implemented and turned on at some point after the merge is done um just so we have a bit of separation and we we can kind of we don't have we don't want to do all of the potentially dangerous things at the exact same time you want to do first one and then the and then the other so that developers can kind of pay attention and focus um so sharding is as we've been talking about for a year starts off as being just data sharding so no execution on charts instead the shards are blobs of data and the reason we care about having blobs of data is uh so that those blobs of data can be used by roll-ups right so 64 data shards on each chart targeting i think an average of uh i forget if it's an average of the max but like either 250 an average of either 256 or 512 kilobytes um you know in a shard block per 12 seconds um and then the security of the charted block uh shard blocks will start off being committee based so just a randomly selected committee will vote on it and if it signs off it's accepted but then over time we'll add higher levels of security with uh things like proof of custody and through this big thing uh called that data availability sampling and at some point we also wants to uh or potentially even immediately um have staggered shard blocks uh so you don't want every sh the block of every shard to come at the same time during a slot you want say yeah shards one to ten to come early in a slot charge eleven it's wanted to come later as well and then charlotte's like 60 to 63 to come near the very end of a swat and have some way of some incentive mechanism to ensure this actually happens and so roll ups that are willing to kind of walk between multiple shorts will basically be able to just like keep on using these new roll blocks immediately as soon as they come and they'll be able to have the walk times that are much faster than the 12 second uh kind of tick time of the beacon chain itself right so this is kind of currently the most promising potential strategy for basically making the eth2 system and roll-ups on top of youth to kind of have uh initial confirmation times that are competitive with more centralized chains basically um without actually incurring the risks of being centralized um data availability sampling so this is this really important security technology for um sharding where basically the goal is to have clients verify data availability guarantees in this probabilistic way and the goal of this is to allow clients to detect data availability failures or reject blocked shard blocks that are not available even if the major honest majority assumption for committees is broken right so this sort of preserves the property that we're used to with ethereum as it is today and with bitcoin as it is today that basically says even if there is a 51 attacker they can do they could they can revert the chain but they can't like force you to accept invalid uh or unavailable junk right and in a shorted system we want to maintain this invariant but obviously without requiring every clients to personally download and check everything and state availability sampling is this lovely and wonderful technology for actually doing that and so every block gets redundantly encoded with polynomial commitments um and the idea is that if you have any 50 50 of the block so the block let's say gets split into a thousand pieces um if you have any 500 of those pieces you can recover those other 500 right because let's say yeah i'm going to degree 500 polynomials so if you evaluate it at some points you can extract the polynomial then you evaluate it at all the other points um if he wants to know more of the fancy math like this has been written about in some the i think even the post on a dis on notes.ethereum.org that actually contains this picture um and then once you have this mechanism where you only need half a block to be available for the entire block to be available you can randomly sample to check that enough of the blog probably actually is there um so a lot of work has gone into this a lot of thinking has already gone into some kind of starting some prototypes i'm coming up with optimized algorithms for polynomial commitments thinking through the chart or the peer-to-peer network design but it is still lower priority than just the merge and charting because we do recognize the kind of urgent need for security or sort for scalability and they need to just uh get users we get some kind of scalability in the hands of users first and then kind of push up the robustness of this of the system second um now i mean the system still is fairly robust even without data availability sampling right it just relies on an honest majority assumption and data availability sampling basically removes the honest majority assumption at least for uh for sharded data and then more security improvements right so these are things that justin really loves um single secret leader election so basically ensuring that the proposers of the net of upcoming beacon blocks and possibly shard blocks are not publicly visible anymore and that mitigates dos issues it may get collusion risks it basically kind of replicates many of the benefits of kind of the way proof of work works where uh block publication is more anonymous in a proof of stake context uh vdf's verifiable delay functions uh so these once again justin has talked about these a lot and basically verifiable ran a kind of more very secure randomness for choosing committees so committees become more difficult to attack which in practice means that the security of the system goes up from or your bill you can rely on the committee uh like before vdfs if say more than uh 70 of uh nodes are honest but with a vdf that requirement might go down to i don't know somewhere around like 57 maybe 60 percent and then uh proof of uh custody is basically just a further mechanic that forces nodes to actually download keep and validate block data that's basically a kind of anti centralization measure um so those are some kind of short term uh consensus layer focused things well i shouldn't say short term because it's after the merge but some medium term consensus all your focused things that i expect that um will be a the major focus uh after the merge and these are all ideas that we've been working on for quite some time right uh so for a lot of them there's like basically a complete a kind of proto spec that's just been sitting around uh and at some point he just needs to turn the products back into a full spec and then turn it into an implementation execution layer improvements uh so execute the execution layer does have some needs to continue evolving um so one is address extension um so this is a small thing but it's probably important for the long term basically increase the length of addresses from 20 bytes to 32 bytes and this is an important security improvement um 20 bytes is not is in the long term not safe for collision resistance and this gives 26 bytes for collision resistance which actually is safe um add some version numbers for future compatibility and it's needed for state expiry proposals uh which is uh the next thing here uh so basically state assistance date expiry this is a really important thing for the ethereum execution layer post march uh so right now the the main uh thing that is making uh further increases to the gas limit not safe is actually not even um things to do with uh execution it is state size right like in the pro state size is growing by something like 30 gigabytes a year potentially um and then with the recent gas limit increase that'll probably go up to about 35 and then if there's more gasoline increases it'll go up even more and there's this just permanent ever-growing state and this is really inconvenient because it means that um just sinking to the network for the first time is something that should that would just permanently become more and more inconvenient it also means that um the hard disk space requirements of a full node just keep going up and up and it also actually kind of interacts with the dos issues because the large the larger the state size is and the more amount of data he needs to have on database the more time each individual database read will take and so the more vulnerable the chain becomes to denial of service attacks so state size kind of management is this really important issue and i've talked about and really the ethereum community in general has talked about two big categories of strategy to address this one of them is statelessness and the other estate expiry and so the idea behind statelessness is to basically say well we're going to create two classes of nodes one class of nodes continues to require the state and the other class of nodes um instead does not have to store any state at all um and in order to verify blocks they have a witness that basically provides the portion of the state accessed by a particular transaction plus a cryptographic proof that shows that that the values that are provided are actually correct right so this is a it's also been called stateless clients um and vertical trees which we've been uh talking about a lot and codemoralization which we've been also talking about a lot um it's gonna become code vocalization uh but these are all really um important uh to make the witness sizes actually small enough for this to be viable um eip2929 which happens in berlin also contributed to making statelessness viable because it established a a nice low balance on the number of state accesses that can happen inside a block um it also made my uniswap transactions about one percent cheaper which is interesting um so if you have a dap there's a chance that it got one percent cheaper because and there's a chance he got about it got one percent more expensive but i think a lot of things did um especially more more expensive things did end up getting slightly cheaper which is uh interesting um but basically it was a reworking of gas costs that just ensured that there's this balance on the number of uh storage reads which means that there's about uh a balance on the witness size and so like there isn't a risk that there's gonna be blocks where just the size of a witness is too big to propagate to everyone in time um this is um there is one thing that is still required for uh to kind of finish that task one more gas cost change which is at the same time as code verbalization we we will need to add a gas rule that charges some amount of gas for every chunk of code that gets accessed and i'm just warning the community this is something that is going to cause some medium amount of pain to at least some application developers so i'm hoping that fairly soon we'll have tools that will kind of help um help us understand more like exactly what transactions will have to consume more uh we'll have to consume more gas as a result of this uh but um like this is something that we do needs to kind of keep an eye on and just make sure that it's not a uh that it's not a surprise to people so basically a gas cost of roughly 400 gas for every chunk of 32 bytes in the code that gets accessed that's like the thing the thing that will need to be done so let's tell us this state expiry is a different strategy right state expiry is a strategy that basically says well we are going to have um the state and the um objects that are not touched for a long time um base get kind of pushed out of the state and they get instead become part of the old state and if you have an object that's part of the old state and you want to access it with a transaction then you have to provide a witness and when you provide a witness then that object gets renewed and it gets added to the more recent state um so the idea is basically that the state that clients including mine including miners including fall clients everyone has to store would only be the set of accounts that were accessed roughly within the last year um and older things are just going to be stored by um just archive nodes block explorers the graph like other decentralized projects right and and you'll need to like basically get those witnesses through some other protocol they're not the responsibility of the core ethereum consensus protocol um so important point of clarification if you have an account that has a million of wraps doge and you uh hibernate for two years your rap stories is not going to disappear right like nobody is going to lose money just because they forget what's going to happen is your raps though is just going to become part of the old state and if he wants to do something with your rap stories all you have to do is just go through one of these secondary protocols grab one grab a witness for the state and pay a bit of extra gas to make a transaction that contains a witness and sort of brings the account and the storage slot that contain your wrapped nose balance back into the updated state um this is done using this scheme that basically adds uh kind of creates a new e-book every year and adds a new stage tree every epoch and clients effectively store the more the most recent two state trees um there's a long post i wrote once again you can uh probably go find it and i'm sure somebody will uh uh hopefully provide uh provide a link to it uh but it's the current likely path is to actually do both of these things at the same time so statelessness and state expiry at the same time and it turns out that like this sounds crazy but it's actually easier to do both at the same time than it is to do either just statelessness or just state expiring which is interesting um so big project um it will have it does have quite a quite a bit of complexity but there it has a lot of value and a lot of potential to do some important good for the ethereum ecosystem it really does uh remove what's probably the main impediments to just further increasing the base chain uh capacity right and once this happens it'll also simultaneously become considerably easier to run a full a full node that verifies the ethereum execution layer um so oh excellent uh someone actually uh did did provide some links in the chat um yeah um right uh so let's see if he wants them another another thing by the way is that like i've been talking about this idea of kind of forgetting old data in a couple of contexts ready to talk about forgetting the proof of work and history chain history and i talked about forgetting these um expired states one really nice thing about is that when either the proof of work chain or these um expired states expire they're static objects right and um having a protocol for backing up and retrieving a static object is much easier than doing it for a dynamic object like the state right so for the current state um like developers like piper and you know jason carver and his whole lovely crew over in colorado have just been doing some amazing work in trying to figure out like how mate how to make a good protocol for kind of extracting this and and giving clients this data in real time but it's hard because the state just keeps changing but older states and the report chain history they're just static files right like once they become old they're just fixed things and they never change and that what that means is that you can just like potentially even stick them on bittorrent right you can stick them on one of a whole bunch of archiving solutions and so i actually don't expect like um archiving and extracting from archives and even doing that in a fully uh decentralized way to a to be a problem um right i saw a two maybe dumb questions from nn uh when will the merge go live for the public i mean like from what i've optimists are saying before the end of the year pessimists are saying after the end of the year um but uh i mean it's i think uh we don't want to give kind of good uh like really precise numbers especially until the whole ranism thing ends um and uh this and we kind of have our learnings from that if everything is open source how does the team protect other from other groups just copying everything and building their own centralized business um i mean if other people wants to fork ethereum and make a centralized version they're perfectly free to they yeah that's actually happened multiple times already i'm not worried like i think that the ethereum ecosystems are kind of main value proposition is the decentralization and the ecosystem and the public legitimacy that comes with the ecosystem yeah the technology is important but the technology like the role of the technology is just to be uh to be good enough to actually make sure that people are able to do all of these things that they're um that they wants to do right like if someone comes up with uh copies the technology and then builds five percent better technology you know it's not like everyone's just gonna move to them um okay so some more execution layer things account abstraction uh so this is like one of my personal big favorite kind of pet projects um of course uh so basically um moving away from requiring every transaction to start in an ecdsa wallet or sorry in an externally owned account which runs on ecdsa and allowing transactions to start by just being calls to contracts and this has a lot of benefits one of them is that multi-stakes becomes simpler because a transaction could just go directly into a multi-sig and the multi-sig itself can pay for gas without this complicated scheme where the transaction goes into an ela then the eoa pays for gas then the ela calls the multisig the multisig refunds the eoa and then the ela needs to hold some if and what if gas prices go up by a factor of 10 and it does add to the eoa is not holding enough you so then you're stuck uh like basically getting rid of this and moving to this future better world where multi-sigs and social recovery wallets which i'm a big fan of and all these other things just work as efficiently as regular accounts um there's multiple paths to this so eip 2938 this eip that myself um ons guard dietrich and some other people have worked on a while back is one example of a path another example of a path is to just rely on flashbots so flashbots can create a system by which they detect these uh transactions that are just zero gas price direct calls to an ela and that that's just a forwarder to a contract and if they just decide that the transaction is will pay a fee then they could just put it in a bundle and miners will accept it or possibly some kind of convergence right like possibly there's some set of modifications you can make to eap2938 some set of optimizations that you have to do the flashbots and like these two routes will actually maybe end up more similar than different in a half a year's time i don't know but this problem is really important to keep working on um evm improvements so evmx is a big one that i'm personally excited about just modular operations going forward to 384 bits and above um this is really good for cryptography um also you can look at bit sizes below 256 bits and this is one way to get back some of the benefits of avm that's a 64-bit based instead of being a 256-bit based and potentially other kind of improvements to the ethereum virtual machine subroutines potentially some other things down the line so that is uh kind of the medium-term future um the next question is kind of the long-term future right um so one thing in the long term future that i think is really interesting is a cbc casper uh so there's these two flavors of casper right guess for ffg and the cbc casper cbc casper is kind of sitting in this state where a version of cbc casper that's fairly simple and that's like theoretically implementable and is there but the problem with that version of cbc casper is that there's just efficiency issues with it right cbc casper requires you to do much more logic that has to do with keeping track of of complicated data that has to do with individual uh messages whereas ffg is just kind of counting the messages up right and cbc casper is likely more secure because there's fewer kind of awkward interaction issues with lmd ghost cbc casper just runs on lmd ghost so it's much simpler in some in a conceptual way more flexible finality thresholds so like casper ffg if less than two-thirds are online uh you just lose finality completely with casper cbc as long as more than 50 are online you have at least a little a little bit of finality um here's this kind of current best effort from two years ago issue 701 that tries to talk about how to cbcfi the ethereum chain but there might be better ways and it's possible that the better way is actually depend on just waiting for better technology like zk snarks for example and that brings us to um snarking everything uh so we can uh snark the beacon chain uh we can snark the evm we could also potentially snark a better vm but have some kind of a pathway by which evm code can be automatically compiled to the better vm but if you write smart contracts in the better vm directly you get more efficiency um so the two of these things together basically mean that it just becomes much easier to run a node because you don't have to expend like barely any effort to verify other people's blocks uh you're just verifying a proof and downloading some data you the main effort you'd have to expand is on creating your own blocks um so the load would just be much lower and potentially i'm starting the evm also just makes it much easier to add native execution to shards if that ends up being uh something that we wants to do right like it's just much easier to figure out the crypto economics around adding evm execution to shards if you have snarks and so you don't even have to think about the possibility of like one of these executions being wrong and then you having to revert it um so starking everything is really nice it could add a lot of efficiencies it adds this kind of holy grail of a chain that requires a very low level of computing power to keep up with uh you could potentially have a super powerful white client protocol where the light client just does does some data availability sampling and then verifies one proof and that's it and you've basically verified that you have the current ethereum chain and it's up to date and it's correct um then in the so note the benefits of this are huge right i mean if we want to for marketing purposes we could just like brands this ethereum 3.0 but that's like the community's decision i mean i don't i don't know i don't know it's like your choice like fight it out in your forums people um quantum security is uh nice um so basically quantum computers are going to come at some points and to be quantum proof we basically just have to replace every elliptic curve thing with a hash thing right so replacing snarks with starks um replace bls signatures with aggregate signatures and we know of stark based aggregate signature schemes that are pretty good um starkware had some really nice ones that they have some examples of replace the vertical tree with us a stark merkle tree and you know keep replace um potentially replace the the vdf with a stark vdf if we end up doing a vdf that's not start from day one i just start everything and do everything based off of hashes and starks um so at this point arguably we're done right so like basically these are the first set of things here is like a lot of some security improvements some uh economic sustainability improvements um and some features and the far future is just about like really nailing down and uh improving um and having extremely strong guarantees about the security of the system um and then once you have the features and once you have the security like if you if you want core daf can go on vacation and go into maintenance mode right and i think there's a lot to be said for that like basically anything further if needed can be done at layer two um and if layer one just kind of stops moving quickly after this point uh then um that's really nice because it reduces the load on client developers it reduces the risk of centralization in client development you have this kind of one finite piece of code and uh client uh anyone would easily be able or one find a piece of spec and easily anyone uh at least who has has the knowledge to implement ck snark things would be able to adjust them implement a client for it um and also at this point backwards compatibility is probably something that becomes much more important right so there's a lot to be said i think for just kind of really reducing the speed of uh change of functionality changes even after this set of things is done and then reducing the speed the the kind of the speed of just changes in general after like the some key security improvements are done now these are i don't think these are the only three key security improvements that we'll have in the far future i'm sure that there is going to be others i'm sure there's also the possibility of just tweaks to economic logic and so one thing that i did not mention for example for the medium term is a tweak that just bounds the number of active validators just to kind of reduce the risk that the chain will end up being uh really or unexpectedly really expensive to process uh but um like i i do expect basically that sort of the pace of change for ethereum it can decrease right now and there is still the possibility of like experimenting with new vms and if we want that's something that can be done in protocol layer but that's also something that can be done it can be done at the role player right or potentially there's routes in the middle where the protocol layer adds protocol features that are specifically designed to basically make it really easy to make roll-ups with different vms and provide a kind of excellent and very smooth user experience for just jumping between them but like these are still more a kind of far future questions and you know even different people on the team have uh different uh opinions on these uh but uh you know that's uh you know basically where sort of the current known roadmap is going um [Music] oh yeah again if if people have questions i'm happy to answer them i'm also happy to scroll through the chat box um we'll do we'll do a bunch of moderation so we have a we have a list of questions that have not been answered yet and uh thank you so much for kind of dropping this whole list of amazing things that are upcoming in the future for everybody who's going to look at this in 30 seconds uh please post your questions on the chat and i'll release them directly on on this to vitalik um i'll start with a few that have not been answered i guess the first one uh obvious question is um why is statelessness and expiry kind of management easier to do at the same time versus independently and what's kind of the rationale behind that yes that's a very good and important question basically the idea is that the way the state expiry scheme works is that um you'll go away from having one state tree and you instead have a state tree per e-book right and are you still there uh yeah that's the one yesterday everything's good sorry i was just worried that zoom suddenly did something working um okay so basically state expiry involves moving from one state tree to this model of one stage three per ebook um and the really nice thing about that model is that that model actually it's by itself makes it easy to upgrade the stage b format right because if you upgrade the stage b format you can just make the upgraded version apply to new epochs and that's it you're done whereas with the current model if he wants to update the state tree today you have to have this really complicated protocol where like first you are kind of snapshot the current state then you have everyone recompute that state then you um have then you you keep track of what the delta is while you're doing the recomputing um and then you apply and then you apply the new state and then you start taking that delta and then kind of still moving it over into the into the new stage tree that you've created it's this fairly complicated five-step protocol and like the complexity of doing that is already like quite possibly half the complexity of like just making a state expert solution um so if we do state experience like basically like that just automatically gives us the easiest possible way to upgrade the state trade because all we have to do is we just have to say well everything starting from epoch 1 is going to use purple trees instead of hexagon patricia trees and then if we want we can make one single hard fork about a month later after epoch 1 begins where we all just like calculate the uh uh the new vertical the equivalent vertical root of epoch zero and we just kind of swap it out right and that's just the one time thing uh so the basically moving to this model where you have um epochs and old e-box expire and become frozen just happens to as a byproduct make it easier to do kind of all of this stage be upgrading and make stateless as possible got it awesome i also want to just quickly thank trent and maria-san on the chat they've been doing an excellent job annotating some of the points that you've made and kind of providing additional resources and also just commenting on what's happening um so just thanks so much for uh making this community awesome uh from what you just said there was another question that's related and that is um hope i lost the question let's see uh when on uh there you go so when will uh vertical trees be live will it be before after the merge just a quick clarification there okay um everything i talked about in this post including vertical trees is after the march awesome the next question is uh what will decide if after the merge that starting after merge and starting we will focus on data availability as opposed to further layer one scaling okay um basically the reason why we're doing this data availability centric as a shorting roadmap is because um well it well first of all roll ups are just like the first the scaling strategy that's the closest to being released like they have uncertainty but everything else has even more uncertainty and it like data only sharding does give them a scalability boost immediately but the second thing is that um like just having data sharding is in some ways just by itself a necessary stepping stone to having data and execution charting um like in order to solve the problems that you have to solve to have data and execution sharding you have to first solve the problems that you do with data sharding and then on top of that you have to solve some extra problems that are execution specific so it's it's on the way anyway um and so it's just obvious that this makes sense as a short-term goal to focus on awesome that makes a lot of sense um slightly related to the last question um how can technical debt be reduced pre-merge so my expectation is that like pre-merged there's still going to be quite a bit of technical uh quite a bit of technical debt um and it's not really going to go down before before the march the reason i think a big part of the reason is that before the merge we're just continuing to have this kind of social norm that says that in order to have something that's you know quote a legit ethereum client uh the ethereum client has to be able to process everything uh from genesis up until the current point and i think in the long run that's a formula that's worth moving away from right like in the long run i think we should be possible like a client should only have to be able to verify say the last um you know year of history for example and so if we do that then kind of older protocol like older versions of the protocol before recent hard forks can just sort of stop being considered and stop being part of the necessary code base over time and like in particular probably the biggest gain that we're going to get is when we do kind of make this uh important decision of uh kind of removing uh the ability to sync the pre-merge proof-of-work history from the core ethereum protocol right because once that happens then like there really is not going to be a need to do any of this uh or uh to do anything with approved worksheet and it will go down to just having this one chain um and the execution clients can just become much simpler you can just completely remove fork choice code and kind of separate syncing code from execution clients so a lot of good things can happen um yeah but yeah uh cool um the uh uh to to correct myself there i also want to thank a couple other people have done a great job migrating this community so eth memes and uh simbuza thank you so much for for also being super active i didn't mean to exclude anybody there um what the next question is uh what is a world um of in a way layered three look like uh where you have eight l2 and l1 working together um and just is that a valid question like what would that mean in in a feature case i'm not sure what layer three means like i think layer three is one of those terms that hasn't really been socially defined yet and so it can mean different things to different people like does it mean the application layer does it potentially mean layer two protocols that have to do with reading state from the from the chain does it have to do with application while your constructions like oracle's i don't know um and i think all of those are important problem problems they're kind of worthy of having their own teams working hard to solve them makes a lot of sense um you touched on a lot of new things that are up and coming uh what about evm and he wasn't um where does that fit in right so my like my personal opinion is definitely that like i personally have become less interested in ewasm over time um i think a big reason for this is that my excitement for ewasm initially was about the possibility that you know this is this advanced vm that has a lot of existing professional work going into making optimized implementations and they can even be compilers instead of being interpreters so they can be super fast and you can implement cryptography in them and you don't need pre-compiles anymore but the research since then has shown that that's not the reality right and the reality is that like the evm can or the e blossom compilers all have worst case bugs where you can make worst case code that attacks them and it makes them very slow and interpreters are not that big and improvements over the evm and also that like it's possible to extend the evm and improve it to make it basically good enough to do cryptography or to do a lot of cryptography with maybe a two to three x penalty with things like evm 384 or other thing or i guess it's being renamed the evmx now and so that path is looking better um the the realistic kind of a long-term vm upgrade possibility is like this idea that i mentioned where in the long term we can make this vm that's more explicitly start friendly and that could be a time to during which that evm can introduce some more features that are that kind of take advantage of the ability to do faster execution without bothering with 256 bits for everything but the important thing is that it will have to be backwards compatible with the evm right it'll have to have some kind of compilation path from the evm to that new vm because there's just existing applications that are using the evm and you know we're not going to be able to make them go away and if we want the chain to be provable then those things would have to be provable as well absolutely no that makes a lot of sense especially again as you pointed out the evmx feature set um it does kind of supersede a lot of uh those trade-offs another kind of quick question is there an optimal number of active validators to be expected for the merge i feel like the amount of validators that we have already is more than enough uh and obviously if there's three times more than that's great too but i'm not worried that i'm not worried about there being too few uh i'm also not worried about there being too many got it uh next question is how will contract composability work uh post merge um in terms of just post merge and and charting in async environment just what does that look like for all this um sure uh so i think um well the merge itself is not gonna affect anything right because the bridge itself is just a change to the consensus engine um i expect we will learn much more about um async interaction from the roll-up world the roll-up world is really starting to come online this year and uh you know we already have who bring in z gay sync and diversify and we're gonna see um optimism and orbits arbitrarily and i think i believe seller has some roll-up thing as well um so the yeah like there are going to be applications on each of these systems and there's going to be a need to have interoperability of the ability to jump between them easily and this is a problem that the ecosystem will just have to figure out and i feel like from the rollup or world we'll just learn a lot like there is a big chance that it's just not a problem right like you have this concept of zones and you can do synchronous things within one zone but like if you want you can jump between zones and jumping between them is fairly easy but like you'll just not be able to do synchronous things across multiple zones directly and that'll end up being fine uh so that's my kind of number one prediction but we could also learn other things right absolutely and sort of uh kind of attaching to that answer i guess like do you are you excited for any particular positive effects uh after the march for uh for more consumer facing use cases on top of each um i'm excited not so much for the merge but more for role in that case but more for roll-ups and sharding the reason i am excited for rollups and uh sharding is uh basically that roll-ups and charting have uh um are going to increase scalability and so they're going to massively reduce transaction fees and the massive reduction in transaction fees is something that we are going to need um to enable non-financial applications right there's a lot of really exciting non-financial applications there's ens there's the nft stuff there's the proof of humanity stuff there's like colony and all the dow stuff but for those things to run transactions just have to be significantly cheaper and you know two orders of magnitude cheaper and roll ups will provide that and starting will provide that even in the context of a much larger community and much higher demand so those are definitely things that i am excited about and i am just excited about the ethereum ecosystem being able to sort of turn back on as a platform for uh kind of deployment of all those uh amazing non-financial things that's i personally look forward to that world um just for everybody listening and we'll do a final call of the last few questions coming in to do anything that has not been answered please type that again on the chat and i'll relay that over over here one other kind of question i have is um you kind of talked a lot about what the the post merged world looks like the far out future and there's a lot of emphasis on just nars and starks um and just kind of uh talking of everything how far it out is that timeline and uh if you were to kind of give estimates what does that work when does that work um possibly like somewhere around three to five years um it's important to note that like it cannot happen uh uh too quickly because like doing snarks well requires using snark friendly hash functions and like the reason basically is that existing hash functions like shot 256 are just insanely bad from a yes narc efficiency perspective um like they take you know many tens of thousands of constraints foreign or the arithmetically optimized ones um i can work with only either a couple hundred constraints or even there's fancy stuff like gkr that if it works would i make it even cheaper um but these fancy hash functions require some amount of time in order to just be de-risked and like academically tested and cryptanalyzed and all of that stuff um but you know once we have that and once we have just better start technology another thing is that like just making a snarked version of the of like the evm is just this complex um kind of engineering task and probably a research task um and that's just something that'll take a lot of time to do um so yeah i i expect it to be a multi-year effort and also just realistically i do expect it to be a kind of lower priority effort for implementation than uh say state expiry just because state expiry just is this really important it's kind of high priority item for sustainability and to allow more gas growth but you know it will happen we've already started doing quite a lot of things to prepare for it happening no it's uh that's awesome um maybe i'll end with like a question here related to scaling ether in the hackathon there's over 600 developers hacking on cool stuff to uh make everything possible on l2 and just more scalable l1 solutions yeah what do you have a list of any cool ideas or things you want to see whether it's tooling or applications or just that anything that would drastically improve the experience for what it is now that people can uh hack on any tooling that like that people can build that could drastically improve the experience or tooling that exists your wish list of scaling related hackathons or ideas or tooling that you think could improve this ecosystem um just like zooming out a bit and just random ideas um one um social recovery wallets inside of rollups i'm a big fan of social recovery wallets for reasons that i talked about and uh i think uh like in my blog and other places um and grow ups just seem like a really good opportunity to kind of actually do them and get people into that and get people into the habit of using them so that's like an example of something that would be nice to build um another example of something that would be nice to build is actually building scalable infrastructure for reading data from um the ethereum blockchain ethereum history roll-up chains shard chains like everything i think it's about the same either way um the reason why this is important is because we are moving away from a world in which you like regular users will have nodes that are actually processing all of the data um and like because of all of these techniques that we talked about including roll ups and including did um eurasia coding and data availability sampling we're still going to have security but users are going to needs to have alternate ways to be able to grab the data that they need on demand either because they wants to read it or because they want to create transactions with it and so creating protocols that actually can um kind of replace the uh uh like basically replace a have a full nodes uh kind of api as much as possible but do it in a decentralized way that doesn't require any individual node to store anything is something that would be a really valuable to make as well how would somebody go about implementing something like that or designing something like that i guess um it's not that hard like i think step one is markle proofs and uh step step two is uh discovery and step three is incentives like you just have to kind of combine those pieces in the right way and i think you can make something great um well um if there's nothing else i want to thank you so much today for uh doing this amazing talk hopefully we'll uh make those slides in uh in the video available later on for everybody to catch up and uh thanks so much again thank you very much great so um thanks everybody for sticking us with uh all day today i know this is uh interestingly the delegate on a really cool note because our next week's summit is actually all about zero knowledge and how that world is going to make anything from scaling to just new primitives will allow more applications to be possible so um please tune in for next friday for our zero knowledge summit and we'll walk into what programmability with snarks and starts looks like along with uh cool applications of these technologies all of that information is available on skilling.educable.

com so um for those of you who are watching the summit i'll see you all next friday and for everybody hacking um wish you all the best for your current hacks and i will see you on our discord so thanks again thank you