EIPIP Meeting 55

Transcript

welcome to eipip meeting 55 i have shared agenda in chat the first item listed here is core eips in an executable spec world um we have added the proposal to the agenda so this item is under discussion for the past few meetings now and there has been some async communication also it can be found in the fem link which is added to the agenda in the last meeting that's right that's right uh sam i i think he said he will be joining and today we are expecting oh greg is also

there but looks like he's greg's also missing let's come back to this one after some of the others that make sense we can move on to the number two and we hope that sam in the meanwhile will join also greg will be back too so the item number two added here is discussion items from different issues this is added on the request of a community contributor panda pip1 though he could not join the meeting today he did mention that he will be following

the recording and the list that we have here is of open issues and pull requests at different ethereum repositories based on his priority what he thinks will be of priority i'm gonna just read them and maybe eip editors or anyone who is working on these issues um if they have any updates they can share it or maybe propose any possible solution the first one that is a bug currently and is of higher priority it seems updating workflow files should use stricter rule and the issue link here is eip bot issue number 79.

so this uh issue i mean this particular item i think we discussed it earlier i i see a lot of like a comment going on anyone has any date there or would like to add anything on that all right i think this is about the two editors issue right currently only one editor can add or remove any of the existing eip editors and we discussed it in one of the earlier meetings that we should have at least two editors or more approval needed for uh making this function work i'm not sure if we have got this uh done

yeah i always need someone to do it a lot of these are i think find them we just someone has to simply take the time to do them that's right i am also expecting some more people to join today maybe um one of them um may be able to help out with this though we already have someone also looking into issues we can find the comment there okay definitely we know that this is one of the highest priority items so if if someone is available to work on that we will make this off one of the highest priority item to look into i i will comment about it when we we go to the eip boat

section in the agenda seeing that is the next one okay okay that sounds good um mike i just curious um do you want me to go through all the items listed here or is there anything that we can pick it up particularly i mean i'm happy to read let's see uh let's just go through it the next one is cannot delete files in asset folders so and again this is already added to eip bot um repository i am expecting if jose if you may have any updates on that you can probably share it and if not then whoever will be joining

uh to look into these issues maybe look it at higher priority the next sub item listed here is eip 5069 eip editor apprentice handbook in eip form so recently we have noted this new pull request number is five zero six nine uh this uh user he has documented a hack md file created by me where i have collected all the information related how we can have a new eip auditors on board he is trying to make it as a meta proposal and he has put it into a

template that is available for creating any uh eip i'm curious to hear what what are the thoughts of eip editors here my thoughts are the same as always with meta and informational aips i feel like they should go somewhere else but as always i think i'm alone in that and so if one of the other editors wants to merge i won't stop them um there was a really long discussion of that which i didn't participate in i'm sorry um amsterdam and preparing for amsterdam and recovering from amsterdam took up

all my time but eips and ercs have been in the same repository and used the same numbering for so long i don't see any hope of changing that yeah so i don't know i don't i don't think this proposes a change that doesn't i i've really lost track they need to be divided in some way just because there are so many possibilities um for ercs so there's lots of them and there's just a lot fewer core eips and a lot fewer

people who are competent to really understand them and well like for myself they're the only ones i'm interested in reviewing well this particular proposal is not related to eip and erc probably we can discuss it when we go back to item number one uh we were waiting for some more uh participants to join so we skipped it but this particular this particular proposal is about how to onboard eip editors i got lost while i was pouring my coffee so we'll come back to that i'm sorry not a problem so yeah if there are any other thoughts on like uh do we need this kind of meta

proposal or first of all do we need this as a proposal because this was just a hack empty file that we were sharing earlier yeah and if we want to like kind of uh formalize that we may use some kind of eip and if that at all it has to be an eip should it be informational meta so yeah it didn't used to be that formal but there was simply some discussion among existing editors and a consensus reach that a new person should join um and it was loose enough that i recall simply adding macaw out of frustration that there didn't seem to be any other editors but me for a while

um so it'd be good to tighten it up a little but i think there should be some consensus of all the existing editors um it doesn't have to be a big deal or a formal thing wondering if anyone else has any thought i don't see sam on the call but yeah lifeline if you may have any thought on this yes tim please go ahead uh i'm not sure

