EIPIP Meeting 58

Transcript

welcome to eipip meeting 58 i have shared agenda in the chat so let's start this meeting with the congratulating the new eip editor joining in the ethereum github repository his name is devin john we know him by panda p1 so he created pull request to name to be updated on the eip1 that is open uh if any other editor may approve it it can be done the other pull request to update it is yeah uh i think this afternoon

okay oh if it is done then it's cool i thought i checked it in the morning on my morning okay fine never mind that's good thank you no i don't see it i think there is another full request no number is 5156 um i'm sharing the link right here in the chat so the one pull request that has been that one that has been merged is like github notification but this is the another one which is to add him in the eip one so i hope uh this would be done and uh

oh he did his two separate pr's okay i was confused about that yeah yeah yeah and it looks like like client left a comment that it has to be in alphabetical order so probably he can update the pull request and then we can get atmos well anyway congratulations to him as well as to us we get one more person in the group i don't see him in the car but i hope he'll be around to follow the recording and leave his comment suggestions thoughts for whatever we are doing with eip moving on to the first item listed here in the agenda is a pr's need discussion panda peep left some comment in the last meeting agenda and i have taken it from

there the request was to uh get it discussed here in this meeting the first one here is remove greeting but i see comments from almost all editors and it looks like mostly people are in agreement though exec had a comment that also looks like it has already been answered so yeah if anyone would like to summarize the discussion may be to announce decision i'm just waiting to see if alex has any additional comments after responding to him okay that makes sense we can give it some more time to keep it there the other one is revised eip2535 it

looks like there is heavy changes done i have added it here because you know it was requested by panda peep to be getting uh to be discussed in the eipip meeting however matt and sam also looked into this pull request yesterday uh i suppose uh there was some comment left too so yeah if anyone else has anything to add here the main question is about the manual merge and one suggestion that i brought up like it should not be going back to draft it should be going back to review what's the question about manual merge uh so the eip editor he has proposed a lot of

changes and also requested that the proposal should be moved from last call to draft and if there is no response received from authors and then it has to be done by eap editors oh not not draft back to review um i'm generally inclined to leave it up to the author um to approve it like i don't like touching people's eips unless it's an absolute last resort and the author of this one is fairly active so i think we can get them to agree okay it's mud gen right yeah they've actually

they've actually commented on the pr so i don't think it's gonna need a manual marriage very well i think we have him on our discord as well categories discord so i will also try to ping him about this if we do not get any response in another week or two i think it just needs to be taken out of draft i think that's the only thing that needs to happen i think it has a few more edits from this yeah but yes it needs to be moved out of draft and it needs a few more edits that's it yeah shouldn't need a manual merge at all cool

cool thank you moving on to item number two that is eips discussion took place i have added this item just because there was some discussion on discord about fem uh or the e3 research i know there was a general agreement to have a fem as the discussion too and this morning i noticed that proposal 5133 they also have updated it to fem so is it uh generally uh fine like we will continue with fm or is there anything to be discussed here when you say ethereum do you mean ethereum research research that's right yeah sorry did i say um yeah so that was just a mistake i think it was overlooked the

i think the ip1 direct says it very explicitly ethereum magicians not research so whatever erp has that we should just encourage the author to fix it yeah i think it is it has already been fixed i saw that it has been merged so it is corrected there another thing like we were discussing this in the last meeting so i created an issue and i believe we have collected response from most of the eip editors and item number three which was uh seems to be like liked by most of the people over there i think it is already in action it's already done i think we can close

this unless someone has additional work they'd like to get done okay this sounds fair i mean we can definitely close it what is the last comment you're fine i'm fine closing it and uh thank you so much looks like uh after a long time i see issues as 15 it is in two digits i mean two digits but lower lower like tens and twenties it's very low yes it is becoming manageable right good thank you moving on that is item number three but

i would still like to skip it for some more time um we'll wait for another maybe a few items to go over before we come back to execution specs discussion skipping that item item number four is git badges uh so there is an issue link here in which uh the git boy up team discussed about how to be distributing it perhaps for uh recognition of contributors or maybe uh wanting them or make it memorable for them so for uh cathodes the link is live i have added the link in the agenda so whoever have contributed to the calories website or

