EIPIP Meeting 53

Transcript

welcome to eipip meeting 53 i just have shared agenda in the chat and um i don't know we see some new people on the call today do we want to go with a small introduction brief introduction if anyone is interested and then we can get into the agenda item sure that's good hello yeah anyone if you would like to go ahead first uh okay i can go first yeah hi everyone uh my name is victor uh on github i go by xin v nlv and uh i'm the author of uh erc uh

1202 and the ip2135 um it's a voting standard and the other one is a consumable interface and i joined this meeting because i think it's a little bit uh hard for me to see how to like move forward on it how to get adoptions and how to uh discuss with uh to get more consensus so looking forward to your advice and guidance here my name is victor thank you thanks for joining victor alright not greg i've been at this so long i can't remember

but predators i'm not quite an og but close me and hudson and nick pretty much put together the current the current eip and then then some of you people have made a lot of changes you just have only two statuses hey i'm sam i'm responsible for breaking a lot of the changes that uh greg mentioned well a few of the more recent ones anyways are you in a train station sam uh mcdonald's close enough

so i see but we have one more new person he is jose and jose if you would like to introduce yourself briefly and yeah please go ahead yeah thank you hi guys i have signed roughly two weeks ago helping learning and trying to contribute for the issues in the eip bot specifically we have i have been trying to to get the 53 and the issue 53 and issue 58 and actually trying to figure it out about the issue 55

um well thank you for the opportunity i am here for as i say learning and helping appreciate it right we can get into that uh issues uh maybe uh later on the agenda well thank you so much for joining us today all right with that i think we can now just get into the items that have been listed here for today's discussion the first item is a rename master branch to meme branch um this item was requested at eipip issue section and also at the eip github issue section by panda pip1 however he has closed the eipip issue but that is still open at eip

github um issue um i think i have added the link so if people want they can click it there and he listed a list of ethereum github repositories uh where this change is requested it seems that there was a voting to rename it as well i don't know what uh other editors have to say on that uh voting what are you referring to the voting there is a thumbs up thumbs down informal vote on the issue oh i'm not a huge fan of democracy personally

well i think i'm more curious on understanding like do we really need to have this thing done like do we really need to rename what is that is breaking if we do not rename it so i think the argument for doing it is um that it might make the repository less accessible to people who find the term master offensive and the argument against it is master is a commonly used word and it doesn't necessarily have those connotations for everybody i didn't know that for

tech people i don't know yeah any other thought if people may have yeah just to reiterate what i said in the discussion uh my general feeling is that if we rename it we'll offend the people who are against the renaming if we don't rename it we'll offend the people who are for the renaming so in order to remain credibly neutral i think we should do nothing and in this case do nothing happens to side with the um the people who prefer the term master but that's the most neutral path pathway can take because it's um basically follow the default it's been mastered for so long sorry sorry mika

it's been master for so long why would we want to create confusion by changing it out to the master branch and so many jit hub projects i think you know i don't know it's a difficult topic right and um there is precedent in the ethereum ecosystem for making the change um like suicide to self-destruct um and i think this change has a more technical side to it than that that one did but um yeah and i just want to make it clear

i'm actually against the proposal i just think i'm the only one here who would argue for it so um from what i hear i think all three editors are against if i get you correct sam you are against the proposal right um very weakly against yeah yeah i think the counter argument here is right as mentioned by greg like you know we have been using master for so long why do you confuse people whatever changes we make it requires a lot of information sharing in terms of making community aware that this change has been made and even after yes we find out people coming back to us and we were never aware of what the changes are

and i'm not sure if uh if there is like a harmful necessity to change it just renaming it for the purpose of this um i would be happy to hear others thought as well but i think uh three of the editors out of five are voting no for that so considering this as uh eip especially for eip github repository i would like to collect more thoughts and see if there is general change on the other repositories of ethereum if they agree to change it maybe that would be a good way to proceed what do people think yeah i think that's that's my biggest concern is that if we do make this

change it should be uniform for all repositories under the ethereum uh organization and also we probably shouldn't discuss this too much today because the the issues like champion isn't on this call as far as i know so i agree i agree um so we can just communicate that this has been uh discussed in the meeting and this is what most of the people in the me people present here uh things but anyone if you are in uh strongly in favor please speak up so we can update the issue accordingly and see what the person wants to keep it on or close the issue

i think you're muted greg we can't hear you i'm very sensitive to the issue especially as an american and our our uh horrible history with that um but it does seem like a lot of disruption so we should move into it pretty carefully um i noticed that github is has changed it for new repositories they're creating but they're not going through and changing existing repositories [Music] right