if lifeline okay okay he's using text please go ahead tim yeah i i is this about essentially this is about like adding another eip editor or this whole erc so this is about adding eip editor uh the proposal here is like whatever hackamd file that we were referring earlier where it is documented how we are doing this the internship program how we are running it and the steps that we are following to onboard an editor uh he is just proposing to have these things publicly available not in the form of hack md but in the form of eib may be stored on the eip repository so uh just curious to understand what

people think about this particular proposal i don't have a strong opinion but it feels a bit weird as an eip but yeah i'm i'm not sure why i'm not sure i can articulate why it just feels i guess because it's like a process thing and not like um yeah not like a actual ethereum thing but it's a very strong opinion right yeah and and this proposal is proposed as a meta eap which is again for all process thing

though i am also not able to comprehend it completely this user has used my document and he reached out to me that is it fine to have him added as an author obviously if you are doing the leg work if you are championing a proposal you have to be a co-author of that maybe we can wait for review comments from other people like other editors because it is already added as a pull request we can expect something going forward okay all right we can move on i suppose and the next one here is force usage of included license file and they have added an issue

on ethereum eaps repository wondering if anyone has start i here comments on it already okay okay so a few meetings ago we uh mentioned that if there are anything that people would like to be discussed in eipip meeting they can probably list it here on the eip's repository issue issues section because we are strongly discouraging people to create an issue for eip's discussion so all the issues here are

listed from there feel free to drop a comment over there on the issue that is linked if you have any opinion strong weak whatever but whatever can help us close these issues faster similarly i see there is another issue created that is for automatic redirection of old type urls um i'm not using issues um i keep getting confused on just how to introduce an eip um especially corey ips because we have

a section on the magicians where discussions of core eips go but in general um you want to you want you may want to introduce discussion of an eip before you've actually introduced one uh with a pr and asked for a number and so you get in this loop where you can't you can't start the discussion of a core eip with a number until you have a pr with a number so you wind up in this loop and the issues made it possible to

to get started on a discussion with a number that you knew was going to be assigned and start the discussion in the correct place in the magicians and uh so you you can start you could definitely start a discussion in the magicians forum um you're correct you won't get a number um is there a reason you need a number to start talking about it um look at the core section of the eips um and i i think the uh the uh earl there includes the number or somehow related to it so so you can't you can't really get something started

there until you get an eip number it's not cause i believe there's i don't believe anything stops you from creating without a number and so you should be able to and then i'm pretty confident that we fixed it so you now can edit infinitely like you're no longer limited to only be able to edit within the first like 10 minutes or whatever so you should be able to just create create it with a description as a title fill it in talk about it and then once you get a number you can go back and edit the title to include the number so where do you put your initial draft of the eip before you're ready to actually you know actually make a pr on the repo ethereum

magician's thread that you create just like in the original post like then we fixed the issue that you brought up that you couldn't edit i agree i agree with you that was definitely not acceptable um so that should be fixed okay so you should be able to iterate it on it right in there at this point okay so that's been fixed yes if it's not fixed let's let me know i tested it and it worked for me um but i may have more permission so it doesn't work for you definitely tell us because it should be fixed okay well if you can do it there and keep editing it to keep it up to date um then and then remove it and put a link to the actual um the actual draft when the time comes that works very well great thanks

definitely let me know if it doesn't work right i'm sure it does it's no big deal if it doesn't it's it's mechanical yeah we hope that issue is fixed uh i see daniel um muted unmuted do you do you have something to add here i know you are also working on an eip right yeah i was just going to say i know you can create draft pull requests uh that you know that might be a way to um have a draft but not have it being reviewed or

clogging up any kind of processes and you could just point the discussion to that draftful request in magicians until you're ready to make it official but it sounds like that's not the only way to solve this issue right that is also a very good point because earlier when we used to have draft draft was the only status before it can be moved to last call now that we have a review as a status so people can always create the initial pull request as draft and when unless they are ready uh keep it in draft and once they are ready uh they can move it to review for editor's review