to the eip ip repository pm or l2e will be getting perhaps um this is just a piece of information so please check out the live link and share your feedback and uh there is a proposal to provide a retroactive award to people who who have contributed to ethereum related repository which are not active anymore so yeah please check out the issue and if you have any comments thoughts or suggestion feel free to add okay uh number five is eips github commissions and support so i tried to reaching out to my usual contact but it seems like um i didn't

get much response from there so uh i don't know but uh the issue of spamming was communicated and looks like joshua who is also for the epdm.org he responded on the discord channel that he will be around to help on that so i hope to continue communication with him for any other issues that arises in future i am still working on sam wilson's permission for eip github repository i don't know i don't see tim here on the call otherwise i would have asked him if he may be able to point us to any other person who can be like faster in

response never mind um there is item number six about eip bots i don't see jose on the call so maybe we can skip unless anyone has anything specific to comment on no okay no problem the next one is eip's inside it's monthly eips status reporting in june today's 15th of june half month have already passed in june we have two eips 2464 and 2364 which were long pending proposals moved to final

six eips are added as draft and two new proposals are waiting to be reviewed uh i mean they are um they are being reviewed uh but there are some more work to be done on that site before it can be merged as draft a new eip editor gavin john i did mention earlier in the meeting has been added to github repository and there are more charts and graphs then you can check out in the report that is added to the agenda we had this eip editors apprenticeship meeting yesterday the recording link is added to the agenda i don't think we have any more items to

go over so let's move on to the item number three which is core eip in an executable spec world i know greg you mentioned earlier that we should be holding decision because we were not able to make that last meeting uh so yeah if you would like to maybe add something um i've discussed it quite a lot um and sam and i have discussed it uh one on one quite a lot so i'm i'm not quite sure where it stands do we do we have an actual eip for it well i'm look the link i'm looking at now isn't

isn't yet a pr yeah we we don't have like a formal um proposal like written up to change eip1 yet um i think we're still in the uh rough consensus phase among editors okay um so so like personally i think um i i'm still weakly in favor of making it mandatory for core eips but um you know i i don't want to push the issue too much if um we don't have rough consensus among editors so yeah well you need enough consensus with the all right the corey ips the core editor

blah blah blah the the core devs have to agree too because i have to read these things yeah yeah and and i think from from the discord chat we had a couple weeks ago i think people were very unsure and there was no clear direction from the core devs yeah we haven't discussed the broader community that much either as to some eips the broader community really cares about and most of them don't read python um the broader community doesn't really

read any programming language so yeah well a lot of them do but a lot of them don't and they do care um a lot of them i don't read python very well i i can't count how many programming language i can't count how many i either know or used to know python even i've written but it's like a process of soaking it in it's like okay now i remember um but i've i've tried to read like even the beacon chain spec it's just like i get almost nothing out of it it's like yeah if i was implementing it

it would be useful but as far as trying to understand it at a conceptual level it's it's useless to me i think no matter what language we choose there's going to be a set of people who do not speak that language um well yeah i know but unfortunate population right so like we have to accept there will be people who cannot um read the spec and the question is is which set of people do we want to exclude right but if you're asking someone to learn english that's of more general use than python um

but even more so there's things you need to say but i would argue you can't say certain things in python i'm looking at specs i've written and others have written um and others in the industry look at the wasm spec that there's there's one page of procedural specification and they even say this isn't this isn't spec this is appendix this is example the entire spec is declarative there is nothing procedural in the spec and python is not a language for writing declarative specifications my own specs it's english

but the spec itself is a fair amount of it is declarative it's these are rules you need to follow not this is an algorithm then there's in then there's yes this is an algorithm for checking that the code follows the rules but simply specifying the algorithm would be generally useless um trying to reverse engineer the rules from the algorithm would not be easy at all and asking everyone else to write to write the code from the algorithm

it's like yes you can just blindly port code um but it's you know it's really not fair to people to just say blindly port this code that you don't understand wait what's this you know and you could so i think the perhaps the issue is is i think when i think executable spec and the ei corey ip's moving over to executable spec i am at what i'm imagining is that people will still probably write some human readable portion um and that's going to be held i think in markdown files tentatively the plan somewhere um