so we start rearranging another thing right that's right so i think in this meeting we are especially uh um discussing issues which are related to eip github repository and because that is a part of ethereum um github so we will wait for making any changes on our and till it is done at the organization level itself does that sound like a fair consensus for the group well if no one opposes then i would consider it like this is the general consensus the rough consciousness the rough consensus on which we

generally try to handle things here all right so we will keep it there only moving on to the next item is a discus appropriate date for created in eip so this item is added based on the recommendation from the last meeting the group was uh discussing useful and possibly less useful field of an eip that we have at the moment and it was brought up that how confusing dates can be so i wanted to bring it up to this meeting today so we can get more feedback from people what do they generally think of having created field in the eips i am taking an

example here for example uh for example i'm taking eip 4430 described transaction this particular proposal was documented on 7th november 2021 but it was merged just yesterday that is 5th april 2022 but when i look into this particular proposal in eips.ethereum.org it looks like that the created field will show the date on which this proposal was documented however it can be very confusing for people if they are referring in later future that the created means that it was created in november 2021 but definitely it was not available for

anyone till april 2022 so i want to just check what is general part how do we want to see this thing my personal preference and in the ideal world of rainbows and unicorns would be that the created field is automatically filled in and it's based on when the file was initially added to the repository and this would all be done by ci and we would not have a field in the eip itself it would just be like when you look at eips.ethereum.org it would be generated automatically from the basic file creation date um that being said i recognize there's a non-trivial amount of engineering effort to achieve that and

until we have that i don't think like i can appreciate the desire to keep the created feel um on a more personal note i personally find no value in the creative field like i don't care what they something was created it doesn't matter for me um and so i i don't know if everybody else okay that i'd be totally fine i just ruined the field entirely but maybe other people have a reason that they think it's valuable in which case i'm okay with keeping it as well i like seeing the age of an eip so until we have a technical solution for it i think we should keep it uh greg you might want to unmute yourself

i just assume greg is talking to himself yes and my internet connection keeps dropping so if i seem to have gone away it's because i've gone away um yeah it's it's useful for showing more or less how old something is a precise value doesn't matter that much but if any like if it's six years old it's good to know that well in that case it looks like that the best midway would be like if we keep looking for someone to be maybe able to update the value of the field as the merge date of the draft and uh till we get there we continue

having it on the eip the way it is but definitely we keep our search on maybe we can create an issue uh to get this field updated by ci and let's see if we can get some contributor working on it all right um maybe we can add it as an action item we create the field and keep looking for people who may be able to contribute on this part item number three is a discus eip status that may or may not be added to a new proposal so this item is added based on comments

uh that we have found on um fellowship of ethereum magician for some of the eips definitely more than one that's why i'm saying some because i could not read all of them we actually organized a peep and eat meeting for a few core proposals in the past week so i'm taking examples of those particular proposals number is eip4895 beacon chain push withdrawal as operations so in that particular proposal there is a mention of eip 4788 which seems to be an alternative method of getting beacon chain withdrawal um done on the main net this proposal is in draft but most likely it will be dropped because we

have to go with one proposal so if we are going with four eight nine five we may not be going with four seven eight eight yeah so i'm pretty strongly against having finally the reason for this is because draft dips are highly mutable like we've had people in the past we just take an aip and basically rewrite the whole thing before it gets from draft to review or review to final and so that mutability means you're effectively linking you have some final eip that is supposed to be a canonical specification for a thing and it's linking out to another ap that is a completely immutable and may be something totally different in the future and so what i generally tell people is uh just take the the key

points like like often this comes out like like the issue which you mentioned where someone is saying hey here's an idea and then in the rationale section for when we're describing why we didn't do something else they say we didn't do this other thing and then they pointed you know what we're saying is we'll never make it past graph and they say we didn't do the other thing because x y and z my general recommendation to those people is just extract out you know one or two sentence description uh vip other thing and include it in line and i mean here the rationale section is just to give people some some answers to common questions and uh you know reasons why you know path a was chosen instead of that b and i don't think it's

necessary to link to an entire specification especially one that is going to be mutable and i'd rather see them include an immutable um you know short description that stands at some time that that doesn't work in the in the evm work we've got a collection of eips which are mutually interrelated and just having a sentence or something is inadequate that they need to read each other yeah so this is very specifically for eips that are mutually exclusive um mutually like when you have a set of vips that need to work together i'm totally okay with linking between them

um that's definitely fine this is when someone has eip that says like sometimes people create two eips they're like two different solutions the same problem only one of those solutions will ever make it to final the other one will just die and it will go away and so hang on so why would only one of them make it to final can't you finalize an eip even though it's never adopted so this is for core eips specifically and core eips um the current process is core eops only get to final if they go like that's the final equals ethereum um we've talked about having core aps fallacies similar to erc's where you know you can move final if you want um