yeah i'm just thinking of the ideas that are often vague enough they're never going to get to an eip and you don't want to clutter up the repo with draft pr's um issues used to be a good place to say i think this might be a good idea for an eip and start a discussion and that's a magician's is a good place for that to um all right make sense okay going back the plus the the whole pr process is difficult enough that the people don't want to have to learn how to do it until

they have to right all right uh going back to the um the last item it was five zero five six i i know that uh there are a few comments related to this particular issue that is already available in the link that is provided in the agenda so if anyone has any comment or suggestions to handle this one please um uh look into that uh no tim you did not miss the first item we are just coming back on it uh because we were waiting for some more people so we thought that we can quickly finish this up i think we'll take another five minutes or so and we should be going through all these

uh small items and then we'll go back to our item number one again um the next one uh is the mud ethereum cat herders into ethereum org repository i suppose this is a very big proposal it's good that we have many people on the call would love to hear thoughts on this particular item i know i had a chat oh yeah let me first mention this i had a chat with tim earlier and we were thinking about how to make sure like the we can have a backup of some of the important repos of ethereum categories repository and we did discuss about eipip to be considered one but i'm not sure like it was discussed to move all together

into ethereum um yeah please go ahead micah sorry for introduction i i don't hold a strong opinion on this either way but i don't see a clear or strong need for it so for me i don't i would like to see more on why this would be beneficial like what would we gain from such a move yeah that is an interesting point and i would love to hear more thought on that uh though i could not uh connect with this person like to have a long chat he said that his availability will be more uh in next two weeks he has some exams

so maybe when he's around or if we have more information on that we can probably bring it back um but yeah if anyone has any any kind of opinion like whether it should be or it should not be they can definitely comment on the issue that is listed here and i find a few more items three more items that is like already listed here and one of them is um a bug which is again eap bot i think we can cover that in the next item it is eip issue number 77 so we can probably uh discuss it over there

okay all right so in the essence of time and now that we have a lot of people here to discuss item number one maybe we can go back to vitamin though we didn't have samuelson on the call yet um i'm not sure if he'll be able to make it though we have left a message for him so let me go back to item number one and see uh what we have since the last meeting as i was mentioning that we have been discussing this item for past few meetings and uh we have a lot of discussion so if anyone interested they can go back refer to the recording of earlier meetings uh from the last meeting it seems like uh greg colvin has some concerns and we kind of discussed uh

that uh what is the current situation with the python specs as well as with the people who will be able to understand the um yellow paper ethereum yellow paper it looks like like current availability of resources uh such as that moving towards having diff to python specs is comparatively better because we have more audiences who can probably understand python than who can understand the current yellow paper but because greg was not there last time so we wanted to bring it up again to the meeting today so yeah feel free to share your thoughts opinion concerns me um

yeah i spent a fair amount of time with sam wilson going over that kind of view 615 just as an example because it's fairly long and brought home some of my concerns sort of the central concern is just that python is a bad language for declarative specifications um and you know 615 as an algorithm for instance for validation but the specification is almost entirely declarative if you look at the wasm specification

it's a hundred some pages of totally declarative specification it has a very short algorithm at the end for validation but it specifically said that's not part of the specification um so having python code for implementing uh a spec doesn't work um as the spec itself and right we already have that for the beacon chain though like we kind of have a counter example that it does work great and i mean sam's stack works to implement ethereum basically all the way to

constantinople now so i guess i i'm not sure what i'm not sure understand what you mean but like it doesn't work to implement the spec if you have a reference implementation yes other teams can basically port the reference implementation um but you can specify things without writing the code you write declarative specification and then any code that implements that specification is satisfactory and if you're using a procedural language like python the port is relatively straightforward if you're using a

non-procedural language like i guess haskell you basically have to reverse engineer a declarative specification from the python and then implement it from that and is that are there any clients for whom that would be the case we went back to 615 um and to go from the algorithm to the spec you just wouldn't get there the spec provides you know rules on on how you must write

your code and you know in order for the code to be safe you must follow certain rules the stack must be laid out in a certain way things like that and the yellow paper can specify things declaratively because it uses fairly ordinary mathematics the mathematics it uses is really pretty easy um topolous and set theory um so you're saying it's not impossible it's not possible to say specify something like eip6150 615 in an executable spec like