and in that place you could still have your declarative specification and that would still be valuable the the only thing that's really changing here is that we're we're kind of rearranging where things live so that's change and we're saying we no longer will allow you to submit or we will tentatively you know request that everybody writes a reference implementation plus reference tests that that where the reference information passes it and in order for that to work functionally we need to have a shared reference implementation and that shared reference implementation is going to be in some language it could be go it could be rust it could be python it could be whatever and if we accept all of that which maybe you don't but if we accept all of that

then it's just a choice of okay which language is most likely to be approachable by the average developer and i do think python meets that bill i agree with you on all your points i think that python is not great for declarative stuff i think python is not in a perfect language i mean i hate the fact that it's not statically typed i love static type languages python's not um these are all things are pythonas are using the static typing stuff yep okay let's step up but nonetheless it's not the best i've tried it it's not the best static typer in the world but it's passable um nonetheless i think despite all of that and i'm not and this is coming from someone i actually hate i don't like python like i do not write python but i

do recognize that it does make for fairly readable code for the average person who you know if you just pick a random developer and you don't know what languages they're gonna they speak ahead of time or they right ahead of time there's a good chance if you show them python they'll be able to figure out what's going on and and that's why i think it's a good choice again this assumes that you still have your your declarative stuff somewhere somewhere in a markdown file in english most likely um somewhere this is just a way to make sure that every core eip has tests and a reference implementation which currently we don't don't get for a lot of them well you get them but you get them

further down the line when when teams actually start implementing and tests actually get written which is not necessary but the eip author is not necessarily qualified to do that um especially if they're not if they're not on a client team that's maintaining a client they really just can't do it um is there an expectation um sam or tim maybe for a draft proposal in this new executable spec world would the is it is it expected before you submit a

draft you already have pr against code or can you submit a a draft with only the markdown portion like ignoring like getting the last call or final or whatever just like to get started is the expectation that people have code or is expectation that you start with maybe mark down and you work your way up what's the expectation today if i submit a draft without the specification section what will you tell me or if my specification section say imagine uh i i guess we we allow it because like even this difficulty bomb vip the spec just i guess there is one line of code yeah i don't know so so right now if you didn't have a

specific specification section you submitted a draft uh but all the other sections are filled out i would probably let it through and probably i'd encourage you to fill it out um but i don't think as long as you had the section and you just put tbd in there i would probably allow it um i allow you people to put tbd in all the other sections i don't think anyone's tried to put tpd for the specification but i can't think of a reason why i would say no to it as long as they had i have said no to people who just literally fill in a blank earp because they're trying to number snipe and i'll tell them no you need to actually have something here like you can't just have a blanky ip that you fill in later um but if you've got like a motivation and abstract and you know

some some rationale maybe and all these other sections are in there but you just don't have a spec yet um i would be okay with that personally i don't know about the other editor well they have to be proposing something um but sure but like if the even the abstract is the proposal arguably it's just not specified enough to actually do anything with yet even the epsilon team expresses expresses their what they express in code they express in python but it's not it's not pr's against a non-existent rep reference implementation um because but that

implementation like isn't final yet well but even if it was it's not what they're doing they're they're working against their their c plus client um i've i've got some prs going which have code in in c and in sudo go at some point i would translate it but it's hard enough right now just getting algorithms right without translating it [Music] and i i really don't want to have to set up a python system on my machine and get

a client running um and understand the client well enough to make modifications to it it's just like that i'm sorry but this is hard enough work i'm not getting paid to do um and if we want such a thing it's i would just need a lot of help and cooperation from from a client team that's maintaining that client for any core iip i've at some point needed help you know from a client team uh typically martin recently um it'll probably be the epsilon team um if we decide to go with one of my eips

it just i understand we did it this way for the cl layer but they started out with a python implementation and the people working on it you know the whole style was was different it was a matter of starting with a working python implementation and continuing continuing to keep it going and we would have to get in a position of having a working python implementation and pretty much all the core developers all of them have it going they understand it they can speak it um then yes at some point it just becomes a bar to entry that before it before you