whenever and it's unrelated to the you know ethereum mainnet launch but that got a lot of pushback from core devs like they want the eip status to be correlated with maintenance um see i'd much prefer having them separate and then having like an adopted header field that actually lists what hard fork it was adopted in like i think that would make more sense no i'm sorry i got strong feelings yes because because i was there when when certain decisions were made um which that when the the editing is basically handed off to the core devs to do what they need to do

and a final standard that was never on the main net is not final it can be changed at any time before it finally finally gets onto the main net otherwise it otherwise you'll need to go back and edit it before it gets on the main net because things on the main net can have changed um we went through this 20 with 23 15. it was going to go on the main net and was yanked out very close uh very and i decided to keep editing 2315 rather than throw it away and start over

was that the right decision i don't know but it um other other eips it'll just be not quite but later it's just the eip process and the core devs process were never intended to be totally tightly intertwined like this so it's a core eip was not to be final until it hit the main net people wanted some sort of final status needed some sort of final status for non-core eips so that people trying to implement

trying to implement systems that depended on each other could point to the eip and say this is the standard if you want to interoperate we all need to follow this standard so you need a final there so having a final vip for core uh uh means it's not that has not been put on the main net really means it's not final um yeah i think to to summarize that and this is basically what greg said and what other feedback we got is that because eips can change it up to the

last minute before they go on to on to maintenance we find bugs any ips right up to you know public test networks and sometimes you know after the public test networks and when those changes happen we need to be able to rapidly iterate and so pragmatically we can never make an eip final because final means so if we maintain the stance that final means immutable then we cannot make an eap final until after it has made that because it's not until they hit me it's made not that we actually know that it's not going to change like with bug fix or something and so because of that um even even if we don't have like an actual assertion that core eips can't be final until they hit main net dramatically like that's what ends up happening because we can't

reasonably say they're immutable until we're sure that's what's going on tonight um maybe we could but then we have a problem where um we have to tell the core devs you know at the 11th hour sorry even you yeah has already marked this final so you need to you know draft a fork of it and create a new one get a new number you know update your code with that new number if you have a number in your code somewhere um which leads to a lot of problems so i tend to agree with with greg though perhaps not as passionately no i i think that makes sense so is there maybe a um a final but not deployed status that we could use like withdrawn or is that

still immutable last call is so first things that are slated to go on to maintenance and last call is meant to kind of serve that purpose for coordinates we're saying we're pretty sure this isn't going to change but we're leaving in the door open for changes at the 11th hour but we're pretty confident um if you're referring to things that are um like these alternatives that we're talking about strictly back the original topic where you've got some alternative vip that you know we know will never go to mainnet but we want to permanently record its history um i mean we could we could come up with like some status that is final but not deployed and will never be deployed

just so we can then do this cross-linking yeah that feels weird uh i'm not absolutely against it though yeah i just don't want to add too many new states right like we already have so many states they don't think we need more of them i was just thinking if we could use withdrawn for something like that i believe withdrawn can be revived um i think is what we agreed on okay john means the author decided not to pursue it at this time but maybe at some point in the future if they decide to pick it up or someone else wants to take the torch um you can pull it out so he can keep the number or keep consistency that makes sense

okay i'm sorry i think uh i am lost uh so for withdrawn is it uh allowed to keep the number there so if if something goes into withdrawn and then later the author wants to pick it up again um i believe we decided they can and so you just move it back from withdrawn to whatever maybe i'm just remembering um i know there was a bunch of discussion about this yeah i i think um i think the decision that i can read here from eip1 right now because this has been discussed a lot so i can totally understand i and you may be getting confused here it states that withdrawn the eip authors have withdrawn the

proposed eip this state has finality and can no longer be resurrected using this eip number if the idea is pursued at a later date it is considered as a new proposal even if the text is identical yeah but we cannot allow the same number you have to use this different number i mean if that's the case i'm perfectly happy like using withdrawn as like you can link to withdrawn eips and final eips i think that makes sense yeah i'm convinced by that argument well my next part of this question was related to a withdrawn eip uh it was for a proposal three eight five five push zero

instruction and there was this mention of an eip2733 transaction package which is currently withdrawn and we know that it is never going to be in the final list of eip github repositories it is the mention of a with a drawn eip okay for a new proposal or should we try avoiding that i'm fine with it if we retain the rule that withdrawn is a final state like terminal it's immutable just like finally like that's under that assumption okay that if we change that assumption this is getting so complicated the itf has managed the internet for a

very long time with two or three statuses basically withdraw to me sounds like the author is is indicating they don't want it to go in with the creative commons anyone can pick it up and in that sense a new number makes sense perhaps this is more like a stagnant eip it may get picked up again it may not but if it does it's still basically the same proposal it's just now time to try it again because situations have changed but yeah my recommendation to most people is

