Moving to an EIP-Centric Process: A Retrospective

Transcript

okay all right this is work yep it does so here's our next speaker starting a bit late apologies for that sweet um hey everybody oh oh oh okay the lights are on we're good okay so we're good with the live stream thanks everyone my name is Tim I'm from Pegasus I'm here to talk about some changes we've made to the each process if she came here at the time of my talk I'm sorry you had to listen to 15 minutes of etc' Schilling this talk is about etherium yeah so basically and sorry I actually had slides for this but they're on a Mac and now I need to go through the PowerPoint so you at the PDF so you'll lose my animations um yeah so back at Def Con

last year my colleague Dan oh and me gave a talk about changes in the eeap's process over the past year and 2019 there were a lot of proposals made to improve things based on how Istanbul had gone and I'll give you a bit of background about that and then walk through you know the proposed changes that we had and how we've done on them so far so the first thing to note is like where we were at a Def Con s here we were just off the tales of planning Istanbul which was kind of dead hard for Croatia had been the most he proposed to aetherium ever and the theorem community had grown a lot in the past year and the process we use up to Istanbul was kind of a waterfall process where we had all

these stages of the eeap's process and every single iPad to move through each step of the process at the same time and this means that the process kind of gets stuck every time there's an EEP that slows it down and and what I have on the slide here is all the eeap's that were kind of in this this final list stage that were proposed for assemble and and all the dependencies that had between them and so this means that like when it came to time to plan the actual upgrade the core developers have to think through all of these dependencies try and figure out you know what's the best way for all these eats to work together in the upgrade which ones are actually competitive to one another and that slowed the process down a lot so instead of having your upgrade in October like

we planned we ended up having it at the end of the year and so during the year as this was going on and all the people in the community proposed some some ways we could improve the process so that Berlin which would be the next network network upgrade could be much smoother than Istanbul here I have a animation about how we've done so far and basically the first thing that happened is as we wrapped up Istanbul we had an issue we were so caught up with all of these eats that I showed earlier that we kind of forgot to think about the difficulty bomb so even though some people did some calculations for when the bomb would go off and those

showed that it would come up I think in summer 2020 people didn't really double-check those calculations and and then in November when we were basically done planning the Istanbul upgrade ready to go live on main that somebody showed up in the core developer chat and said hey guys I think the bomb is going off right now and they were right so we had to put together this kind of emergency upgrade called muir glacier that would basically just push out the bomb and we had to deploy that over the holidays um it was less than ideal but luckily we had over 99.5% of the nodes on the network upgrade and so now kind of oh so again you get like some spoilers or some fancy animations here oh well back to the proposals that were

done we tried to aggregate them at DEFCON and and called it the train station model because the goal was to have a process that was a bit more like how trains operate where you buy a ticket at the last minute you get on it and then the train leaves without you I'm rather than like a plane ticket where you kind of buy your ticket months in advance and then the plane will wait for you if your luggage is already inside and there were four main ideas here the first is that we wanted to have apes progress independently throughout the process so like I mentioned earlier we used to have this waterfall process which wasn't great because it would get deadlocked on the slowest EEP every time so ideally you want Apes to move at different stages at different pace and then you schedule them for a specific

upgrade once they're actually done and then similarly we wanted each to have a champion so this might sound trivial but having someone who kind of a single point of contact that the core developers can pin who shows up on the call even though they're not doing all the work for to eat themself is hugely important I the third thing is kind of related to the first so if you have these ifs that progress independently you would like to have updates that ship based on whatever is ready so as soon as you have a set of each that are ready you bundle them together and that constitutes your upgrade if anything is kind of slowing down the process you can simply move them back to the next upgrade and finally in order to kind of compensate that you want to have a predictable pace

of upgrade upgrades so we were aiming for semiannual this way if you're working on an e Pitt doesn't make it into a specific upgrade it simply gets moved back six months but you know that there's another one that's coming and so as the slide shows on these first two we actually did did quite a good job um and if we look at at what the EEP centric model we've we've adopted was like it basically goes as follows you first start you right here EEP and then we've added this new stage called eligible for inclusion this means you go in the core devs call you give kind of a high-level overview of your EEP and the core devs will mark it eligible assuming that if everything goes well in the implementation conceptually did except you know did accept it as part of an

upgrade and we have a list for all the Apes that are in the status that's at eight twenty three seventy eight you can see it there on the slide and this is a bit different than what we did before because the eeap's are not already assigned to a specific upgrade we're just saying this is like something we'd like to do but we're not committing to when we're actually gonna gonna get this live so once you have your you're eligible for inclusion status then this is as the previous process you go you put together your reference implementation for your EEP and you put together reference tests now people can do that themselves for their own oops using retest death we have a new security consideration sections in the EEP so every each should have kind of a