have anything to do with core um you've got to understand this but it's going to take time to get there because it's not where we're at and even so i i would resist because i just go it's it's not worth it it's i i would say no eips can be much more in the language the author chooses and this transformation happens further down the line and it's it's more like the yellow paper um there's a team of people that that keep the yellow paper not up to date enough but if that's a problem they need resources

we don't just abandon them so i'm going in circles i think i think my point of view is pretty clear by now right i think two two things that like still make me fall on the the python specs either one like unifying the like beacon chain spec and uh and and uh execution spec um like you know sure the systems are different today but like we're gonna merge in a couple months um there is you want the theorem to be like a coherent thing that like people can wrap their heads around

having to like having one python spec and then yeah one an until an unintelligible math paper that basically we rely on three volunteers to understand and upgrade um it's just really bad that they're not the same um and i guess the second bit is like i do feel like we're more bottlenecked by client developers than like eip proposals and that's been true for like the past couple years and again like it seems like from client teams like that i speak to like generally they prefer the executable spec approach and um yeah and and i i i simply like i think

we should try to find ways you know to make it easy for people to take part in this process and like you know perhaps have like very soft requirements around when this pr to the spec is actually is actually required and and i suspect if you have an idea that's like valuable enough and that your bottleneck like if everyone thinks the eip is valuable but the bottleneck is actually right in your prt executable spec many people will be able to help with that um yeah so i i don't know i i it is like a change to the process and for sure if like you you're working in the geth code base like it might be harder but i think like having a full specification not having to like rewrite weird parts

of ethereum in an eip um and having something also that maps from like the execution to consensus layer when you're thinking about a change that spans both sides um and as much as people want to say that it's going to be modular like i think like we look at the next hard fork there's changes spanning across both sides i think once you start having things like proposal builder separation you're going to have changes on both sides i mean all the sharding stuff influences both sides as well like it's much more it seems much better to have like a unified standard where you know the the sharding bit on the consensus layer specified in python but so is the way to access the sharp data

on the execution layer and it's on one place so i i i struggled to see how we just keep the two separate systems and like it seems like the system from the consensus their side today is like just much more approachable to people except this whole thing about like where do you put the the marked down text but that seems like a much easier problem to solve yeah we've got two very incompatible approaches here yeah um both of both of um well the eip process is a pretty long standing now um

they used to say internet time was seven years per one um no it was worse than that that's dog years anyway eip has been around a long time in the context of ethereum um i don't know um it just seems if we want this there needs to be an eip team and the people maintaining the ip client the uh sorry the people i'm not doing very well this morning i'm only into my first cup of coffee uh the team maintaining the python client has to step up to a lot of this at least for a while in the transition

because you'll lose people otherwise it may not matter but you'll you'll lose me um i i i cannot be maintaining a client and trying trying to make gifts against the client um that isn't isn't the client that i'm actually doing the work in um and of late that would be go uh or c plus plus because i'll be working with martin and or the ipsilon team so as far as getting executable code

unless they move over to python so maybe that will work out at some point will this python client be able to sync up to the mainnet or is it going to be too slow to keep up uh so we can we could do a block in about 12 to 13 seconds on like a regular laptop so on a beefier machine it should be fine i don't have a beefier machine well i do but full second i don't rush i don't i don't carry it around with me yeah i mean it can so like if you're testing individual blocks it's totally

fine um and i don't like why would you want to sync mainnet on just uh like your development machine yeah so i think that the the answer is is it is fully consensus compatible meaning you can sync maintenance it is not designed for performance so pragmatic i understand that to me it's essential it has to be able to do that or it can't be a reference implementation yes so it's it's capable of processing blocks and doing state transformations and you know all that stuff um what it can't do is do that fast on a low end machine so like someone could run the python implementation on a beefy

machine somewhere just to make sure that it's staying in sync and it's following extension rules but like this would not be a client that we encourage users to use because it's unreasonably slow oh god yeah definitely not yeah i'm not worried about that i'm worried about the fact that the operating protocol in the end is the spec yeah it's yeah i've said this if what's running there has to be specified um it's for the period of time any protocol is running that's what was running doesn't matter what the spec document says so if we want to document