go to stack stagnant not withdrawn like if you have any inclination that you might want to do this in the future stagnant that's a better better choice withdrawn is like the author uh saying i don't think they should go in like i am actively against this and a great this actually the situation right now with these um kind of mutually exclusive vips is a great example of this where the author is saying we have i have decided i want to champion this one i think this should go in and this withdrawn one i don't think should go in as the the alternative and we can leave them both in you know draft or review right up until um the end and then when one goes final the other one good was drawn just kind of that way we get the immune immutability i've just drawn one so we can reasonably link to

it and it has it can provide context for some other erp that did go in um and we don't worry about it changing in the future i see hand raised by victor you have something to add yeah i was about to mention uh greg sent with greg that stagnant seems to be relevant in this context and also uh there's another state called leaving um like if we are anticipating that uh the the drop that the eip is in a state of that's relevant that's relatively formal but still you can expect change then leaving might also be

one of the state that is relevant here and uh from the erc perspective i also see many uh proposal that was like proposed and then they can get into a state that is already finalized but not adopted um so i think if we really want to have another state and maybe final instead of naming final but not adopted maybe we can have one after an option is have one after final as like adopted and i want to bring to the um i want to mention the question is also is that it seems like we as a decentralized

uh platform and and commit movements we also anticipate that many adopted uh in the different implementations so if we really want to pursue another new state that indicates the adoption or implementation or go to mainnet then that will bring up a new problem whether one or two adopted what would that stay be like so i just want to put that in place well my general thing is that once mit is final it's done with the iep process and the weather gets picked up by users or used or whatever is a separate out of the ips a good example of this is 28 30 i think it was that was the access

list like no one uses that like i don't think i think there's like three access-less transactions on all of the magnetic street i think they're protesting the so one could say you know it's on mainnet but it hasn't been adopted by the community and i'm uh fairly strongly against trying to define what adopted me does one person using it being adopted and this gets way harder with ercs where you know adoption is is one guy using it somewhere on the internet you know adopted or does it need some sort of critical mass and so i would much rather keep that out of the eap process the eap process kind of terminates at um it's immutable and then some other process can pick up you know tracking what people are actually using stuff like that like you know i definitely see

value in the community as a whole having some place they can go to see where the what are the ercs that people are actually using out there you know 1155 is used and 721 is used and 20 is used but there's plenty of ercs and no one uses and so um i do think there's a value that someone could provide and like you know have a website or something like that i just think that it should be outside of the scope of the eip process personally yeah i would agree the adoption can be different at different statuses though we encourage people to share reference implementation if they if author can find any uh to be added or shared in the erp but

mention of adoption is something that is after the standardization process is finished um i remember victor mentioning about leaving status um i'm not sure if we were referring to some other other blockchain but for ethereum blockchain i don't think that is a valid status that we are following for standardization process though uh there is one which is called living but that living is for only one eip i'm sorry if i got confused between living and leaving leaving is just for eip1 because we keep on editing it forever and that is the

only special proposal here for any other proposal it ha it starts from draft and ends at either final or um withdrawn i guess yeah either final or withdrawn that's the last status in stagnant they are kept there for unlimited um period of time till someone wants to pick it and bring it back to life but once it is finalized or withdrawn it cannot be brought back into the process okay we're uh we're about to run into a trouble with that with uh vm proposals since they now have uh we have a validation stage

and if you if you add new op codes that need to be validated um the validation for them will need to be integrated into the validation for all the other op codes and if you keep make you can't just do that with one eip necessarily yeah because you don't want validation defined as do this do that do that do that do that and by the way it's your job to turn them all into a single algorithm so a living document where you keep you keep updating the validation

constraints and algorithm as new op codes get added uh seems to be what we need uh or maybe that falls into the uh the uh core eips an executable spec world yeah but anyway you understand the issue yeah there's another issue i'm curious wouldn't you create a disney ip that says the new validation algorithm as of this hard fork will be x and just include the validation algorithm there you could do it that way you wind up with a pretty big stack of vips over time

but um you could do it i think with the next few little sec i think it makes me it simplifies that yeah this is one of the reasons i would like to see the next school is executable spec succeed um just because you all right there are situations you know where you're you're saying okay modify this fairly large and complex algorithm to now do something slightly different but that's slightly different may require you know integration in like five or six different areas within that algorithm and um having next google stack you know you can get a diff that shows you know okay here's the three three things you need to change uh from a reference implementation point of view um yeah which definitely i agree it's much easier but we're struggling with this right now because we have some proposals there's