in python is that is that right um it would i wouldn't know how to do it um i don't write python very well at all like i can you know i can put together simple scripts and struggle through struggle through the beacon chain code but languages we have for doing declarative specification are basically english math um and uh that's about it for our team there's formal languages that people use but they're gonna be even harder than python english generally works pretty well and eventually that winds up in the

yellow paper right but i think that one of the challenges when we talked about this about cordevs with like english is uh martin brought up is like it leads to a bunch of eips being underspecified right like whereas like if you have to actually work through like a full implementation you by definition have to like specify it in code um and then the question of like you know python versus other programming language i think is a bit like orthogonal to that but like i think from like when we presented sam's work on our core devs there was a pretty strong consensus that having like a spec which is in code provides less ambiguity and one of the annoying things for client developers is

when a new eip comes in and it's just like underspecified and they actually have to like figure out what the author of the eip intended um based on kind of their english or like declarative specification which which doesn't have everything yeah i understand i worked i worked with a couple you know formal analysis experts to go through that and and get it as correct as possible and off to the side we we did have some you know some formal specifications but they wouldn't help most of the core developers either partly if we want to do this i i'd want

to have a person or small team of persons who's willing to work with people doing core proposals to help produce this python it wasn't clear to me it wasn't clear to me whether this was a full implementation of the client so you you could actually test it is is it a full implementation yeah it is okay um then we get the hassle that the initial implementation is likely to be in some other client um i you know work i do

would probably be either in the c plus plus client or the go client so i might have a pr on a you know complete implementation but it's not going to be the python client especially if i'm doing performance work uh on geth or something it's it's going to be irrelevant to python um but there i think there's two things there so it's like sure a pr that improves death performance that's not like a consensus change right like it's a it could be gas engulfing for example you need to know what like we're not going to use the python client for figuring out how much gasoline should cost no sure but i mean you're going to need

to use if if you're pricing gas for upgrades you're going to need to check multiple clients anyways right so it's like it feels like there's kind of a weird gap where like yes you know like you may choose to implement something and go first because like you're more comfortable there like the base you team would tell you the same thing about java but like i think it's the question is then like what does the full specification get written in which is like different from the actual client implementation and and i think the goal here is we can have the full specification written in python rather than like english or pseudocode basically which is like

kind of the the case today i've got i have eips in progress which are declarative english which once it's worked out will be a complete specification you don't need any code for that specification to be complete it's english so that's that's problematic but using using a formal specification language is also problematic um wasm solves it by having both english and formal spec and a promise that the two of them mean

exactly the same thing and that took some very good people to do that they don't have a reference implementation as far as some eips i currently have on the table the reference implementation will almost certainly be and go because i would want have been and would want to continue working with martin in the caf client and or the turbo caf client so by the time i'm done i have a working tested implementation and then if i'm told oh you have to port this to python i'm going to go

i put a year of work into this go and i don't really know how to write python very well and so i'm sorry what am i supposed to do learn python well enough um to do this no i can't i think that's going to be true no matter what language you choose so anything we choose there will be a set of people who do not know it so if we choose python there's a lot of people who don't know the python features go some people who don't know go if we choose f there's going to be some people who don't know f like uh i think that is an unsolvable problem like the fundamental kind of underpinning of what you're getting at and that leaves us the question okay so which which do we choose and we can we could choose a

uh like a formal formal something you know r or whatever it is or something it can be formally specified the reason for python i think is just that it is the most likely language that most people will be able to know or figure out like it's it's a i mean there's a reason people use it for teaching right because it's relatively simple and not too complicated doesn't have a lot of weird edge cases i mean it's not a perfect language i don't use it for example um but it's not hard and so i i think that i mean my argument here is basically that we're not someone's going to be unhappy in this case it's you and probably some other people as well i'm sure there's other people that don't want to write in python but i feel like this is