what was running during that period of time that's that's what it was and so if if the executable spec can't actually keep up um it's not as useful yeah i keep saying you know i would love to have a reference implementation i think that's a very useful thing to have um but i would see it as a client alongside the other clients that like the other clients you know needs things need to get implemented and ready to go before a release and so the eips would would pick up python at some point

some of them right away some of them a little further down the line um so maybe before it gets out of review that's something you want to do um but not going into draft i think i'm weekly i don't have any immediate problems with having the process making it so the process allows for pr's against executable spec that only contain the markdown portion which is the human readable portion um this would be similar to you know submitting a pr that just contains comments um i mean the comments in this case are kind of separated out a little bit but

and again i'd like more input from others but my i don't have any initial problems with that and so that would allow i think what you're describing greg where you describe your your your eip in english or some customs uh declarative language or whatever and put that into a markdown file you send a pr against the executables facts repo which is where these markdown files i'm hoping will go i think tim disagrees but tbd they'll go somewhere you submit that pr and then as things progress at some point there will be a requirement to get the code in but that can be further along maybe you've attracted people with your great idea that are can help you with

the python or do the python for you um and so we would end up with reference implementation sometime before uh understanding people there has to be a team of people who maintain that client and part of their job is to work with the ips to to get to get them working and then there's a pr without sticking to pr and the eip can it can be huge sometimes i i've got a proposal it didn't get as far as a proposal but you repeat the pr against gath would have been huge it was a total rewrite of the interpreter but then it should

so if you have something like that and it's scheduled for mainnet obviously someone will help you write it but if you have something like that and like it's not scheduled like should somebody else than you who's championing it spend time trying to map it to another spec like i think it's like at some point like sure like i i have no doubt that like if we have an eip coming in and like there's no pr against the python spec and that's a reference implementation like the ef can have a couple people that like work on that uh there's probably client teams as well that work on it and that's basically how it works on the consensus

layer side you know we have a few people at the ef who spend time on those specs um but they're not like the sole contributors to them and if something's gonna go into our hard fork on the beacon chain like for sure those people if nobody else has stepped up to make a pr those people will like make that pr to the spec um but if anyone who has like an idea for an eip like it's just not tractable for any team to like implement everybody's random ideas it's like there needs to be some sort of gate and i think that's like roughly when we think something should be in a hard fork and i think then eip champions kind of have an incentive to provide this

implementation before because it probably increases the odds that their thing gets into a hard fork if more people understand it and there's a clear spec for it right yeah it's just at this point sometimes the idea is clear enough without code changes that it can get discussed for quite a while and the teams can go yes this is a good idea we're going to put it in sometimes it's this is a good idea a bunch of us who put it in it works it was a small change you know others you know i i could show up anyone could show up and it's like we've gone into geth and we've done all this and here's the change so they've got a big change

against geth and then it's like well you need a python change it's like um i'm sorry i've got this done i've got another job to do but then if it's yeah but if nobody else feels your change is important like you know you say today you make this pr against death but like what about baysu nethermine and aragon they kind of have to look at the get pr and they have to like basically interpret it and some of those client teams by the way can't look at a guest vr because of licensing issues so like i understand how it makes your life easier in this specific case but it's i don't think it makes the process better like i think if you look at like the process like having a spec that like

everyone can read um which is not like some client code is is much better because now what we have we we do have we have this this um um yeah we do have this weird like in between um where like the eeps are often underspecified and then like people end up looking either at get code or like basically finding out that they disagree on some under specification when we start writing tests for the eeps and um yeah it just seems like this is part of the process of getting a spec right yes that i've seen this before you

you get it to a certain point the teams can start to understand it and in then in the course of implementation there's push back on the author um this is normal and clearly written english is often of more use to a varied set of teams than at having it expressed in any particular language and backing up a little everyone says the yellow paper is incomprehensible mathematics and i just look and go it's badly written but the math is actually very simple