some alternatives you know i'm being asked well can you put a pr in this other proposal to show how this is going to change and i'm like well sure but i don't see the point until we've actually agreed that we want this other one to go in and we've agreed as to what this other one even is but it's just sort of a mess and i'm not entirely sure how we'll straighten it out um i guess for this round we'll we'll have one document for the for the upgrade they're going into and we can we can work this out later but

it's the sort of thing that a living document might might handle so you have one place to keep going for the current uh the current set of constraints but it might be the damn executable spec will will be where we go and i think that's the next topic right it is there for executable specs i will go there but before we move on from this item i just want to summarize it for people who may be uh new for documenting their proposal or for future editors that they can follow this while reviewing the proposal so um from the discussion today it seems like uh eipa editors are on board with a

mention of final eips as well as withdrawn eips but not any other statuses because any other statuses can change is that the right summary that's like i said i'm fine with it as long as we retain the withdrawn withdrawn is terminal we'll revoke that or change that rule then i no longer okay with that okay yeah i mean as per the present eip1 withdrawn is a terminal status so um final and withdrawn are the two all right

moving on to the next item is core eips in an executable spec world uh i know uh from the last meeting we did discuss about the proposal that is already on the table by timbeko uh there is a solution fellowship of ethereum magician thread to share uh comments over there but uh i thought that we were also discussing to have alternative proposals i'm not sure if there is any and should probably wait and see if um sam gets back samsung's back in 15 minutes i'm guessing he's moving from mcdonald's to kfc yeah yeah that that makes sense so maybe we can come back on this uh topic if he's back in the meanwhile we can move

on so yeah this most important topic to me but um yeah because yeah sam needs to be involved that's right that's right he he just left a comment that uh he will be back soon it's important because it's moving quickly and i have i have strong objections or a strong need for for things to to change i i've been trying to read the cl specs and i can't read them and i don't want to go spend a week with a python book and even then way too much information is missing

reading reading it doesn't give you the concepts you need to understand it um but i guess we'll discuss that just a little later yeah welcome back on that topic i hope today uh if he's back within the time so in the meanwhile let's move on to the next topic so when he's back we are covered with the rest of the topics which are there for today's discussion um the number five is eip bart issues and eapv issues i know um jose has been working on issues um for both and the number he mentioned is number 53 and 58. i don't know who say if you have any question to discuss the

process or the approach that you were trying to follow to solve that issue uh you have a question feel free thank you well i basic basically i have just one question is well the idea for any author is to follow the eip one specs right i'm sorry if i if i i don't get this right okay why so

it's so is is is so much going on about helping the or supporting the author to to follow the eip1 spec export template for writing in the proper way the proposal i mean i can understand that the bot is is there to you know for as a definition set for simple issues but and and this is just a question is not supposed any author that want to make a proposal to to follow the the specs concerning the

all the definitions that you have there to feel followed the proposal i mean is something going on that to to make to make to make the question and just shut up and listen to you guys is is something going going on that above avoid the author to follow the mark the markdown format for the eip proposal in the ip1 or or this is just me that i'm so new and i don't get it i'm sorry that's it so i i think what you may be asking and correct me if i'm wrong here is um why do we manually enforce eip1 instead of having the bots enforce your

one rules is that what you're asking no and asking that but in the opposite why we need to to enforce the the authors that are supposed to follow the eip1 markdown template um i mean i i don't i i don't know i i don't understand it should be at least the the first requirement to to make a proposal that that you will feel follow the the ap one mardum form at least for the template whatever yeah so that that is you are correct that is a currently a requirement and the reason we have that

and loops who uh make sure the is you know when they show up on the website they're consistently formatted and easy to read once you get to know like how to read an ap so we want consistency like want all about the same and right now we do enforce that but the enforcement comes from eip enders when someone submits the pr the editor will go through and say please fix those three sixes please fix this it would be better if we had a bot that automatically did all this we just have not had the time to write a bot that does all that okay got it so so we can we can live with the

but we but the idea would be to [Music] ensure in the automatic way that the template and the markdowns yes are are fulfilled for the for the authors i mean fine i understand that but it's going to be always i'm correct me if i'm wrong it's going to be always a reviewer or any editor that is going to approve that right yeah and the editor so if we had if we had all of the automation that we wanted so bots did a lot of the work then the editor would just kind of yeah if you make sure they didn't have any like uh grammar errors or they didn't have you

know make sure it makes sense uh you know make sure it's readable uh it's not spam stuff like that but the less work that editor we have editors doing and the more work we can have about doing the better it's just writing bots is time consuming and so we haven't done it at all but there will the plan is to always have editors involved but we want the editors to do as little as possible like ideally the editors just do one read through and they said yep this is good and the bot took care of everything else okay thank you it's good good thank you jose for looking into issues um