kind of optimizing for the least total unhappiness across the core dev space no you're not getting it i'm sorry um well so then there's i think there's the other aspect we're saying i do agree with which is that a declarative specification would be better i agree the problem is is that we getting someone to write and maintain a full declarative formal specification for ethereum is hard like the yellow paper was supposed to be that and it was totally under maintained no one could read it i shouldn't say no one many people struggled to read it and we want something that's approachable and accessible and so we we have to make so the choice the question is is do we make a sacrifice

in like we were sacrificing what you said declarative is better but we're sacrificing that in order to increase accessibility and approachability and simplicity and things that people are more likely to be familiar with and and again i want to make clear i do agree with you that something formal would be better if we had infinite resources and we didn't have to worry about like ramp up time and onboarding time for new eip authors stuff like that and so i think it's python is just kind of an optimization for lowest common denominator i guess you could say it's worse than that i have eips that cannot be expressed in python an algorithm for validating

that code follows certain rules can be written but reverse engineering rules out of the algorithm would be very difficult stating the rules in english statement right my information would be to write write the rules in english or whatever you're familiar with like you can write them in the eap i don't think is limited to only having the python it's just it must have at least the python and so you could write your ap perhaps initially without any of the python you'd author it get it as a draft like you might not allow it to go to reviewer last call without the python implementation but i definitely would accept a draft without a python implementation and so you can you know write it in something you're familiar with and have a declarative all that and then maybe as a later step once

you have you know you kind of sold some people on it someone can come in and help you or actually do the python implementation so that it satisfies the requirement of it has to have the uh python update that's my my thinking um may have other thoughts on that though because process wise yeah that lines up with what i am kind of imagining does it make sense to have a pr that doesn't actually change the executable spec as long as like i mean as long as we okay because like uh there's a couple ways you could do it right you could do it so that you just

make the markdown file and um don't make any changes whatsoever to the executable spec you could um make the markdown file and change the dock strings of the relevant functions which i think doesn't really require knowing much python just just enough to be able to find where you want to make the change and i think you know having different levels of like like i don't know where the line should be drawn maybe zero python is probably the best option but yeah there's different places you could draw um um i can't i can't do this it's just

but one thing so i could look i could show up with an eip that uses english and you know whatever seems appropriate to present the idea clearly enough that it can be implemented i might at some point and i might not do it until i first get it to cfi then finish off a complete working implementation in one of the clients and damn that's a lot of work already and there needs to be a complete implementation if you're doing something that's

supposed to improve performance you need to show it does prove performance in the important clients at that point you've done a lot of work and then you're told oh you've got this go code oh you have the c plus plus code oh you have this java code and before it can be any ip you must translate this code to python um and it's i'm just like no that's too much work well i think other team no really if another team who is the python team says don't worry we're the python team now we'll work with you to finish off the spec um

but it really seems up to the core devs themselves uh weather respect is ready for them to implement whether they really need this um it's not really for the eip editors to to decide what the core devs need that the original concept was you know pretty much that the core devs are operating independently enough of this process um that it's up to them what what they find acceptable um so i think that part of the reason that things came about is the frustration from the core devs that we have a lot of core eips that are under-specified like we don't find then people implement them different ways because they're written in english

and so this is a an attempt to solve that problem fine i i can with i can just withdraw some eyepiece um or or ask for a lot of help um i think it's okay to ask for help right like because in practice this is what this is what everyone who's not a guest dev does today right like they have an eip that they come up with and then they have like a specification which is usually english or some like underspecified format and they usually need to get like help from one of the client teams to like actually implement this in guest or at the very least review it or

or or whatnot and i think like i i i see your point that like you for a draft or something it's probably reasonable to not require like a full full python implementation my personal line would be like for us to move something to cfi you would probably want to have that and and then it's like by then you know if if we're actually thinking about moving this eip to cfi there should be somebody who's willing to like help you with like a python implementation if you can't do it yourself um but it seems like sure like for for drafts and for discussions i i appreciate that that creates a ton of useless overhead and and like we shouldn't impose that on

people um but but yeah i i think like uh to move to cfi or at the very least like to move to be included in a hard fork then you make that like a hard requirement and other people at that point might might be able to help if like the eip champion is blocked by that specific task which is the case today for a bunch of eip champions for say the actual say death implementation or other kind of improvement issues well also the people who are maintaining the python client sure but you would ideally not dump it all on them um i think it's a bit unsustainable to say like