there's what i mean you can say the same thing about the python spec it's like it's but math is a universal language it's so it's not it's it doesn't matter that it's universal it's like who's like the people that you're reaching and like basically those people are like programmers who write who write specs for your theorems it's like if if you are able to read the yellow paper and like yeah i'm not concerned that you cannot like get to a point where you have a python spec working if somebody helps you it's like i think the level of skill required to digest i mean i know plenty of people who like contribute i mean

myself included like i've never read through the entire yellow paper and i think i can like look at the python spec and have a really good idea of what's going on um yeah i right i would push back pretty strongly like i think the yellow paper is like 10x less approachable than even this like weird system we have today which is like yellow paper plus a bunch of deep diffs um i suspect most of the newer core developers have not necessarily read through the entire yellow paper um or if they do so they basically read through like the get code on the site but like i yeah i don't think it's a way that a lot of people

intuitively reason about ethereum yeah you can go out there's actually a huge academic literature at this point of people going into ethereum who lean on the yellow paper because they're you know they're actually mathematicians and computer scientists um but yeah i i go to the yellow paper but when i need to when i'm implementing or designing and need to make sure that i have things right i go to the yellow paper right if i needed it it's hard work but i would i would go the yellow paper before i tried to go into client code because right but i think that's kind of the

thing it feels like there's a disagreement here where like you kind of refer to the python spec as like client code but it's it's not quite that like yes it it it does run and it does take the main net but like it's not like practical to use as a as a node on the ethereum network so it's like it's more like a translation of the yellow paper into python than it is like client code and i think i don't know i think the amount of people who will find that and i mean you know even assuming you know math and and python equally well the yellow paper doesn't really have diffs as well as well established um you know i i don't basically if you want to look at the

diff between two hard forks i'm not even sure that's possible because last time i checked uh it's andrew from from aragon who maintains it and like will typically add like an eip at the time because he does this on like a part-time basis so you need to like pull together like the set of commits that you think maps to a hard fork to get like a diff it's just like oh yeah yeah but it's like assuming the comprehension is not an issue i still think it's much less practical so so just just to be fair to the yellow paper i don't think there'd be any issue with generating diffs between hard forks if we follow the right like development practices on the yellow paper like it could be done yeah exactly so just prepare like we could add the tooling to the yellow

paper right yeah i mean exactly paper is also if we fail to maintain the yellow paper as a spec that's that's a big change that affects a lot of people much more than peop than i think we realize if people can't go to the yellow paper and say this is a canonical spec or but they can't after the merge they don't know like it doesn't tell you it might be a spec of the evm it's like you would you could strip it down but it's like there's no consensus the consensus of ethereum won't be in

the yellow paper after the merge there's also nothing stopping people from continuing to maintain the yellow paper like they have today like that status quo can continue to hold maybe they won't have the consensus portion of it but these people who are doing it today they're free to continue maintaining and the people who are reading it can continue using that as their resource okay it's this is i'll probably wash my hands of this at some point but this doesn't sound good um we're there's no formal spec for python either so we're building on sand

um but and it's not it's not literate programming um so it's certainly trying to be that's that's the goal okay it's not even close that is one should be able um given given the wide audience for the spec is the other trouble um you should be able to read the english and still get the gist of it i mean i can go into the literature with a lot of math that i can't follow when i'm

trying to just chase some computer science ideas i want to implement and if they're well written it's sort of you follow the english it's well written and then you kind of go math math math math math okay english okay i follow what he's doing math math math uh i'm not quite sure what the hell you know but that's how i read always but it's all python it's just it's like oh i can't get any traction here at all yeah i remember i just go through pages of python and just go i don't know what's going on here i don't know what the concepts are i don't know what the purpose is uh one would hope that i don't know you know i don't know which of this code is

because this is how you do it in python uh and which of this is actual spec so i think that i mean the the short answer to which is spec versus which is python is what is a what is externally observable um but that is uh kind of a cop-out answer because determining that is often non-trivial i think yeah i understand that i think the abs if someone who's writing one of these change proposals my hope would be is that they do have you know some english commentary whether that's in comments or if it's in like the markdown file as in the abstract