if there are any for the question you can always uh drop them as a comment you think and i'm hoping that either the person who created the issue or any of the eip editors may be able to help you answer over there so that may speed up and that may not be a blocker for you to continue working on it uh i'm just trying to look into other questions here change to eap1 with a single editor approval okay i remember it now okay there was this uh pr uh that was um that is currently merged i believe uh

but i think i found a comment like why was it marched and why did not wait for author's approval i guess yes bug or i guess basically it's not a bug if no one feature request which is and that means it needs multiple gender approvals like it shouldn't just be one editor approving it should be like four or something and i have a little thing in there my proposal was just if the change to eip1 has been open for um it was just recently opened and it requires foreigners approvals but the number of editor approvals require

decreases over time down to one like over the span of like two months and the idea for this is to make it so we don't get blocked if we there have been times throughout the history of the aft editing process where we've been down to like one editor for a very long period of time on active vendor and so just in order to prevent us from getting totally blocked the idea is that the number of editors required to approve change to ip1 decreases the longer a change is open just so that if we've got lots of editors then you know we need more consensus if we're down in one of those dry spells where we have one active editor we can still make four changes though and then also if any editor rejects the the change then it should block

entirely so it shouldn't be like one person rejected so i always have to wait three months if someone actively rejects the change then it just stops right there and so there's a feature request out of the box great to have automation on but we don't at the moment and so if anyone's looking for what to do i'm a bit confused here i think i i made a pr on on eip1 i should have made it draft but i had and i was a bit confused in making it that it actually wasn't the right way to

change things and i think we were all surprised when it just suddenly merged i'd never actually approved it it seemed like just because i was an editor it it just said oh okay put it on in so i think i think in your case it was so there's two two issues here one uh if an editor authors an eip i believe it still requires one other approval but i actually did a proof of it because i i thought your change was fine i had to prove um mostly because i forgot that um as an editor if i approve your change via p1 it will then get auto merged i should have not approved it and just give it a thumbs up or something um so i take responsibility for that

when that was my bad um and this is again ideally if the bot was written doing to do things the way we want then i could have approved it and then it would have still sat and waited for sam or light client or alex to approve it and then you know once we got four approvals then it would merge or if we got three approvals and waited a month then it would merge or if it got two approvals and waited you know three weeks or whatever the thresholds are it would merge but the idea is yes that shouldn't have merged it was my fault because i hit the prove button there because i forgot oh okay yeah if he was not special yeah i think there's some other one that there's some other one i think i approved and it just sapped right in i'm

going what yeah it's not desired but uh it is the bodies of it that's what it's programmed to do exactly yes that's the problem with bots um for living like instead of special casing eip1 should we special case like living eips in general or um i'm okay with either one since eft one is the only living erp and the only living ip is the ip1 so eip1 should not change without actual discussion and consensus um i i don't think anyway

it's special so if i can summarize here it looks like uh this is a small bug on the bot side maybe we have to update the bot for make it a minimum of two approvals required to get it merged is that correct uh so we have two options one just minimum of two approvals required and that's kind of like the if we don't have time to write things well then that's i feel like that's more acceptable in the current situation and the other better option in my opinion is to have a thresholding system so it depends on how long the the pr is open for and so if it was freshly opened they need four approvals if it's been open for less than a month or sorry

uh it's been open for like two weeks and you need it drops down and even three approvals and if it's been open for a month then it drops down two and if it's been open for two months drop down to one and again the purpose of that is just to avoid a situation where you know four of the editors have disappeared and we're down to just one or two people and we can still look forward um but i agree exactly what greg said like if you want changes should get consensus if possible um so yeah i think in one of those issues that you linked i actually described um this and we just need you know someone who wants to work on the bot to go one of those two solutions yeah i don't like some complicated system of thresholds and times because then the

bottles still just do things unexpectedly because who can remember thresholds and times almost easier to tell just tell the bot never do anything to eip1 it's yeah so i would actually be okay with just as a the simplest solution um just update the bot to not touch eip1 or not touch the beam if you use either either one and that is that is by far the simplest thing requires zero programming or very little programming and maybe someone can just hack it out in an hour i don't know yeah that's right i think we have shared the issue here that is issue number 53 that talks about the tier editors

approval required for ambiguous prs here um i think the quickest fix is obviously to update the bot for make it minimum of two and then um i'm assuming that jose is already working on this particular issue so if we can come up with the alternate solution that micah has proposed that would be really good to have any final comment from anyone because i know we have left it five minutes and i really quickly want to jump to uh sam's part like if he has to share anything on execution later oh um i don't really have anything new to share on it i think there's the discussion thread that uh i've been keeping updated uh with proposals

um i think the only thing is that that might raise a few issues against the eip bot to add features um but that's it so far um yeah on that and um i i was uh wondering like uh in in the last meeting we discussed about having alternate proposal for uh the updating of uh the process the core eip process did you get a chance to look into that or uh yeah it's in the it's in the discussions thread all all right okay that sounds good um [Music]

