 So just to bridge sort of like what happened before as this one is basically just like a continuing session to what happened in Osaka where we thought that we will almost die after Typhoon. So basically that was like proof of work to proof of stake, sort of like transition session where we hosted like some community sessions as well alongside the ETH1 in ETH1 X2 ETH2 and ETH2 sessions. It was kind of successful and a huge room where Vitalik went on like a huge session and brought like so many ETH research posts of like that inspired the discussions that happened during the session. And then just to give you a quick overview of the roadmap of what we've been discussing, like just a few points, mainly we've been discussing the IP 1559 the fee market change for Ethereum which was so very hot discussion and also the PROC POW which we agreed all that's sort of conspiracy driven IP and we should not keep much of a like we should not like pay much of attention to that as that's very conspiracy driven. Then we also started discussing about state rent as we realized that many people are using blockchain as a storage. So we were discussing that there should be rent free, that there should be some rent fee for the providers. It also kicked off the ideas for stateless claim with Alex and Piper. I'm not sure if they are there but they started pretty much discussing how we make Ethereum stateless and then they follow up the session in Paris after ECC in 2020 which was the COVID session as well. And then we were discussing also sharding like how Ethereum can like how like shards like the shard design basically and then the Ethereum transaction history archive which is basically about how we can keep the full state of all transactions and like archive notes and all that. So you guys may wondering why everybody is sitting down even I'm like sitting down because I don't want to be like too much like oh I'm like important and you guys are not but basically Ethereum magicians sessions are always like everybody's sort of like on the same same like line or something that like there is no such thing as like oh these are the corridors or like oh these are the speakers and they're important like no everybody is equal and everybody is as important as whether you are speaker or you are sitting in the audience and I highly encourage you to join us anytime in this like how sterile cool so if you have like something to say to this session or like to the topic that is being discussed feel free to anytime switch like anybody just like take their seat and be like hey like I want to like say something to this and even grab a mic and I also encourage you to take some notes or some like ideas that you have we also have a Marcus which is like thank you so much who is gonna take a notes from this session and then also but there is a guy who is going to take a note in Spanish so we are going to have a translated notes from this session as well and make sure to publish them on Ethereum magicians form and then I just figured out that this will be a cool quote to like kick off this session to like make Ethereum more diversified as I feel like we need more clients to be run in the Ethereum ecosystem and we should not be just focusing ourselves are on the main two clients and by the way the QR code we are going to let the QR code be there and that's where you can find the slides and in the slides are many links that what I've been just mentioning during my introduction speech and that's pretty much it from my side I'm just going to try to encourage you all to like speak up and like don't be scared even the mic it doesn't bite you and it's just like our friend and if you will try to if you want to like speak up about something we want you to like make sure that everybody will hear you basically and that's pretty much it I'm excited for this I'm just giving the words to Tim and let's kick off. Yeah thanks Annette for the intro. Yeah so I guess on the point of people asking questions and contributing I do not have near three hours of like contents here right like so like you know I have a couple questions to kick things off but like this is very much on you if you will have stuff you want to discuss this is the place for it or we'll be out here in 50 minutes but I guess yeah there's like three things on the slides I think our needs to discuss with the people here first is just like how the merge went it was a pretty big piece of work not only technically but just like making it happen from like a human perspective we have all these teams working together so yeah I'm personally curious to hear just from the different client teams and folks involved like how that whole process went is there things we can do better for like the next one or things we did well that we didn't expect to do so well. After that like we keep talking about like the surge, verge, purge, spurge all that stuff I think just want to make sure we have space you know to hear from different client teams about like how they see priorities there what they think is important where things are generally at and then answer all the questions from you guys because I think it's easy to like look at the four acronyms or like meme names and then when you get into the details there's like many more open questions so hopefully we can get into some of those and then yeah we'll try and keep time at the end or actually we will keep time no matter what at the end to just discuss like specific EIPs like there's a bunch of EIP champions Shanghai planning has been a bit different because we cancelled the calls after the merge to give people a break so everyone has like EIPs that they want to put in not all the places to discuss them right now so we'll use this as a sort of pressure valve for some of those discussions yeah so that's that's roughly it but again yeah please ask questions throughout otherwise this is going to be over pretty quick but yeah I take it off I'm I just was curious to hear from like different folks on kites like their perspective on like not like technically how the merge went like I think we've covered that a lot already but just how they felt during the process and like you know now that it's over and we have a bit more distance like looking back how do you feel that it went and are things that could have been better yeah I made the mistake of sitting beside him it was stressful it was really really stressful and really drawn out for a long time and I think as core devs we we've all felt that real pressure so that's that's kind of the personal view of it I don't know how you change that I'm not sure we should because we should have been under pressure to ship and we were but you know I guess I'd say never be in doubt that core devs feel the pressure to ship we really do yeah I think there were a lot of really good things we did the testing that we we managed to do was phenomenal and it was a kind of another couple of steps up on anything we've done before for hard forks and that kind of coordination and and work that went into that was absolutely fantastic starting with the client teams testing their releases but then the EF support of spinning up the shadow test nets were a brilliant idea and Mario and other people contributing to the test suites and hive tests and that kind of thing really really valuable I don't think we started those hive tests in particular early enough and I think that probably is a knock-on effect from we didn't necessarily include the execution clients early enough which might have been because I'm busy with you know 1559 or something giant so I'm not sure what the timelines there exactly were but it felt like consensus side almost felt confident and ready and execution was kind of like oh yeah emerged emerges the next thing we've got time now we can look and it wasn't wasn't a surprise to them don't don't get me wrong but I think that was a big deal that that would have helped to bring that forward and then have more time on things like being able to pay real attention to the hive test we were struggling as client developers to keep up with the sport and the last minute things we knew about and dealing with these hive test reports that are in a format that particularly for the cancer content aside we weren't particularly familiar with thank you made the mistake of sitting too close to age yeah I agree it was really stressful very very stressful four years I think a large part of it was figuring out how to deal with that and how to keep performing and keep delivering good code not sure what to do about that perhaps having gone through it once then these group of clients will be better at doing it again I think it was interesting to see how they were kind of like a few little efforts or a few people that kind of poked up and really push things along I think parry was really helpful I think Marius also managed to create a lot of momentum so I think there's a lot to be said about yeah just I think the right person at the right time relieving the right pressure point so I don't know what we can do to make that happen more in the future but those yeah those individuals should be enabled when they want to when they want to do something I think it went really well I have been quite disappointed with me V since since it's launched I know there's been with some of the implementations there there's been some bugs that we would like Jason encoding that really really shouldn't have hit us on mainnet I think it's probably because me V like we all kind of realize that that's the thing is happening quite close to the merge didn't quite get enough time to run with it didn't get enough time for it to be integrated into our setups I think there's also some catching up that those teams need to do in terms of announcements and comms so if they have failures with their software they need to announce it they need to tell people instantly that there is a problem that it's being looked into not sit on over some time and then and then publish it I was really happy to actually we almost launched in October so just the next year so but then I came back to the like after I said that I was like yeah maybe maybe it was not really the common agreement the common sense and I came back to the to the net of my team asking everyone how do you think I can do this for October like you think it's possible at least I have to go and just like tell everyone hey I was wrong and I said no we think it's possible so I thought okay yeah and well there was there was a lot of work but it seemed to remember thinking on the same day I think it was good to say it because suddenly all infrastructure teams started calling everyone and saying hey like we're launching October we are totally unprepared we have to start preparing and it was needed like because we needed no operators to start looking at this we needed the community to say okay there's some date for the first time so I miss it by a lot but and then in and for a yes I was still still very confident because I have seen the things progressing I've seen the the Ryan is getting very fast but it was like all those small things that take so much time really and the testing and the proper testing and the confidence and I think when I was a bit pessimistic was around April this year when I when we were thinking about the MV boost and how ready MV boost is and how much everybody was prepared for a movie boost and it was more stressed at the time about we'll have a movie boost on time or we'll have to launch before the movie boost because at the time we were thinking of June or May as a as a launch date for a movie it for for the merge so everything came together around September I definitely didn't want people to just say to use this difficulty bomb thing as a something that would drive the dates I talking to developers to our team I feel like there's really no more motivation you can get or no more pushing or shouting or asking that you could get for delivery on time so there's absolutely no sense to introduce any other stressors so so the difficulty bomb being moved slightly I hoped it won't move the merge date and we didn't so actually the merge it wasn't moved and nobody was talking about the block times but we would talk about the block times if it didn't happens nice um yeah we're focused on the other side of the room I wanted to share I guess a different aspect of the merge so we are like one of the minor clients Bezu team and one thing I would have done differently was preparing for people choosing client diversity getting ready for them didn't realize I guess I think it was around like two three weeks before the merge timeline we saw a huge amount of people thanks to a lot of solosakers coming through discord asking tons of questions and I think the maintainers were super busy with you know trying to get the final release out didn't get to really respond to a lot of them so I think that's something that if you had to go through the merge not really but if you had to go through it again definitely would do that differently to be ready for community support how do we get this new users coming through this ecosystem like how can we support that better and but honestly it's definitely a hard challenge because as maintainers like you're really deep in the weeds of like really trying to get the code out on top of that trying to support tons of users coming through is it's really challenging but thanks to a lot of the contributors who also chimed in and asked answering a lot of other people's questions on how to set up their validators and all that so yeah it's definitely a community effort it's not just the maintainers all-courtesce so thank you for those solosakers coming in and asking questions and really improving the client diversity and also other contributors supporting each other so yeah thank you for that I guess one less common is please don't threaten us minority clients by saying oh we're gonna go together I think that's like a stab in your like heart and twisting it so yeah thank you hello okay so I want to double down on Paul so I'm from prison and so from my team's perspective Merge has always just been consensus as institution and engineering API and boom done right and then like I guess like just a month before the merge we learn okay there's this MEV stuff we have to work on now and then there's this MEV booths and there's this relayer this builder so we just keep adding more and more actors to the picture and then even a few weeks before the merge right there there was this tornado cash this like old fetch stuff and then flashbots were the only relayer so our team had this big internal discussion it's okay should we drop the support right now like like what should we do if flashbar was the only relayer and the they are sensitive in section right even though and we boost it's a neutral piece of software but flashbots is the only relayer then as a client team we are indirectly supporting censorship and of course I'm not happy with that this this is not what we're here for right so I think like we learn a lot I learned a lot it just like if today relays are producing 50% of the blocks on the mainnet are they considered as layer one right and I'm I'm really happy to see there's more and more like relays flashbots they're joining the Oracle Devco they're starting to participate more on just layer one roadmap like architecture and stuff like that so I do think like we do have to work with them and then have to work with us together to basically push the space forward yeah good points by by Terrence I think it's worth saying as well that I think even though we did have some problems with MEV and I was pretty harsh on them before I think we did come out of it in a better spot than we were before there's no like MEV geth now and flashbots were really happy to relinquish that that control which was really cool and MEV boost is something that can be implemented by other people and even as it stands it works with other relays so I think we really opened up the world to MEV and although we didn't solve it and we're still not in a great spot I think we ended up in a better spot and I think flashbots have done some good stuff towards that as well yeah the circuit break was good as well yeah so now there's the consensus clients can detect when the chain is unhealthy and then just disable MEV so that's something that we couldn't really do before in MEV geth whether like MEV boot and flashbots could have implemented it but you know it's a lot of work for them so yeah now there's a lot more control from the consensus clients at least into what's going on with MEV and I think that's that's a really good place to be in. Do they still run MEV geth if you did the theory layers? I don't know actually it's a good question I kind of wasn't thinking about that but yeah because I think like you know for the most part most people who are running validators they're just getting blocks from the either the builder or the relay or somebody has to run something that looks like geth that's taking the searcher bundles together and putting them into a block format yeah I guess what's how if that that's still the case it's not it's not ideal but I guess what's better now is that every one of those gets produced is now verified by not that thing before it's published on the network. Yeah and I guess like from my perspective the whole situation with MEV was very interesting because MEV has been around for several years now and you know we've kind of seen through the DeFi summer and the NFT summer these crazy numbers about how much MEV there is and blocks and you know from my perspective was I was thinking you know there's so much money in this industry like the solutions are just going to appear and they're gonna be really robust and they're gonna work and then you know it turns out that six seven months before we were really projecting for the merch to happen we're starting to realize that the solutions that we as core developers feel need to exist weren't in the place that we felt that they needed to be and so we started trying to like help help accelerate that path and the way that it turned out I think like it's better than it could have been I would have been very curious to see like what you know institutions would have created their own MEV boost had this like open-source public thing not existed because I think that there is enough money in this industry that some of these big stakers would have realized you know there's no way for us to extract maybe anymore let's create some centralized endpoint for people to send bundles to and we'll just extract it for our customers and you know screw all the rest of the stakers they can figure out their own ways so it's not where we want it to be today we want to improve MEV boost to make it better and we eventually want to move to PBS where it's part of the protocol and so we're just working towards that but I think like also you know with respect to thinking that the MEV industry was going to build all this stuff the core development community is also like very anti-financialization of a lot of things and so to a degree it felt like we didn't want to think about it felt wrong for us to think about MEV in a lot of cases and it was only later on where we realized how much interplay there was between censorship and MEV and the ability to produce blocks and it started to just unfold very naturally over the last six to eight months and I think like looking back if we would have understood those things two years ago we probably would have thought a lot harder about how to think about this with respect to the marriage and maybe how to integrate some of the stuff a little bit more natively into clients. I guess yeah talking about like the design of the whole thing I'm curious to hear like Proto-Mickel you both spent a bunch of time like Erdion with like the engine API and and specking out of that but yeah Miguel do you want to just like walk us through like how do we come up with the merge like how do we how do we get here yeah hey okay so started like for me the merge started two and a half years ago like roughly at this moment in time and yeah by that time it was like an idea of the two-way bridge of bringing the Casper FFG as a finality gadget from the beacon chain to the the proof work chain that was the starting point and there was an idea of like actually transitioning the proof of work chain eventually to the one of the charts that was not yet designed by that time and yeah it was like a long journey I can't recall everything that has happened like during this more than two years period of time but one thing that I would just like to mention here like my key takeaway one of the key takeaways from the working on the merge project is that retrospectively what what I can yeah recall like the first collaboration with other some somebody else working on the same space was collaborated with Guillaume Guillaume prototype the basically the first execution layer client was not called that by that time but anyway it like made me much easier to like prototype the whole thing like the consensus layer interacting with the execution layer it was not done by engine API by that time but anyway it was like yeah the old idea of like putting it in the chart and make it work somehow so we did this prototype then yeah after some progress on the merge specs and then the ideas then prototyped with like ranism project so just you know forced us to make the first version of engine API for the do you remember all this enormous amount of hours you've spent managing this project and driving it through I mean I can talk about that I I want to first reiterate over what the first moment in time was that we developed the merge I think it was before covid before the whole pandemic I think in like SBC there were still discussions about e-wasm but then less than a month later in Paris during e-phone x discussions afterwards e-wasm or like the idea of execution charts was basically over and done for and these discussions between you and Guillaume, Denny, me, others Ben and also started where hey maybe we can prototype the catalyst thing with the evm attached to teku and yeah like that was kind of cool but it took less 2020 it took a year more than a year till we got to to ranism so it's a huge leap already where things happened and then in ranism where we're in this awkward spot where Altair was still not chapped and London was still not chapped and we were just like moment in time where there's this tech development where you have to convince people that they need to dedicate resources on something that's not the main artwork to make some kind of progress definitely like there were moments in time where I was slightly like yeah out of my humor because of the way these calls would go like for a month we were thinking of it like a hackathon where okay we just do the prototype with more than one client and more often it's just meant that some clients would not go and join these calls to even just get a glimpse of what we were trying to do after Altair and after London and I think like this discovery process for future works we can improve where that's the time and if we had more people think about the merch we could have realized that hey we need to make these communication channels with things like fresh pots and MFE because the merch is very soon otherwise it's very late then you get in these situations yeah by the way MEP people are going to join us for the last session so we can discuss more that later because Alex yeah just text me that he's coming for the last session unfortunately did not make it here can I continue on that yeah it's just a few few sentences left from my end yeah so after any this is the first time we had like engaged more client developers and client development teams into that we had to written to write us back of the engine API like to make this you know some kind of standardized or whatever it was even before M4 it was like like more than one year ago like yeah yeah April and May when we won yeah it was great so then M4 then yeah all this of chain events of chain sorry of sites of offline events it's a really huge facilitator of the progress and all the developers in one place talking to each other in person I think it's really helps to collaborate on the things even after the event when we're like on the internet back to work yeah and as has been mentioned testing efforts client developers gave a lot of feedback and all this stuff that was just and the key takeaway from what has been said yeah the right people at right moment in time make the things happen so retrospectively this is what has happened with the merge and I think that this may only happen this kind of like thing right people at the right moment in time appear like in the healthy community which we have currently the healthy community of researchers and developers and yeah and this like proof the merge is like as for me it's proof of like these that the this community of researchers and developers that we have an ethereum ecosystem can like capable of delivering like huge big sophisticated projects and like the merge is like the first one right so next is uh dank sharding and other things uh rock old trees so it's not that I'm not that scared about it after we deliver the merge with this huge success so thank you very much everyone who made it I guess on the note of the community has been like 35 minutes that's just us talking um team don't want to give a lot starter um to like tell us more we can do don't start but after that start asking questions so we can like yeah open this up hey thank you sorry for being late as we are most of the time we're we are the fifth the fifth consensus client so yeah we we actually produced our first block on mainnet in november of last year but it was actually fun to basically sprint up to uh to with everyone else and basically caught up um so that sort of retrospective was uh was amazing to see the kind of feat that we can get there and of course with the help of all the other client teams um as well we were able to pull through so basically goes to show that what we're capable of when we all work together especially when we're all focused on that one thing and it was to achieve a successful merge so um it was really great to for all you guys to help us basically pull us up to where you guys are um I guess one of the hardest things that we had to deal with with being a more later client uh to be ready for mainnet is really just the fact that client stickiness is really really huge issue and we definitely noticed it as we're going towards merge people tended to not necessarily want to experiment with a new client uh going up to something as critical as the merge so we found that to be quite difficult even though we you know tried our best to sort of make it easier for people you know or like one of the best examples would have been our um load star quick scripts that we use work which is basically like a one line command for people to start up load star with any of the EL clients um but you know didn't see as much traction with that as we'd like to but um now that we're pretty much caught up going into withdrawals Shanghai dank sharding hoping to see much more adoption with that and um yeah we we definitely can't do it without the help of all of our collective minds together so really our retrospective is um if you are an up-and-coming client um we're all here to help you thanks yeah so we we've just shared kind of mostly core devs and researchers you know our retrospectives on the merge so my question to everyone out in the community is what's it been like like what's your retrospective on how the merge has gone how has it been as a validator how has it been as a dap developer and those kinds of things someone's got to start just give someone a mic yeah thank you hi i know that it was crazy because uh in Mexico i'm trying to teach people what is your needs to make in what people like you are building are are creating and it's hard to call all the terminology is very hard to understand and the devs uh they don't teach people what you're doing and guys like me that are nerds reading all the stuff it's very hard to to keep a good channel channel so i think it's day to day it's improving life for example when when i start to make the threats about all core devs in spanish uh skylar came to me and said hey guy uh nice what you are what you are doing they and team bacon start to to share my post so thank you to everyone for all this i don't know i feel like very nervous because i think that i am with a very very smart guys people and it's like crazy but that day that night where i was with the itladan community speaking about the merge what it's going to do everybody was very very high then we saw the panda and was okay it's done let's go to sleep so great job guys great job and thank you to everyone who's doing those translations and helping with that education we can't keep up with all of it and it is a community effort it's just really brilliant this might be like a random question but can we have more documentation resources for future core developers um because i've looked around and it's very hard to find and i myself like to volunteer to take that task and would love to create a documentation tutorials and roadmaps because uh i really want to work on that but it's very hard to find like a cure path to become a core developer okay uh this is a great time to give a shout out because mario just came and he is uh actually one of the people who leads the fellowship program for core devs um like um leadership program thank you um have you heard about a protocol fellowship uh it's exactly answer to your question oh you were i'm sorry for that but you can still participate so this is the thing so like so uh within a protocol fellowship is kind of an internship program where um uh anybody can come and start working on a project and in a way that we it provides um certain mentorship from many of folks who are sitting here and other core devs and there are also resources so if with the the whole uh like the fellowship is coordinated via a repository uh on github where there is also suggested reading uh there are few things they put together but i agree it's not easy there it's it's a high wall that you have to go through but so we are i believe that this might make make it easier so there is uh there is a lot of things to dive into and uh the the reading in the repo can help you to look into what makes you uh with what you're interested in and then uh you can just start contributing because so the the calls and everything in the even if you were not accepted it's still open you can join uh if you are not accepted you just don't get a stipend uh but you can still come and if you work on a project and over a few weeks we see that you have valuable output uh we can still give you the stipend as well uh but uh it's fully permissionless you can come to the calls propose idea that you want there uh uh there are um calls where you can propose idea in an issue similar to acd uh i would like to discuss this and uh we'll invite some of the mentors to help you with that if you get some guidance so yeah hopefully it can help and if not that then uh never mind has uh internship uh program as well and uh we have like one of our projects is also core development as well where we are very happy to guide you over as well um yeah we are always hiring new interns so i don't know yeah so this is like sort of like should be your base layer for where to find more core devs related or like how to be a core dev although that was kind of controversial where um i think lane or amin yeah amin was like who is a core devs can i be a core dev who is a core dev um yeah who else will there ever be a hackathon for this sort of thing um maybe like a three-day thing event where people can work on funny stuff we should do that uh cuz christof wanted to do one in like nevermind hackathon uh but it was like it was supposed to be internal but i'm very happy to take this over and um just sort of like a core dev uh hackathon and i mean mario should definitely collaborate on that if thomas is okay with that cuz he's like my boss right now cuz i'm leading the internship program so just quickly i was gonna say um it's a lot of the open source repos also have tickets that are marked good to start development on so um that's another avenue it does get taken up by contributors and we review and give feedback and help and so there are a few avenues but it is a big it's a learning curve um so we were working this weekend on the eth boggletown some hypothesis regarding the new proof of stake system and one question we really couldn't get answered was now with the new proof of stake system is how the box the blocks get built is it still purely an economical incentive as where they choose the highest fees for the are the highest prices to include in the blocks or are there still other incentives include included as there's an increased risk of slashing so the the block building doesn't really lead to the slashing risk slashing risks are only uh related to the double signing like signing two different blocks or attesting to two different blocks or proposing two conflicting blocks or attesting to conflicting blocks uh so they yeah it's it should be economical incentive it should be aligned incentive something that is very natural so the block builder is looking for the payout and collects the transactions that are paying the most uh plans there might be any not clearly economical not financial but still quantifiable benefits right so Thomas is right about slashing uh there are inactivity penalties which are often confused with slashings which you can incur if you miss your proposal and for example if the latency is very high because you're using an external block builder service um so that's one incentive for people to use lower latency surfaces which should just be your own notes but I do think that's that's part of the whole mfv discussion on how we make homestakers as competitive with regular stakers when it comes to publishing blocks so that they get attested timely and they're not missed and larger blocks obviously they they are they cost more bandwidth they cost more time to propagate so that might play a role thank you I just wanted to I was just going to circle back very quickly to the question about how to be a core developer and I wanted to say that there's I think there's two things to consider the first is just follow all core devs the best of your ability I think orienting oneself around like what's actually happening in the protocol starts to make it a lot clearer like where places that you can contribute to so doing that and then I haven't talked to a core developer in a long time who doesn't have a long laundry list of things that they would love to happen that they just simply don't have enough hours in the day to do so maybe once you're feeling more oriented with the direction of the protocol to try and just reach out to a core developer and say hey you know this is my skill set this is where I'm coming from you know do you have a project in mind that I might be able to help with and I think like once you start doing a little bit of that and showing that there's like you're creating value then core teams love hiring people so this is a this is what I'd recommend all the tiny note on that about like following all core devs as the guy who runs it the first like six months of so it was my job to attend all core devs I just like didn't understand anything that was happening and like was literally like too intimidated to like speak up so like if that's your feeling that's normal and if you're smart and you'll probably not last six months but like it there's a lot of just like implied context that I don't know it's really hard and I felt really good about myself when Danny Ryan told me the same thing and he started I think before he started the EF he would attend the Casper CBC calls and he would just share links in the zoom chat he was telling me like you know when somebody was like oh like this paper came out he would just like google it to be the first guy to share the link in the zoom chat so like yeah the calls are like hard to there's not like a good way to dive into it I haven't found somebody and so if you're like if it feels weird for a while that's that's kind of normal um I have I when people ask me that questions I always throw in these are random ideas I think this is a good idea just be extremely obsessed with like each research forum and to a point where that you read the forum one or two three times and then take notes to like like basically where the notes that you can understand then you can transfer notes into blog posts and then you can share the blog posts to people and then but but when you're able to do that you are you like you can actually be fairly you can actually be very knowledgeable at that topic already which yeah and then other things like just just podcasts in general like here just like pay attention to like for that podcast and then take notes on that and then also share your notes just people will actually appreciate that because not because not a lot of people have time to watch like youtube videos and listen to podcasts and stuff people will prefer to read notes and just make sure to share everything on twitter that's where that's where the hype is and that's like how you can like get involved and go to events and just like speak up or even take notes and then like even DM to people that's like how you can basically get started also great way how to get even closer to the people in the ethereum is just volunteer on a conference that's basically how many people in the ecosystem including me started and I feel like that's the way how you can get even closer and whether that's like volunteering on the conference itself or you can just even volunteer on the calls and you can like find like a client calls and then just like hey like I want to take a notes or like this is my skill set and like this is how I want to help you or like I found a bounty like I found a bug in your code or something or just like get involved with the ducky tell repose yeah i'd 100% agree hi i'm christine i'm a researcher at galaxy but on the topic of a core dev calls i too definitely did not understand anything for like the first couple years of my time covering these calls but it takes a while i think one thing that i thought was really interesting about covering the merge and being on these like watching through live stream over the years that it took to kind of like get the merge going is how over time like the process for figuring out what goes into the merge and who gets to build clients for the merge increasingly become like a smaller and smaller and smaller team um so like in the beginning there was like probably there was like there's this article on coin desk talking about like how there's like eight or nine different client teams like trying to build for the merge but a lot of them dropped off once like i think there was a point in which like the the repo for how ethereum's consensus was going to happen got like totally overturned and that made a lot of client teams mad and so then it like shrank down to four and i think the closer like the client teams got to to the merge it was very it was very clear that like there there wasn't like really much more discussion to be had from like just anybody so like when the discord channel was like privatized like basically like no one talked because we really have to focus on the merge right now and when they started to become like differences of like client teams readiness for the merge so like some client teams were more ready than others had more features ready than others i think they're the differences between like preparation and resources for each client teams got a lot clearer like the closer it came to the merge um so i think like moving forward and looking ahead to some of the other bigger upgrades um i guess like i wanted to know your guys's thoughts on how to like on basically what the new process is going to be for eip's and stuff because like for the ethcore dev calls for the last couple months it's been clear that it's just the merge but now like there's going to be so much to discuss so much about ethereum's roadmap um so i thought that it was like really like part of the the whole topic around like ossification like the more decentralized this process is the harder it is to make changes but clearly there's like some amount of centralization that's needed and that we've already seen to make the merge possible and so now they're shanghai coming up so like will it still be like consensus layer execution layer like calls or how are we thinking about governance i guess moving forward to to to start to like um yeah pull off some of the other big big big roadmap items yeah wow there's a lot to unpack in there um i think i short really short answer is like slowly iterating from what we have like i think just like the merge itself was kind of a a feat of governance to some extent to get like nine client teams to work together um and agree on like uh like agreeing on the big stuff was easy for the merge i think everybody wanted to do it um like all the tiny things i don't know i have the latest valid hash like burnt into my head from typing it in the all coordinates agenda um like it's just like this thousand tiny things where it's like the coordination was really hard um i think the other thing is like and we're about to get into like it's like balancing like large protocol changes or something like the merge something like sharding something like stateless with like smaller things that like bring it out of value as well i i think this is where most of the tension probably arises like different prioritizations there i think it's i'm going to hear from dank right out there dank right you have like some like more radical views about the process that means so yeah and you haven't spoken so far so i think this is a good it's a good cue for you um i mean that's a big jump but yeah um i mean um i mean my my view on all core depths i mean like i mean uh i think i think the big thing that i i feel is missing and that i want to see is um representation of like ethereum's users and the whole community rather than it mostly being focused around one side of the of the um of ethereum which is the development um and i think that's uh that's a big thing and we would see very interesting and different proposals if we had more voices like that on the call also the ip processes being um like it's being improved over time and right now what like not like we but the ip i p group is working on and alongside with ethereum cathedrals uh is pretty much that they are going to like sort of fork or like separate the core ip's from the other erc's and like other different ip's uh and then eventually what's up oh okay uh yeah but like i remember like we've been talking with like team and some other even like Hudson i think you were there in the group where we wanted to separate the uh erc's from the eip's um oh jesus i mean also Hudson we we did not use the stage because we want to like be everybody on the same okay thank you um so pretty much we wanted to separate erc's from uh eip's but then it ended up what ended up happened is that we ended up uh sort of separating core ip's from the rest of the eip's that's exactly right and um there's been there's been years and years of debate over whether to separate eip's from erc's and a lot of it the biggest problem i'm finding looking back is that there wasn't a steward to be an erc editor i mean there are also eip editors already but there are like two or three people at this point and micah doesn't want to do the rc's anymore like he's been open about that i mean yeah there was like many people that wanted to sort of do it i was even like one of the people that wanted to like do it myself on behalf of magicians but then like i don't know it kind of fizzled yeah there was there was like miscommunication there was like a lot of different problems but either way i'm glad that it's getting separated now that's gonna make things less confusing when people talk about eip's and especially as ethereum is pos uh because back in like i think we had this discussion and uh like with mario's right at the arm stream where we started talking about how the eip process will gonna look like and that was like april this year um and all i basically pretty much got as answer was that it will be consensus driven um so not not ip process as we are used to right now which is by the way described in the ip one which you guys can find on eip.ethereum.org um yeah can i say one more quick thing on the eip's i i guess it's like worth separating like the tools from the process like sure you know like we can split out the rc's and i'm i'm very bullish on like executable specs for for the execution i were like there's a bunch of like mechanical changes we can do to the process and i think they'll be better but that's different from like how do we actually come to consensus on the thing like whether it's an eip or the yellow paper like a consensus spec pr um you know that's just like a marginal difference i think that so one thing i actually really don't like about all courteves is that it's calls um like my like and the reason for that is like um calls are hard because they optimize for a bunch of weird things so like they optimize for people who are awake at the time who are like uh good english speakers who like are very like eloquent and like and like think on their feet and and like respond live during the call um and i think this and also they're like not very scalable we can't have like 90 people on a call um and so like to your point about like having more more of like the community involved it's like that's something where like moving the calls are good because they give like a forcing function and like some rhythms like i wouldn't take them away completely but moving to be like more i think is something i've like i try to think a lot about and you know so for shanghai we have like this tag on on east magicians and like you know anyone can tag their eat their client devs can review it like i can't force client devs to like look at your eip they don't want to like you know no one can do that but it's like at least there's a list and they can scroll through it and like if it sounds good to them it might be like more accessible and maybe you wrote it you know at 9 a.m vietnam time rather than like 4 a.m during alcoe dev alcoe devs so yeah i i think moray sink is like one actual tech like thing we can do to make the process more open um yeah so you're like segue into it you don't have to like okay what's the next topic surge verge verge all the big stuff so so so so now that we've talked about how we are going to to come to consensus on these new upgrades and new things we could maybe talk about new upgrades and new things what's your favorite new upgrade marius that's enough segue for you yeah sure marius what's your favorite new upgrade um i i i like four four eight four four um that that's that's pretty nice i'm okay maybe okay a better question on like the new upgrades um i guess i'm curious like yeah from from client teams respectively of like how much have you been thinking about new upgrades because like everyone on twitter obviously talks about four eight four four a bunch of people not in client teams have been contributing a couple in client teams have as well but like you know mostly like we shipped emerge a month ago um you know like it's not a lot of time um so yeah how are you all thinking about like what's next or are you trying to not think about it as much as possible and you know decompress from the merge yeah so i kind of think our main responsibility is our users right now and uh so uh we have a bunch of upgrades coming up that oh yeah okay hi um we have a we have a so forget at least from my perspective forget it's the most important thing is the current network and it's not the it's not the future and it's not these it wasn't the merge and um we want to make sure that uh the current network runs and the current network doesn't go down and it's secure and it's usable and it's uh decentralized and you can run your own node um so uh we have a bunch of uh other things coming up to improve uh things about around the database in gas uh the the the states uh the way we store the state and um so yeah i'm i'm really excited about those and because we've been focusing kind of focusing on those we haven't focused too much on the upcoming EIPs um um okay okay like in general the team uh i i i personally also like i i i started implementing four eight four four in lighthouse who did the wrong wrong client but uh it was it was a learning experience and i i also worked a bit on the kz jesus ceremony because that was just interesting to me um um we we i think gas is in a fortunate position that we have a lot of outside contributions uh so people actually if they if they propose an EIP they usually implemented in gas and so when when like the fork time rolls around and we have to uh uh have the implementations for the EIPs uh we have something to build on and um we are in a very good position there compared to other client teams and uh so we can kind of focus a bit more on uh testing making sure that the spec is correct uh all of these things i i think it drifted very far from the question yeah cool um how we feel about upgrades um i think we're generally keen i think uh definitely keen for withdrawals which mark is working on um i i kind of feel like the merge is not really finished until we have them in we kind of have a bit of an outstanding promise that we're yet to fulfill to the stakers um so definitely keen to get that one in um without even saying like you know what do you want to do after the merge because it's not really after the merge for me until we've done that um yeah so keen to work on that keen to get that in soon definitely keen to get 4844 in i think that looks really cool um personally not super keen to rush it i think it'd be nice to have uh a bit of time like maros was saying to kind of watch the network um breathe um yeah so definitely keen for upgrades we sorry yeah yeah that's right um yeah we have um like Sean's been walking on it um maros has been working on it for lighthouse um yeah you gotta put in your time sheet man um yeah so we're keen i'll uh pass pass it to teku yeah i think i really support paul's point on the the next thing we do is withdrawals like it's gotta be done i i don't think it's reasonable to put in bigger things that are then going to delay getting withdrawals out we made a promise we shirked on the promise a bit and you were all very forgiving because we got the merge sooner and now we're going to deliver the promise we've we've got to come through on that um but i think the thing that really comes after the merge is the user support for the merge and the optimization and the cleanup and the learning now that we're actually seeing it in the real world for real there's a whole heap of stuff that we can now go oh we should make this better and it's not going to be protocol upgrades it's just client improvement and so on so that's going to take a good chunk of time but i think we can um start looking at a bunch of other things as well and so i think 4844 is probably getting the lion's share of attention of the next big thing after withdrawals yeah i think that withdrawals are absolutely must and absolutely the most important thing to deliver at the same time 4844 sounds so interesting that it starts to steal the thunder and and i think that's maybe even it's it's a bit dangerous we should yeah very brave man sitting between proto and red yeah exactly uh so so yeah that's that's why it's so interesting because people are so convincing in delivering those visions uh yeah i think that's uh coming back to her how did the minds team thinks about the next delivery i almost would like to activate daniel here to tell about his like plan of of delivering so i think it's uh in our case very similar what i just heard from other teams so you right now would like to relax a little bit and focus on improving our client yeah so the merge was extremely stressful to be honest for the whole team and uh now people want to do things that you know you know let's say slower slower pace yeah and additionally we would like to clean up a little bit yeah because there was no time um i know i don't know if you are aware but like never mind few months ago it was completely different uh team it was undersized very small at some point there was only one guy maric working on the merge which was crazy and you know i was really sorry when i joined and i you know met maric and it's okay we have to do something with that and yeah now it's we are in a completely different state uh we can you know improve our client a lot we have a lot of things that actually we are excited about and they are not you know i would say one to one related to to shankai these are the things like you mentioned yeah like database improvement our sync improvement you know our robustness of the client these are the things that maybe are not so excited exciting for the community but they are exciting for us and that's we are most they are talking about right now and there are also things like you know documentation community support user support these are things that didn't work well in the past and i think in general it should be improved not only in the other mind but in the whole community yeah so this is what's actually excites us right now and in terms of uh particularly ips we already started you know investigations but you know taking it slowly you know have fun with it like four eight four four is you know there is one guy working from our team that's i see that he's really excited about it that's cool there is we already started to it with ravels we have some kind of draft implementation and we know that's maybe it's gonna change but yeah why not to start playing with it so yeah in general yeah we are much better state when we used to be and yeah this is what we are doing right now so uh yeah i can give you uh an additional perspective from minority client like load star we're pretty much in the same boat i guess with like another mind where before like at a point where we haven't even hired the people that you guys have at this point so in terms of time we really haven't had as much time to really think too too far ahead we're getting most of the stuff from you know you guys in the community and such but uh technical debt is definitely a huge thing for us as well we have a lot of documentation we need an update stuff like this which um you know it would be nice to have a a sprint that's just you know for technical debt and and and getting our client up uh to to par in that sense um but that's you know we're really excited of course to implement all the upcoming stuff um in the roadmap um like this was great for me because i haven't even specced out 4844 as much as i should yet so that's you know where we're at basically so on the numbers side um there is a delicate balance between uh implementing new things that are still uh moving targets and uh doing things that are expecting from client teams like testing and trying not to introduce regressions uh like we had a lot of um point release in the past three weeks before the merge and that took like all of our focus but we do like um implementing new things as well for example we uh took the lead with lot star on the light client thing so this is something that we will continue but we didn't start at all on anything related to the surge the verge uh the purge and the splurge well we did try to look into kzg commitments but they changed a lot in the past two years so everything has to be thrown out and uh recorded i also think it's fine for uh these smaller clients to not be on the like brink of research um because the especially with these uh with these upgrades like like 4844 right now the spec will change uh a lot and uh i think it just doesn't make sense for for smaller client teams um that have that need to focus on like getting their client up to speed um to also uh think about the research and and the iteration on the spec so i think that's something that we did with uh with the merge pretty pretty well is there was like the bigger client teams uh gath lighthouse prism um nethermine and bisu iterating on the spec and the the other clients um kind of uh like like like following a bit and um i think that's a good way for the teams that have more funding more people um to take some of the load away from the other teams and also that's also what we're trying with uh with uh testing uh and and ethium foundation testing team uh where we're currently looking for new people so if you're interested in testing uh come talk to me or mario viga um yes so we want to completely revamp the way we do state tests um to make it really really easy for for for people to to implement state tests and uh to take some load of of of the the client teams i just wanted to share from a small client perspective so for bisu honestly past month has been as equally hectic as preparing for the merge um with bunch of um major fixes um for bug fixes so honestly we haven't even thought of future um eip's honestly i think we even haven't gotten a chance to rest and a lot of the maintainers couldn't make it because they're still working really hard working on the fixes some even donated some of their paternity leave to work on the fixes um so quite quite intense um but i think afterwards we'll um hopefully get some time to rest and get all the maintainers together talk through what's gonna be the future um you know um works that we want to work on what really resonated me personally with the earlier talks by aya was the subtraction part so i'm hoping that as maintainers we got to see which part of our code base could we actually subtract i think we're still talking about what eip's are we gonna add and add and add to our code base um but i think there's gonna be some like future um like you know tech not future like tech debt from the past to clear out to modularize um the the product itself and so looking into a lot of um i would say client improvement is currently where i see maintainers are talking a lot about but yeah definitely would um would have to come talk about eip's yeah um so i'm prism and um i think withdraw is is important but it's also on the easier side and on the eip 444 we have been lucky and optimism and then calling base have been contributing to our code base so thank you for that but i do want to throw like a curve ball i think like censorship resistance is equally as important as 444 and withdraw i just look at me be watched info and 47 percent of the blocks are on the all-fat compliance right now so 47 percent of the blocks on mainnet all have some sort of censorship resistance building to it right so i do think like there's something like before full pbs there's definitely something that we can do to make it better we do have some hybrid pbs we can do we can leverage the builder api we can iterate very fast we can have some mad boost crd's type of thing and we tell these latest research posts does point us to some nice um direction and point out b also has some nice research posts as well so i'm very excited for that and i definitely definitely want to prioritize right now i'm very sympathetic to uh teams who talk about wanting time to uh to work on their client and handle their technical back load and i thought that that uh 4844 and withdrawals was a really good example of they both kind of individually look like okay we've got kind of an idea of how these two things are going to work but and then putting them in the same fork actually does increase complexity uh for you know minor technical reasons i i guess you know we're talking about uh switching the forking based on a block number two based on time stamp and you know the the more places that you have to change in the code base uh the the more work that's going to be right so 4844 introduces a transaction type which means you know more places that this forking based on time stamp has to has to happen for example so just an interesting place of seeing why you might get pushed back on hey let's only do one major thing in this next you know fork instead of two and and leave room for maintenance so so just that as an example for this i actually implemented the forking based on timestamps for Shanghai which was like a 20 line change and i looked into doing the same thing for sorry for for for withdrawals not for Shanghai um and i looked into doing the same thing for 4844 and it would be like 70 different files that i would need to touch just for changing the changing the way we we verify the signatures and the signer so um it's individually it's it's it's okay but together it creates even more complexity i feel like we've heard a lot of clients say that they feel that they could spend some time cleaning things up in their code base improve in you know improving things in their code base and i'm just curious to hear from him and from other clients like how should we think about this in respect to the roadmap and all the things we want to do because it seems like we're consistently saying we need to ship withdrawals yesterday we need to ship 48443 months ago vercal trees all these things and it's not clear to me how to do that and balance and you know maintaining clients for the long term so well we say that we want to slow down at the same time i think that nevermind is ready to to think like a big client like the one that is that is leading the effort on the exploration so so by the fact that we have the large team uh we can both keep cleaning the technical depth but also participate in the research and prototyping uh so so we've we've seen we've heard that from mika talking about is mika still there okay um so he was talking how much it was helpful to have the prototype from guillaume right and how much marisa's experimentations were pushing things forward um so you have those excited people like like seeing now and that in mind and they want to explore they want to experiment and this should help everyone to to push things forward and and these deliveries are critical and they still time critical i'll be doing that in parallel even if the field will be we change the style um that's just we do that a bit more mature way i think that maturity will come also from the learning from the merge and from the team being larger so i think on average the teams grew by like two three times in the last two years on many of the clients teams which means that we should be able to ship faster than in the past and when we look at the last two years comparing to the you know 2018-19 we've seen that we've seen that pace and there is much more experience with the teams people delivered so much during the merge and they they are interested in now delivering the things that they wanted to work on the side and many of those things that they wanted to work on the side are the IPs are the are the items that are interesting like 4844 right uh so this will happen i think this will happen but it's also another factor that we need to consider yeah but like changing let's say 10 lines of code or 17 files two years ago was completely different than changing the same amount of files right now the code base is much bigger the complexity is much bigger and you know sometimes you know small change requires you know days or maybe weeks of you know research and testing and testing especially testing yeah it's something that we need to improve and so yeah the teams grow grew but at the same time it takes much i think it's gonna take much much time to deliver similar change as the ones in the past um if i can add something as a non-client um the right now testing is not much like the experience with testing is not much better than the experience introducing an eip i think we need a a better platform to discuss like the bottlenecks of ethereum to understand like the complexity of syncing of this guy oh and so on and tools like hive they are just as stagnant sometimes as the clients themselves and it comes to making changes or improvements and maybe we're talking about awkward of changes maybe we should have like a regular breakout for testing maybe we should have more of this platform to discuss how we get out of this this decked up into a place where we can be excited about new eip's so so one thing about hive is that it's currently maintained by the guest team and we're slowly transitioning this over to the testing team so mario wrote a lot of hive tests for the merge basically all all of the hive test tests for the merge and uh so as i said we're trying to increase uh we're trying to ramp up the size of the testing team within the ethereum foundation and that should take some hey i'd like that if your information is helping but i don't think the right solution is to limit it to one team no i agree so i think as like an open call to anybody if you are a testing team and like you want to work on this stuff ping danny ryan and he will answer you any hour or day any minute of any hour of every day about improved testing capacity and i think like i agree it's like a huge moment to be fair i feel like the merge we did like an amazing job there like relative to what it was before like when we ship 1559 i was like not 100 confident i was like and then when the merge went live i you know like i was expecting some operator to mess it up but not like the network to break like it felt like the testing it was like super robust um and and the challenge the challenge i think with shipping all of like this complicated stuff is often not like not just that it's hard but it's like it changes the shape of the network like it's easy to add the new opcode right and right test for it like we have framework for that and now we have and like if you want to do something like blobs um we we don't have like blob testing right and so we're gonna need to build all that um and then then we'll have it and it'll be easier to like you know grow the size of blobs or something but then we're gonna gonna we want to do i don't know like data availability sampling we need like you need like always to build the new testing stuff um and it's kind of hard because like you can't build it in advance because you need you need to test something um so there's this weird like chicken and egg but i do think like like we were having the same conversation in 2018 in Osaka and like our capacity was like 25 probably of this so it's like it i feel we've we have gotten better i don't know that it's ever gonna feel better doing the work which is many of my thing it's like we just do more we're better at it but it still feels like we're kind of pushing yourselves because like it's just hard stuff and you need to build it um and yeah like i mean you know to touch on for it for four obviously client teams kind of tired you know want to take a break want to focus on withdrawals but like having optimism had step up having coinways step up like we wouldn't even be talking about for it for four if this hadn't happened and i'm not convinced that like four years ago it would have been possible for like there were no l2 teams but like you know for like the plasma team to like ship something like that so yeah i think we're making progress i don't know that's ever gonna feel better is my rough feeling so adrian from tech who i just moved from over there um so for context um so i think the other factor that's slightly interesting is there's this real cycle to doing hard forks in that client teams in particular get swamped it's not really early on the research team probably get swamped first then the client teams get swamped and then our work is done and we're kind of waiting on coordination and there's this lull and that lull is where we get all of our client optimizations and all the other stuff kind of done um and uh yeah so that's real opportunity and and a lot of the community coordination happens there there's there's a lot of time it takes to go from the code is ready and done to the code is tested in every possible situation and we've automated all of that in terms of the cross client stuff and and the level of detail we want for ethereum and then the code is actually ready from the community's perspective and all the tools have updated and so on and all of those kind of happen to happen in sequence so as long as we don't shoot for a massive hard fork we can get a you know a little hump of we can get you know say withdrawals done because they're relatively simple pick up a lull and then be ready to to pick up something big again um so it's not a case of stop the world it's just managing those cycles um and probably the other factor is that teams go through that kind of cycle as well that you'll have a great team and you're going well and then someone will get a better job offer somewhere and you're kind of suddenly you've got fewer people on your team and you're rebuilding with some new people again and yet all the client teams are nodding we've all done it it happens on every team from time to time it just depends where you are in that cycle as to how freaking out you are about the next hard fork as well um I was expecting to come and try and like make a pitch for why it's crazy to do more than just withdrawals as a big thing in the first hard fork after the merge but actually I've not heard a single cord of advocate for that so far so oh but maybe dank oh no I moved within arm reach of the office of the question anyway um but I did I did want to ask two um points about withdrawals um like mostly to consensus clients um so the first point is um a few people have said things like oh it's a relatively small change and so my my I wanted to just check like is it so um so one of the other sessions recently one of the points it was made uh was that um you know at the at the time that the um withdrawals become enabled also um withdrawal key rotation becomes available so there's going to be enormous queue of people wanting to do key rotation there's going to be massive MUV from those validators who are trying to exit before um they get hacked because their key has been compromised over the last two years all kinds of other sort of maybe things we haven't thought about very much um so do those worry people at all or or not at all um and the second point I wanted to raise about withdrawals was around whether uh kind of links the tech at point that a few people have mentioned is uh is there is there a kind of significant um quantity of tech around the deposit process so so as as as withdrawals the proposal exists is to create a new operation for withdrawals it's it's not a transaction it's it's a completely separate type of thing um it seems quite natural you might want to just have a corresponding deposit operation clean up the deposit contract deal with the issues like kind of you know double counting issue it's all this kind of stuff um that would make the protocol more understandable for future generations is anyone interested in that or is that for later I heard some good arguments about cleaning up the deposit contract to keep the supply in the balances actually matching all the expectations rather than locking up or like burning the the deposits and unminting through withdrawals so that's fair I do think deposits are user initiated and withdrawals are system initiated so they're fundamentally different but yes there's a lot of tech debt there and yes we will fix it in a in a hard fork at some point um just to simplify like it's it's ridiculous the beacon chain is still voting on what it sees as the eth1 head after the merge and it's 8 000 blocks behind but hey it works right and we didn't have to touch it then that was good but we will have to fix that I'm curious to hear from the 4844 maxis so the thing about 4844 is is it's this complement to proof of stake in the old dream of serenity so we're very motivated to ship it at the same time I think there are goalposts and like the communication about the state of ethereum are not that clear and so I'd like a better platform for testing I'd like testing to be less stagnant I'd like to contribute to testing and often I see that some of the test tooling are locked into either a research team or the gaff team of hive and if we open these things more like up and we communicated and that counts about these things I would I think we can make a lot more of these quick programs towards the state we're very happy to to work on for for other complex upgrades um yeah I want to share my perspective on as well I think like we have heard a lot about tech depth this is which is like fair these the the devs here like they have the best overview of that and that is like a very important point of course um but I think we also have a different kind of debt which is like right now we cannot serve the vast majority of people who might want to use ethereum so like I think like it illustrates my point from earlier that we are having these discussions among core devs and they are good and they are important but somehow they can't be the only input into the decision-making so I don't want to clearly say like I can't say like we have to do for it for four as part of Shanghai uh but personally I would love to see it and um I think there are very good reasons to try to do it and um and I think like only looking at the tech depth and saying like we can't do it because of this and we need to do everything in sequence um is is not enough in my opinion in arguing against it like it's um it's uh we we have to like at some point also start seeing the other side like okay so what what is the consequence of not doing it like my fear like of course like if we have say Shanghai for we managed to do it in February and then we can do like for it for for a few months later okay like everyone's happy with that but like what happens if actually Shanghai does not happen in February it happens in June it happens in September or something and for it for four slips into 2024 I think I mean I would be fairly unhappy with that so like we should consider these scenarios and we should also think about what it means to a theorem yes it's like it's a bear market now so maybe we don't have these high fees as pressing pressing an issue anymore but I think they are still actually a pressing issue because right now maybe like we don't feel the pain as much because our the things that we have been doing are fine but still a lot of applications are not being built because the fees are too high and because they can't like the experimentation can't happen because I can't like do some fun stuff if things cost one dollar per transaction which I could do if it's one cent per transaction so I think like we should like be more willing to like think about this part as well and I would love to like understand how we can also like get that in that thinking into our governance pro process as well so currently we're releasing a artworks basically when it's ready so the more things we put inside the longer it takes to be ready because of testing for example so if we actually do withdrawals which are supposedly simple although the talk from yesterday was less reassuring regarding that we can yeah maybe in February we can have withdrawals and then for rightful for for the next one but if we put both together maybe it would be only in June so there is a balance there I guess one question there is like do you think it's possible to have a one fork in February and then another one like literally three or four months later we did Berlin and London with four months okay okay that's I mean one I mean this is like a discussion but just like one other thing I wanted to add just like to what dinkrat said is like thinking about it from the perspective of tech debt of layer two protocols and of roll-ups right like the yeah one of the kind of philosophical goals of 4844 I think was to kind of be a yeah like the changed the change to end all changes sort of for specifically for layer two's in the sense that 4844 introduces stuff like the point evaluation breaking pile and the concept of blobs and that allows layer two is to kind of set their code once and they can literally write their code and launch it and then you know no matter how much we screw around with the sharding design later as long as we kind of screw around within certain parameters roll-ups will be able to kind of you know breathe easy and know that you know they don't have to make like that kind of re-architecting again right so I think there's you know there's also value in trying to like get that phase done earlier because you know the earlier they can do those those kinds of changes that you know the more they can get to the phase where like you know they can start clearing instead of they have to know that like they have to clear eventually let's just it's so worth talking to layer two teams about that too I mean I'm sure they'll have their own perspectives so I guess we there is kind of consensus that we want 4844 and withdrawals within the next nine months is let's say so the question becomes both together or withdraw first and then 4844 and so planning team I will say one of the added challenges that the specs for 4844 and Capella are not unified so like he's working on 4844 I'm working on Capella and that's gonna be a hell of a pull request to try to merge these things and test them so they're kind of already written like they're separate just so one thing I would add with regard to hard forks one versus two is that generally the hard forks implementing something takes usually less time than rolling it out so implementing both withdrawals and 4844 in the same hard for definitely makes it longer but I think overall it would still be shorter than doing two hard forks because you have a sorry so essentially I think rolling out the hard forks always takes two to three months of just well every client is yeah I'm not done yet let's test it tests are not done yet okay let's do a hard for this test not hard for that that that's not so we kind of I don't necessarily want to say we suck at rolling out things but we don't really push very hard so if you want to roll out two hard forks then you have this boiler plate time that will eat up both of from both of them so that's the extra I just want to chime in on Donkrat's point from the Coinbase perspective that's what I represent and I know that we're still here kind of building trust you know convincing like I get it I get it like it's the first time you've had me in this room but you know we've been working with Proto for the last five months on the IP 4844 implementing an imprisonment spec, prism and geth and I think to Donkrat's point the difference between like H1 of next year and 2024 for a business like Coinbase is massive and I think the way that shows up is we have products that we've built on chain smart contracts that we want to be launching like literally we want to be launching in Q4 and Q1 of next year and we can't right now and that is because at the scale that we're operating out where we're talking about bringing millions or tens of millions customers into those contracts in our wallet products fully non-custodially it's just too too expensive most of our customers who are not in the US can't pay for it and we as a business especially in the bear market can't subsidize the cost for them and so what that means is that in the context of these conversations the people who maybe don't understand the technology benefits of decentralization or security they then go and say hey there's all these other EVM chains they have sub one cent fees can we just deploy this thing on that like would that be a faster can get can that get this thing shipped in Q1 and it's up to the people like me maybe or others in the company who understand the whole process and why we're doing rollups and why this is such an important investment from a decentralization security perspective say no like we need to wait we need to wait for this to have the right solution and so I think waiting until the beginning of next year you know first half of next year I feel like that's like a thing we can hold we can make it happen waiting until 2024 is really hard that's going to be a real challenge for us and so I think I think from from where I sit our feeling is like let's make the list of all of the things that all of the people in this room feel like we need in order to feel comfortable and if that's better monitoring of the network so we can understand bandwidth if that's better testing so we can feel more confident in the change that we're making whatever it is like give us the list give optimism the list and we're ready to throw resources at this and support this and I know that again we have a lot of trust to build that will come through in its work a year from now I hope that there's a lot more trust here but I do want to voice like that's the impact for for a business like us and we're ready to come to the table with y'all and work together to figure out how do we make it so the end result is tens of millions or hundreds of millions of more users are using Ethereum by the middle of the end of next year so I have I have two rebuttals to to to putting for it for foreign into Shanghai one of them is I don't I don't I don't see any roll-ups that are trustless right now most of them don't implement the the fraud proofs they're putting the data on-chain but the data is not really used for anything so like you cannot use it to to prove that the that the that the roll-up is wrong and so if we implement thanksharding we basically say to the community use these roll-ups but the roll-ups are not secure um I think that's kind of a it's a minor problem it's it's the other thing the bigger problem I see is that from yesterday's conversation just doesn't seem ready yet so withdrawals the way I see it are basically done that like they are implemented in some of the clients already the specs seems to be pretty stable and with thanksharding we recently had a new fee market change that I don't know how much thought has has been put into it from from my point of view it it like it the the fee market change at some some 1559 like uh thing and from my point of view it it looks like we have a hammer the 1559 hammer and now every everything looks like a nail and um so I think there has to be more oh oh yeah yeah so sorry sorry yeah okay no we actually knew to do this change like this change was like in the pipeline for like months I think it wasn't like something we suddenly came up this was clear we wanted to do this and we do have the change implemented in geth imprisonment and a live dev net okay yeah yeah so but those are things that those those are things that are uh that were not not quite clear to me and um so from my point of view we could ship with uh withdrawals easily january especially if we if we uh like kick out some of yes now yeah okay it's it's probably a bigger change for the for the consensus layer I think for the execution layer it's it's pretty pretty much done and um okay okay okay maybe I'm I'm totally wrong here um but I I agree with the argument that so even if we were to ship uh withdrawals in january um I think we could only ship uh dank sharding september of of 2023 if we were to do both we can probably ship it somewhere in the middle and so actually would if I if I really have if I really think about it it would probably cut to two months uh to to both of it even even though I don't like it and even though I don't like to admit it um but I think it might be the right thing to do I mean I think like the what you what the feeling you have is probably that it is a bit more risky to do both at the same time and I think like most people would probably agree with that like that making a bigger change definitely adds to the risk of the hard fork itself um and I think we also should have an honest conversation on in which cases we are willing to accept those risks because what we're doing is just so important that maybe like some risks have to be accepted as part of doing it so Paul's been waiting well yeah Paul from techie team just on that I mean there's a couple of aspects maybe we need to get better at doing hard forks and releasing them honestly it's a long time between code completion and getting to getting to that gate that may be a thing we need to address but the other side of it playing devil's advocate I understand that 4844 might be important and if it's relatively well-defined there's nothing physically stopping us from doing that first and just delivering 4844 and not delivering withdrawals I mean it's a it is it is an actual option that we have no I'm playing devil's advocate Paul is not representing the views of the techie team this is a fair comment it's purely my view but in reality if two is too hard and we want to deliver this early in a timely manner to not stuff over businesses that is an option that we do have yeah we should absolutely focus on doing the most important thing first always um I think the point that's come up a couple of times is you know when we ship withdrawals and it's actually when we finish code completion because running through test nets doesn't take code of time we put out a release it should be pretty quick and easy there is coordination cost and it consumes all code devs for a while so you've got to know what's coming next if you're going to paralyze it but it's code completion that's the big thing I'll give it in between I'll just pop in so in my opinion withdrawals are kind of specced out so it I mean there are variations but it's simple it's really really simple whereas with 4844 that will most definitely take a lot more time to spec out and it has a lot more potential problems with denial of service and everything it it affects network so withdrawals that's just a tiny consensus change you know tweak a bit the data structures and done with with 4844 that has a much deeper implication so I think it it will require a lot more work and in my opinion it would be much simpler to say that okay for withdrawals are definitely going in and maybe give a cut off that if we for some reason 4844 gets complicated and we cannot finish it by month x then just say okay we're rolling with withdrawals first and then whatever whenever the other is ready so quick question from me because I heard the term a few times like about code completion and then rolling the change and that we are very slow in the second part but you know I joined right yeah I'm I'm a new guy but what I observed with the marriage we we shipped shipped in middle of September but what I observed like from my the definition I know the code was not completed in August and some teams were like pushing the changes at the very end and for me like when you say that code is completed you know you you've been testing you start testing and you don't introduce new changes here so the code is stable so it looked a bit differently from my perspective yeah I agree the merge was not a case where we were called complete three months before um so yeah but but we have done that before right like and and you know again I think burden London was like a good example as soon as we were kind of code complete on burden we started working on London before like it shipped and part of the reason for that three-month delay is not like for the client teams it's for like everyone running you know like folks like Coinbase because usually like people like and not the point of Coinbase here like people just don't care about the hard forks until they're like announced on a blog post on blog.etherium.org and then they're like holy shit and then they like message me and they're like oh my god we need to like upgrade all our infrastructure and you know and especially so if like it's a complicated hard fork if it's just like introducing a new opcode um they need to upgrade their nodes and still sometimes you know they're like oh we need like two months to do that or something so it's it's worth noting like we can set our schedule somewhat independently of like the release schedule um but that doesn't necessarily mean you want to like do code complete and ship two weeks later because there's still value in giving people time to upgrade and I would also argue the merge was like cutting it close and um I think you know the merge was like a big change the environment bits that like proof of statements so I think there was a bunch of variables in that one um but if you look historically we've been like kind of slow but I think that's that's like healthy for people like people people who like are not core developers should not have to look at this stuff every day to know like is there a hard fork in 10 days right uh dino basal maintainer um one of the ideas that you you sent to me once uh Tim that might help because I'm hearing a lot of just talk about um lots lots of bandwidth lots needed in in the layer one um what if we prototype some of our ideas relating to things like EVM and transaction formats on a layer two and that way the libraries and the tooling could adopt to that on the layer two stuff and then um all the downstream stuff is ready and then layer one can implement it when they have the bandwidth um and not having to rush in and get those in so you can get cool things like BLS transaction formats sooner rather than in 2024 or 2025 I really do like the idea at the same time we as layer two optimism especially we're trying not to stray away from layer one where we create conflicts in development we're literally just trying to if we could we would run Gav without modifications we don't want to be different and often I just like client teams layer one developers to be more receptive towards changes but also testing and like creating confidence in these changes as layer two otherwise you get this conflict of interest where okay you want to make the change to be special and new and exciting and cheap but you you're not shipping the Ethereum dream yes like and especially data fidelity like for it for far we we can't even ship it on layer two or we like we created layer three situation with a much much smaller validator sound when we go through that big list of proposed EIP stuff that's coming up in the next thing like half of them are just EVM stuff and that stuff is easy to push through but then again it's the situation like we had with subroutines where it was implemented it was ready and then the week before the first test net all of a sudden it gets ripped out I mean I like the idea but your voice and the exact concern how do we get the commitment that if it's done it will ship on layer one without substantial change because then if you have these changes on layer two and they change substantially then it's a burden on the layer two chain if they put it on on one of their premier chains rather than on test net so one thing to answer here is that I think it's very from the outside it it's a bit strange because it kind of looks like there is commitment to go with an EIP and in reality what at least what I've experienced is that most layer one most execution clients won't even touch an EIP until somebody else actually implements it and verifies that it's correct so usually you have the EIP authors which kind of has to beg one of the clients to please implement it and and everybody is just waiting for that client to implement and find all the corner cases and when when the core devs say that okay we are releasing this EIP in three months and everybody goes into this holy shit mode and okay let's quickly implement it and then we cannot like pursue this dream of roll-ups as like like competitive execution layers on top of a secure data layer that's minimal and like widely decentralized we're now just we don't have a layer two EPM standards but I mean what if you wind up in a situation like coven where you had part of the chain that ran with wasm and then all of a sudden wasm is gone then all of a sudden one client that can run wasm is gone um and you can't run the chain from zero is that a bad thing is it an okay thing I would say it's pretty pretty bad so it's it's it's basically just shopping teched up to layer twos and then the cost is incurred by users being confused why there's smart contract works on one chain not the other chain right oh just yeah we can wrap up here but like yeah we yeah we could I mean if there's final comments we can do that then maybe we should take a short break but just want to make sure we want to keep the last hour to discuss actual EIPs um because we we don't usually have like forums to do that with all the client teams so and if people want to have less comments or take a short break you can do that but let's take a break for like five minutes and then let's have the Shanghai EIP authors line up or switch the spots with the current yeah yeah come to the front if you're yeah that would be awesome thank you cool yeah go to the bathroom