section or something so a person hopefully will still be able to approach these change sets and get a rough idea of what they're trying to do without reading the python now if you want to get details of what they're doing and you want to be able to implement it then you'll probably yes need to be able to read the python but if you just want to know like you know what is this eip proposing like the again the abstract comments those should be sufficient if they're not i would say that the authors are not doing a good job um like this the python i don't know maybe maybe that's too strong of a statement um let me take that back and think on it so maybe in the essence of time we can

maybe try to summarize this thing and look into probable uh next step uh i i am like in agreement with tim that having a unified process for el ncl will be good because el have been using the eip process for whatever the process is as of now but cl it is going to be a new process altogether to have an eip process in place so if we give them something which is closer to what they have been doing in the past i mean like the process that they have been following not the eip per se i guess that would be helpful and again again agreeing to micah that there will always be a subset of people who would be in disagreement so we should

we should understand that there is always a trade-off of new process we get something and we have to drop something it seems like the proposed process for using python is something that again in work in progress obviously we haven't built up the complete specs so far but that is that has made good progress uh sam and team are doing doing a great job over there and we hope that it will be really close to the main net spec and coming back to greg's point like uh maintenance may be a problem i think when a process is in place we would like to find people they they could be helping out maintaining it so if there is a challenge to just have it that they live in the python we can

definitely look out for people we can set out bounty if we don't get any volunteers or we can look into other options just uh but i think uh moving ahead with a general consensus would be useful and helpful on the larger larger context uh just a question for tim i i am assuming that um it was supposed to be discussed among client teams and generally speaking they are in agreement with the proposed process so i don't know that we've made like a formal proposal like obviously we've mentioned this a couple times um and i do think like what

so so so first you know like the pi spec is not is not complete yet like it's it's getting there but it's not like up to the main net yet uh obviously client teams are very busy with the merge so like the amount of time they can spend looking at this is quite small um i feel like what might be helpful is trying to list out like okay what is like the general approach what are like the concerns we see and and how we could address them um because i don't i like i feel like greg obviously you have like some objections and like we've gone around them many times but at some point you know we're gonna need to make a call and and decide even if like it's not perfect um

so i you know let's let's have that implementation first if you show up and say here we are we actually have a full working reference implementation of ethereum that clearly is doing the job um and but i mean they're basically there i think they're i sam you you know better than me but i think you're like at the verdant hard fork now right yeah we're starting we're starting berlin great so you're like a fork behind maintenance like substantive work behind maintenance basically um yeah but even get the and and

that's just code completion we haven't even started writing the like literate programming like greg mentioned so that that's a whole other right a lot of work to do yeah yeah but again that would be like in a better position than starting from the yellow paper as on the right because it would take another year or so yeah and i think i don't know if obviously like we're not gonna like we have a spec for the merge and this is not gonna be used for the merge um i think shanghai is probably like maybe the first fork which we could do both processes in parallel or something and then like realistically if we move to that it would be like the fork after that we

deprecate the other process which is still like much more than a year away yeah yeah um so i but that said like if yeah before basically sam and his team put another year of work into this you i think it's valuable to have like a general sense of buy-in from like client teams and also like a list of like concerns and like potential solutions to them and there's a bunch of like concerns that like we discussed about just like how the specs works but then there's a no this whole other kind of level of like shedding around like how the entire process works together um but yeah i

right yeah right i think we can probably use greg's suggestion here he earlier mentioned that there is enough no formal eip proposed for this changed proposal i'm assuming we could be um having a meta e because this is a great change in prop process and informational or any other eip will not be a good fit for it um so we may be looking for someone who can maybe propose a meta eep for this change process and then we take that eep to the client team asking for their feedback and suggestion would that be a right approach for collecting feedback i'm not sure that like i know sam what do you think yeah actually um so i think the reason why we haven't gone to core

devs with a formal proposal yet is because we wanted to have like not a unified front but at least have some rough consensus among eip editors on a final process and then we go to core devs and be like is this acceptable to you guys and we take up as little of their time as possible um but since we can't reach consensus here maybe we go to them with something a little bit less fully baked i would at least like to um so if we're gonna do that i would at least like to have the process the proposed process to find which i still think we're we don't have that either like even if we ignore greg's concerns um