all right i'm just trying to look what all we are left with and i think greg has some comments you want to discuss about the um executable spec yeah please go ahead with fort how fast is this moving i don't want to write a long essay i want to have a discussion because there's things i don't understand but from what little i've heard it it's just a terrible idea is it i guess sam wasn't here i i've been trying to understand the cl specs and they're pretty much impenetrable i

started with the beacon chain i pretty much understand the beacon chain i'm just going along and like this is just a heap of python i can write scripts in python i could get a book on python and learn enough of it to read more and even so i have to like reverse engineer the concepts from the python code and so anyone who's not a programmer that has no hope of understanding this and even a programmer is going the best they could probably do is just do a port from python to whatever language they're working in rather than being able to understand the concepts

and come up with an appropriate design in their own language especially if they're working in a language which is much more declarative because python's a very procedural language i've i've got eips that are basically almost completely declarative and there's an example algorithm but you could throw the algorithm away and the eip is complete the wasm specification is a few hundred pages of declarative spec and then an example algorithm at the end that specifically says this is just an example to show that you can validate these declarations in linear time but

the spec is all declarative you can't write such a spec in python so i just don't know what to do with that having having a having a client which is executable and is considered to be the reference client is certainly useful but having having a heap of python bd spec it's it's less useful than the yellow paper the yellow paper is really very simple mathematics it's just not well written so but i don't know where the meetings are to push back on this or if it's just going to happen and we'll have an unreadable unreadable

specs i think i think this is this medium is currently the best one to discuss it um i'll hand over sam but i believe the extrudable specs will have a human readable portion to them and i think sam we have some ideas on how that will integrate sam there um i just see a message from him it says that he'll be right back got a phone call maybe i can do one thing like we can bring it back in the next meeting if that's okay if he's not back in a minute or two so i will try to stand in for something my sam had on

so my understanding of the plans like google 6 is the x field spec will be like you said it will be reference client and there will be a requirement to update it so when you're writing a change to uh do it and so in your in your example you know you write you had a little reference implementation of your thing at the end and so that would kind of translate over to the the piece that you would add to the reference preferences or you'd work with someone who is you know python more from the python to handle that part but if i understand correctly the um executable spec will also contain you know some files um and again i i'll leave to sam if he ever returns to oh good thank

god sam i'm trying to speak for you and failing miserably um craig was basically what can you explain what your thoughts are found on how where the read of human readable natural language portion of eips goes and the x real spec world sure so there's there's two parts of human readable text that's going to end up in the spec there's going to be like the annotations on the spec itself and those will be stored as doc strings in the python code and that is going to look a lot like the annotated h2 spec um but i don't think that's what you're talking about i think you're talking about like the motivation and rationale sections um

go on i'm sorry oh no go ahead just go on okay um yeah so the those are i would like to store as um markdown files in the execution specs repository that way they're alongside the code change that they represent and um yeah i think that that's probably how i'd like to structure it but i'm open to other ideas as well my concern is specifications that need to be or are best written or the author prefers to write declaratively not here's an algorithm you can run but here are a set of constraints that these opcodes need to make

and you can validate the constraints or you can implement it the algorithm any way you like it just needs to meet these constraints and that isn't just annotation or commentary that's the spec um yeah i think that makes sense like i think the like prime example of this would be like if in the spec we use a dictionary to represent state right and that is absolutely not how any client would implement it so um and you're asking about pardon they go on i'm sorry oh yeah and you're asking how how do you say like what state is without specifically choosing

an algorithm that implements it um except more generally obviously um you know go ahead well i mean at 615 i i tried to keep very close to yellow paper terminology um yellow paper's never been expressed in python just in general i don't want people to have to learn enough python to read and write the specification python doesn't even have a formal spec python specification is is

is pretty much locked into a current version of python but to actually know the semantics of the current version of python you have to read its source code it's there's no there's no formal specification for python now we're just we're building on sand i i think that's you know a really valid point um and yeah i think it's a difficulty like we don't have a formal um like if we don't build on a formal base our specification isn't you know formal and that's concerning but i think you know the

primary use case for uh the yellow paper and the specs is not for anything formal but for um client developers to implement uh their clients and i think um python provides a firm enough base um to do that even though it isn't you know solid concrete or bedrock it's you mentioned the dictionary for instance it's very hard in a reference implementation to separate the essence of the specification to the accidents of the programming language it's written in so you go through and there's a

dictionary and it's like does it need to be a dictionary oh well what are they actually doing with the dictionary oh these are the actual parts of the dictionary they need that's a what data structure in my language should i use or should i design to do this best oh this algorithm is being expressed recursively in my language if i try and do it recursively i'll blow stack way too soon um okay what's what's the actual concepts here um so i can do it uh in an iterative way or so i can do it with continuations um you know the yellow paper is not an