yeah the people maintaining the spec need to be the one like i think it would be good to have the norm or it's a bit of a broader set of contributors um okay well again you can write entire specs and depending on the subject of the spec they often need to be declarative that the specifications are declarative and python is a bad language for doing that and i remember this discussion years ago on the c plus committee there was a lot of pressure for us to to define it with the formal language um i think z was the popular one at the

time and there would have been advantages uh the problem was that we would have a specification that very few people in the world could actually read and we decided to go with english ordinary math such that people could actually read it and there would be some ambiguity so it would be a job we we had a small subcommittee whose job was to disambiguate the english if when if and when issues arose um and you know in our case we were specifying a language so examples and such would be in that language and when we could we'd specify

things in that language but um i don't know it's 615 remains an example there's there's a validation algorithm but you could slice it off the proposal and formalists were able to go through it and write complete formal specifications based on the english help me get the english cleaned up and uh it's a totally adequate formalization and writing a validation algorithm in python um rather than a pseudo c um fine it would be more readable and it would not be a specification you'd have

to re you would have to reverse engineer the specification from the python definitely for something like 6.5 i definitely don't think that you should remove the specification you have like the english language version the i think the only requirement here is that there is also a python reference implementation functionally like this did not preclude you from also having you know better stuff it's not even declarative language something in english something and i don't know whatever the popular declarative languages are these days like that's acceptable it just also has to have the python reference implementation so basically to write that i would i would have to learn enough python

uh to write what might be a fairly difficult algorithm yeah in python and learn learn wait a minute and learn how the reference implementation works well enough to make a pr even if the pr actually involves fairly substantial changes to the reference implementation you're asking an awful lot of people that unless there's you know unless the executable spec team itself is willing to help when i'm working with the geth team when i'm working with the c-plus plus team

and they think it's a good you know a good thing to do or to investigate they help me you know i'm not i'm not left alone i suspect that would still be true for the python teams as you as you put it i did the reason i don't want to say you will get help is because i want to avoid the trap of saying every single person who wants to draft a queer eip gets a slice of the python team's time like i want to make sure we don't fall into that trap because there's you know hundreds of vips that never make it anywhere and they're terrible and we should not be dedicating resources to those people there are definitely some eips that are going places and we want them to be included like i don't know let's take one five five nine as an

example because it was very popular like for that it would have been pretty easy to find someone to do the python implementation or help you with it 615 may also fall into that that's that bucket there are a number of people who are interested in that we just need like one or two of them to you know help out or the python team maybe interest themselves and they can help out i don't think anything precludes you from getting help from people who are familiar with it it's just i i just want to be very careful we don't promise that because that can lead to worse problems i think well at what stage then at what stage are the core devs insisting that they have some python before they'll go to cfi

my my personal preference on this is that it is acceptable to approach the core devs with an idea that is you know reasonably well described and ask them does this interest you and if we if i push this through you know is that likely to go through or is this going to be something that no one wants to implement and i think it's very reasonable to not have a python implementation for that i think once you cross that phase i would argue that the next one of the next steps before it gets implemented all the clients is the python reference implementation again because the idea is we want to make it so it's relatively easy since all the current clients are procedural it's relatively easy to port python to them and so i think that's why we want somewhere between between the

core dev say yeah we're interested in that and the coordinates say okay we're going to go implement that we want the python implementation and that's my personal preference i'm sure other people have other videos and so that would be just like process wise that would be after something is cfi so like take 615 as an example we could say we consider 615 cfi for the next hard fork as as is like with just the go implementation but then prior to all the client teams or like in parallel perhaps to all the client teams implementing it and prior to it being like officially part of the hard fork then you make it uh you have the python implementation and i think this also has the needs property that you get different people

who can review the python implementation like as things get included in hard forks and and that's like a valuable thing um yeah well so you're saying it's not acceptable to show up um with you know with it working in any other client well you're gonna need like you're gonna need to show that it's a good idea right like and if the way for you to do that is showing it working in another client because say it's like a performance optimization then like that's kind of the way you convince core devs that this is actually worth doing but i think from that point up to like