like i still still don't think we're we're there i'm not suggesting concern for there to be a reference specification if it's in python that's that's wonderful that i would love for that that to be there i just don't want to push the responsibility for that back onto all of the ip officers you know certainly if i'm maintaining a client i don't want to have to deal with random prs coming in uh because most likely i'll have to go what the hell are they actually trying to accomplish with this

pr okay that's not a good way to accomplish it but uh now i i can back that pr out and do it the right way but um i can go on and on but you know first that needs to be there it needs to work we actually need to get through some cycles with it and then we can kind of go okay we have this thing it works we understand it yeah and we can start we can start to decide how to make a transition but we've got the cart way before the horse here so maybe a way to do that and like kind of based on

micah's point is like coming up with a process that we could use for shanghai and parallel to the eip process as like a sort of case study or something that like right obviously won't be perfect but we we can iterate on um i i i i feel like that could be a good way like it forces us to iron us iron out the kinks of the you know the executable specs um and um and obviously all the vips are gonna are gonna be eips for shanghai like we're not gonna have this be the official spec but like i do think this gives us also like a month or two

easily before um meaning like the shanghai for sorry oh yeah yeah i think yeah this just gives us time and maybe we can talk about this on the on the next call but like i feel like yeah maybe coming up with a process that's basically a dry run for shanghai that would happen in parallel to the normal eip process um yeah i find it a very good idea so as of now like as sam was mentioning that we were trying to reach to and edit its concerns as eap editors consensus before we it can be proposed to the client devs we have as of now four eips outer editors out of five and now six

so what i can do like i will try to reach out to these two editors who are not on the call and try to uh like get their feelings where they are and in the meanwhile if either sam or tim uh we can have a proposal to kind of propose this new process as proposed by tim that it can be done in parallel for shanghai i guess that would be a good trial run even if anything goes wrong there should not be a problem because we have the other process in place right what do people think about it i'm happy to help with that if others want to too as well

okay uh so uh the proposal that is linked here is a hackmd file proposed by tim um one final question uh is like are we planning to create this eip based on this or is there any change in the proposal because if i remember correctly there was a minor change which was discussed in one of the earlier eipip meetings so where do we stand there yeah i think i think i have a separate hackmd that's posted further in the discussion thread that might be a better place to start um yeah yeah okay um if it is not too much of a hassle sam would you be willing to maybe propose a

uh proposal based on your hack md and tim you propose a proposal on your how can we that'd be i'm happy to work with sam and like go off his his proposal and and yeah um i guess we can use the eip editing channel is that okay in the discord or is that like an abuse of the channel um i think we are trying to change the entire process of vip so that should be the best channel okay yeah we can use the eip editing channel and and yeah coordinate on that so one thing i want to ask um which eip editing channel is the one to discuss this in the rnd discord yeah yeah yeah and just because i i think some client

devs might pay attention there whereas like i don't think any of them are are going to hang out in the cathedral's channel um agreed that's right yeah i mean if that is uh something on like ethereum level we try to generally discuss it on the rnd but if there is something discussed on a subset level then we try to move the discussion to cataracts but i'm happy to share that all eip editors are on cathodes so if there is anything missed out we can probably share it on both the channels that should not be a problem okay just to maybe summarize this we are on agreement that we would give it a try to the new process there would be one meta eep that maybe some if i'm not putting you on the spot we'll be

proposing yeah and having some discussion on that we can take that proposal to client teams collecting their feedback yep sounds good all right thank you we are almost at the time two minutes passed but good that we we did great on this discussion because this has been there for some time and i think we already have covered all other items listed for today there was just a one action item section and i'm looking into it um one action item that i could not finish it up maybe i will bring it up in the next meeting that was a collect feedback regarding one time nft sale of unused eip numbers so i will try

to reach out to uh people and collect some feedback and then we'll bring this item in the next meeting and rest all seems to be covered well thank you everyone for staying um a few minutes longer on that call i hope to see you all in two weeks the next meeting is planned on june 29 at 1400 utc thanks everyone have a great one thank you thanks bye