algorithm it's it's a description of a world state and a set of state transitions and different languages have different ways to represent state and transitions and it's it's it's just me much easier to ask somebody to say go learn this little bit of very standard mathematics tuples um very simple uh very simple logic the math is so easy in in the yellow paper it's just harder you know i i would argue that given the target

demographic for the like client devs as a target demographic i think learning python i suspect for the vast majority of them is going to be easier than learning mathematic notation just because you know they're starting from a base of they're all software engineers like everybody who who is going to be looking at these and implementing these is software engineers they probably know one or more languages at least one of those languages is almost certainly going to be a um you know python-like language like you know python go rust c like that i don't know what they're called but that class of languages like everybody's going to be oh i only know scale i've never touched anything anything else like i think just

given the demographic like maybe if you're starting from zero maybe the mathematical notation is easier though i even question that but i can appreciate the argument there but starting from a groundwork of quartets i i suspect python is much closer than math which is why i i also suspect why many people complain about the yellow paper because it's written in math language and not in the programming language everybody knows so i kind of want to take what you said greg and split it into two parts um the the first being that um choices that are decisions that are made because of the language of the spec are going to end up leaking into um

downstream clients and uh you know i think that's a legitimate concern like for example like if we choose like a particular algorithm to implement let's say state again using that example then you know that algorithm might end up in clients even though it's a horribly inefficient algorithm and that's 100 a problem um i don't know how to deal with that i'm just going to say that right away like i think the pure note like notation that the yellow paper uses is 100 better in that regard um but to tie that into what mike had just said i think um the readability improvements and like the starting from a shared base among software engineers is is kind of the benefit that i'm wearing against that

and the second thing i wanted to say is um i i think regardless of whether we use python or formal math notation there's this step of translating the written document into a mental model of um how the like what the the spec is describing right so in in the yellow paper you have to translate the mathematical notation um which is algorithm agnostic into um like what the spec is saying to do um and then translate that with the spec you're back okay oh i'm sorry i didn't realize i cut out there so yeah basically i'm just saying that there's

sam is gone for me i think greg is disconnected can you hear me greg i i don't hear sam at all i don't know if anyone hears me oh wait i can hear everyone i think greg might have lost the connection you mentioned earlier he's having connectivity problems um is really good all right i don't know if you're gonna have a solution for this particular thing today or not

um i know we had a lot in the agenda prior to this discussion point so maybe we were running short on time for this i'm happy to bring it back on the agenda next meeting and that will be like in the first or second number so we can discuss it properly because this is a very um this is of higher importance right now it's going to be changing i'm assuming that sorry my connection dropped and i heard almost nothing that sam said what point did you lose then but don't start again probably sam would you

have the recording yeah we will have the recording greg maybe uh whatever you missed we will be able to catch it up over there yeah sam would you have a little time after the meeting for us to actually just discuss this yeah i mean sure um yeah we got more than 10 minutes worth to get through it's actually difficult for me to type right now right and i yeah i'm fine recording it it's just that i don't i don't know if you would want to keep this discussion be a part of making notes so it's fine i'm asking sam if the two of us can just take some time that sounds good

well any final closing for this particular topic from sam greg or micah i'm good for now uh we should probably if we're gonna put it on the agenda for next week which i do think is a good idea we put it earlier on the agenda so we make sure we have time um the first items definitely i'll try to make it a number one item so we will discuss this because there seems to be a higher priority uh with things changing moving faster we definitely should discuss that all right i know we are 12 minutes past the time we had a couple of more agenda items to be discussed i'm not gonna go through all of them just trying to share the information here for eips insight link is added to the agenda so anyone wants

to follow the latest update it is available over there and for eip editors apprenticeship meeting the meeting was organized yesterday the summary and the recording is added to the agenda the link is added there you may be able to follow that and for uh review action items um [Music] maybe we can look into the items quickly if there is anything okay i think all the items have been already taken care of but if uh if people come up with something new we can bring it back in the next meeting hopefully well thank you so much uh everyone for joining us and staying a bit longer i

know victor you joined the meeting but we did not get a chance to discuss your proposal uh if if you want to discuss it with the eip editors maybe we can add it to the next meeting agenda or there is another meeting called eip editors internship meeting uh that happens on tuesday at 1500 utc you're more than welcome to join that and share it with people so if you need any kind of review or comments you can do that sounds good thank you i will look up the context all right any final thing from anyone well thank you again and thank you again everyone for staying a bit longer on this uh see you all around

in the disc and yeah see you in two weeks have a good one everyone thanks everyone bye bye