before everyone has done it that implemented it then is when you also need to get it done in python either by doing it yourself which at that point the next i can do it and again at that point it should be a bit easier to do that because other people should want the cip to also go in the next hard fork and be kind of incentivized for it um yeah and one of the reasons i guess why i'm pushing so hard is also is like i think there is like also a large set of potential core eip champions who are not client devs and for who like this is much better like i was talking with uni

swap yesterday about their eip and they struggle uh to like get it implemented in guesth and all these other clients which have nothing to do with like the type of code that they write usually so i think python is like much more accessible for all these folks who like work more at the application layer and have changes they want to propose back down so it's not and it's not perfect for anyone but i think having it at this point where like you are kind of deciding whether something goes into the hard fork is seems like roughly the right spot but i agree with sam in the comments that we can just ask on all core devs and see what client developers prefer there's there's nothing wrong with doing it that way that's a great that's a great way to

write one if it's the best way for someone to write one but it just seems if it's if you don't really need it then you don't really need it if you've already you know if you've already implemented another client to then say well fine but you also need to implement it in the reference client um it's just like it was hard enough to do it in one client um and unless the core devs are saying no we must see it in a in executable python um when really in the past

people have been able to work this out and once everything is a consensus on the net um it just doesn't seem to be as big an issue as we're making it to be the quality of the eips coming in is an issue but the core devs are quite free to push back and just say we can't understand the cip well enough for whatever reason and having it written in python may or may not help you can write really bad python one other point that i would like to bring up here like generally we uh consider four at the max six core eips for any upgrade

and considering if we are having even two upgrades in a year and we have one or two proposal which needs help like i have it documented in python that can be provided but i totally agree to tim's point that we should not be making it a burden to team who are uh maintaining their specs for python but in my understanding uh this is something doable and if there is any help needed to push a proposal now when it is considered for uh inclusion so cfib generally from the process point of view um such as that proposal should be in review and ideally to have a spec written in python in review status when it is ready to be shared with the code would be good to have but if not i think

um it's just reference implementation and you can share that with code apps and if it is acceptable then someone may help you out with having that in python and you can proceed from there well the core devs will pull the courthouse are free to pull anything into cfi and they will pull pull at just a draft stage if if the draft is clear enough um so yeah that's right that's a fair point and that's what gives us this flexibility of if we need to have that documented in python you can get sufficient help to get it done

okay i object not enough to block yet but i do object you know eips need to be clear and well written but i don't i don't think that just requiring python will necessarily achieve that goal and it puts a big it puts a big barrier on a lot of people including me um well noted i think uh this is a fairly good discussion and that we are trying to discuss both the points um as tim and uh sam i think i read somewhere in the chat that it is good to check with the all code meeting

is more like what other clients think about it because uh we try to come up with a decision on like based on general consensus like whatever is good for a big number of people like a majority of people who try to move ahead with that so for now like because we have specs available in python it seems like we are good with there but definitely we can make a final decision after code as uh what what do they think about it um yum anything more to add on this discussion especially for related to having it in python and not in python because i know at some point sam mentioned that if it is so contentious then we can probably drop it and i just don't want to drop it

just like that before we have like a very very good reason to drop it yeah i think we're finished with it for now that that's good i think uh if this is something that that cannot be like closed in one week or two maybe we will have to work on this adjectivally so we will come back again on this topic um next week uh not this particular one but i know um jim has joined here and we are also looking for some support uh on the ethereum process as an as overall uh help there so yeah

tim if you would like to take it from here and talk about how we can probably add more support to existing process in terms of if we have to move ahead with this execution spec we'll be looking for more help in eip bot and other sections yes um so we have mario today from our team who can probably help with some of these issues i don't know marielle do you want to introduce yourself real quick hey folks i'm maria havel i work with uh ef with demon training vertical support yeah and i've been looking into the eap bots uh i i was listening to the call