detailed explanation of the security implications and you'll want to get the community to poke at your EEP and give feedback and iterate on it and so once you've done all of that you have your reference implementation you have your tests it's been evaluated you go back on our core devs get eat move to accepted then all of the maintenance science will implement the EEP and it'll be scheduled for the nest the next test network and then once that goes live assuming there's no issues it'll be scheduled for the next maintenance fork and then go live on main net and so if you look at at this model in kind of a more visual way and you can see the various stages kind of laid out here and and I I've linked all the eeap's that have been kind of proposed and and and talked about on the

Cortez call over the past few months um and what's good here as you can see there's um there's kind of like a funnel so even though I the eeap's were always progressing at different pace and now we can actually see like the various stages that eeap's are at and it really helps the reason about you know what's ready what's not and to make sure that things are not like deadlocked based on something else so obviously the big caveat there is that we haven't gone through a full upgrade cycle yet so you know we haven't run this process all the way to the end but it's it's starting to the promising and under the kind of 0 column you can see there's there's like stateless fines and gas for now the gadget so these are initiatives that are being worked on abital are kind of still at the prep and

research stage but I wanted to put them there to show they're kind of moving along as well so yeah so the first two seems like everything's going well third one what is done is what ships it's kind of hard to get a give an answer to that yet mostly because we haven't shipped a full upgrade using this this process yet but there's there's a few reasons to be skeptical um the first one is that single EEP upgrades really aren't great there's a pretty high fixed cost they're having these upgrades because you need to test them you need to communicate them to the community everyone has to upgrade their nodes and so there's still a lot of value of trying to estimate which eeap's will be ready kind of at the same time and bundle them together and we've been starting those discussions already for Berlin um the

next thing is that dependencies don't magically disappear because you have smaller upgrades so you do spend less time thinking about like intra upgrade dependencies but you do spend a lot of time thinking about dependencies across multiple upgrades and one example of this is this ungass proposal which proposes to make gas an observer in the EVM and EEP 1702 which proposes to add versioning in the EVM there's a lot of conversations about whether we should only ever have to EVM versions one with gas observable one without and then and then you know if we decide to do that that obviously implies which of these apes and and we deploy in when um the third bit is that for pretty

technical changes it's it's even harder to get a technical or sorry a good definition of done and so as we've been working on like more I don't know bigger changes as part of a theorem one point X and we we don't have a really good feel to know when this is like actually ready to push so if you look at things like VIP 1559 the fee market change VIP 1962 which added a bunch of crypto pre compiles and even stuff like stateless clients and ungass it's really hard to like draw the line and say okay this is actually ready and and so therefore makes it harder to say okay when do we actually ship this and the final bit is that this model kind it doesn't have the forcing function of a date so in the past even though we had a waterfall

model with like every single date that we would miss at least it gave us something to aim for and we would kind of get Gillett with all like kind of late and now that we don't have a date we don't have like a specific thing that we're aiming for so yeah mixed bag for the third one how about semiannual upgrades this is something we're actually not going to be doing and there's a few reasons for this um the first is it conflicts basically with the idea of shipping things when they're done so if you have this predictable cadence it's it's kind of hard to map that back to saying like oh we'll deploy this as soon as it's ready and the second probably the most important one is it's just not clear

what the right paces to have upgrades so whether that's six months four months three months or a year and that's mostly because of like the large each one point X research initiatives and then some coordination that we need with it too and we really can't predict what the next like two years of upgrades will we'll need to be in terms of cadence um and the third point is there's been an interesting proposal to move from having block based upgrades to time-based upgrades so one of the big challenge we have mouths with these block based upgrades is we need to set a block like one or two months in advance and because of the variants and the block times this means that the actual time at which the network upgrades might drift by about a week so it's extremely hard for teams

running nodes to prepare you know well in advance for that so instead there's been a proposal to use a time stamp kind of as an activation and then use the next I think thousand like round thousand block after that and that would reduce like the the delay window from like a week to only a couple hours which would make upgrades kind of much more predictable in terms of when they happen even though we can't predict how many of them there will be so yeah that's kind of the status of where we're at on the the changes we proposed a DEFCON and a quick conclusion is that with each one point X there's a lot of high quality efforts being worked on on the network and it seems like the eccentric process

is successful in smoothing things out and make it easy to reason about where we're different things are out but it doesn't fix all the coordination issues so there's no way to have like a perfectly clear world map for aetherium and to minimize kind of dependencies or duplications of work and we still haven't cept like a final timing strategy so if this is stuff that you're interested in there's kind of three main places where we're dis gets discussed and you can get involved the first is called a IP IP so this stands for a IP improvement process and it's a working group started by the cat herders to just talk through these issues and make the process more efficient um the second

place for a lot of dis gets discussed is the theory of magicians so there's a whole process improvement category there to discuss things like a IP IP this VIP centric process I'm linked and so on and the third bit is the eeap's get a room and so while like most of the talk there is often on like specific oops there's a lot of metal oops that also get discussed and those tend to involve the process a bit more um yeah so that's all I had if you want these slides and all the links in them you can get the QR code or the bitly link and I started late I don't know if I have time for questions but if anyone has anyone okay I have time for questions if anyone has a question happy to take those I was gonna clap first nandhu questions now we could do the

questions but anyone okay thanks a lot you