from january uh to get some overview about the bots and there is well multiple of them there are multiple issues and and the uh this eip is in javascript i'm not really experienced with that and uh the uh the apv one uh the that one is in the rest i might be able to help there so um i will look into it more and and try to try to solve some lowering issues um awesome so did you mention that you would be more comfortable with eipv because i know there are a lot of open issues and also some pull requests that need some reviewing before marsh

yeah exactly exactly um it's the eap verifier validator um right um yeah well later on um so because because i'm i'm just much more uh experienced with rust than with javascript so it would take me a while to pick up on the other one but i was already looking into this one and uh and uh yeah i'll be glad to contribute so we've been discussing slowly migrating the ipv over to the um eap bot however um so on the one hand i want to say you

know we should be careful about singing too much dev effort into eipv if we're just going to eventually deprecate it on the other hand we are desperate for help and people and so if we have someone who wants to help and rest is what they want to do then i would rather keep eipv and not deprecate it and instead get the help if that makes sense yeah sure you have to get it um yeah i mean let me see if uh i will be able to um to figure out something there but uh so what would be the timeline there like when would you imagine to have the ipv duplicated if there are contributions if there's no contributions to either of them then neither then they will both

continue to live on forever it's we have been working on slowly very slowly adding features to the bot that overlap with eapv until eventually at some dis point in the distant future eapv could be removed because it's fully handled by the bot um again though that that process is very slow and i would rather take the help where you can get it and so if if you're passionate about rust and you hate typescript then i would much rather get help on the apv than nothing for sure and the timeline at our current clip like our current pacing is i don't know many years before we managed to hear the vip uh that's great yeah i mean i'm a bit

busy these days i will i will be probably able to look into it in uh coming weeks and uh i will reach out to you i see that you are one of the contributors there and i also uh also actually have in touch with him uh regularly so so if i have anything i will i will ask and uh yeah i think for eapv you probably want to talk to matt uh late client um he's the i think he's the one who ordered it originally from ruby i'm not mistaken um and so he probably knows it the best i i actually don't speak rust so i would not oh okay you should good uh yeah i talked to light clint and amsterdam recently uh

so yeah i can i will get in touch yeah hey i think that would be a good uh help in that direction because as matt mentioned uh micah mentioned that we were considering that to be converted into typescript probably but now that we are getting some help on uh rest side so let's have it what we get there i know there are a lot of open issues there so it's good that you have already started looking into it and we have someone else jose on the call who is currently looking into eip bot stuff but i know jose you have been uh suggesting a lot of suggestion how to improve that yeah if you have anything to like uh add

i know we are out of time but anything quickly if you would like to share yes thank you very quickly issue 78 and issue 80 was created to answer issue 75 and issue 70. i will move them to the pull request as as suggested and i will generally also pull requests for issue 77 and issue 79 which are high priority sounds good yeah if you can add pull request that would give more clarity to eip editors there to may be able to review it and decide like whether that is a

good suggestion or that would be a good solution to the issue that is uh looking for some help so that would be great i know sam wilson has done a great job putting out small issues for uh bot that that can help automate some of the processes so slowly we would like to also get into uh taking up those issues but uh to begin with we can start from whichever or the higher priority um we are out of time i'm not sure if you'll be able to take any other item listed here just quickly i wanted to uh mention this to uh mario mario i'm not sure if you are available on ethereum cad holders

discord if you have not maybe you would like to join and we try to have discussion you can also discuss it on ethereum rnd eip editing channel but um there are also editors available on ethereum cad headers eip editors channel and we can discuss if there is something um that uh i mean that is there for you to answer the editors yeah yeah i'm in the in the uh discord and um i'm following here uh i i also read the the uh the editor apprenticeship had a book and i i might be able to to help with some editing as well or some some feedback for the piece um

yeah sure oh yeah yeah thank you great thank you so much um thank you tim for introducing mario to the group i hope this will help us a lot because we have been looking for a lot of help to uh towards sport so we'll be able to move smoothly anything anyone would like to bring up today um all right um i'll consider that we are good for today but i know um we have a few more things that we would like to cover it in the upcoming meeting so uh thank you everyone for joining us today

hope to see you in next two weeks and we can still keep chatting on the discord ethernet and eat caters have a good one everyone thanks goodbye everybody thank you bye bye