EIPIP Meeting 41

Transcript

welcome to the ipip meeting 41 i have shared the agenda in the chat the first item on the agenda is a process for networking eips so in the past few meetings we have discussed processes for different types and categories of eips that the proposal should be moved and also to the appropriate statuses um we did bring it up in the one of the acd meeting as well and have created peers to change their status but i have added this item in the agenda today based on the conversation on discord about reconsidering the process of a standardization for networking

proposal i know micah left some comment uh i don't know if you if you would like to go ahead and provide a quick summary for people here or who may follow the call afterwards and then we can probably discuss on it i do have a link to those comments i do not remember okay yeah i should have it oh are you is this referring to the comments i made in discord that's right to felix i see uh this is just that i've noticed that networking eips in particular seem to

the the people who write them seem to be very dissatisfied with the eip process and so i was trying to encourage them i think either they should follow the same process everything else or create a different process i'm totally fine with either i'm as everybody knows i'm not like a huge hardcore eap maximalist the the issue is just the like like basically it's felix and peter are the only ones who do networking ips um i think i have one um but they they're really hard to these don't fit within yeah that's not even true

i i to me it feels like the process is okay they just you know write the eep and then they just leave it like yeah so if they just if they would just be there to make it go to final i think that that would be you know all the work right but they for whatever reason they don't want to do that um and this is why i say that either do that like follow the iep process or create a different process and i think both are viable solutions like if they feel like the eip process is not a good fit then um i think it's totally fine and i think there's other processes that one could design it seems like what they want is they want to use the ap process as a means of

advertising so like they they don't want to actually do the ap process they just want the to use it as a as a way to communicate with people and i feel like that's not the right usage of the ap process like we have a process in place in order to ensure standards you know are of certain quality and that there's a you know steps you go through to make sure you're getting the reviews you need et cetera it's not really designed to be a place to just advertise a change that you made in your client i feel like my take is on this was slightly different it felt like they find it useful to use it in the beginning and whenever it just turns out they are generally the only people doing the networking east but they do

appreciate oh we have felix hi felix we're just talking about the networking age yeah right yeah right so i have invited felix to the meeting as well i'm wondering if he has uh some microphone issue of because we can't hear your feelings i'll just finish my thought to me it feels like you know they're just in a way that they have to after this is clearly a final eep that they have to go through every single stage like if we could just convert it to a final leap that would probably be fine and in the future we should just you know try and be more aware and help

convert that to a final eat before it becomes like a year out of dates of essentially being final but not listed as final your mic still appears to not be working felix i see you lighting up but no sounds coming through yeah we still can't hear you so my my general concern with just moving these to final is that um i'm a a big

fan of uh incentive alignment and if we do this then there is now an incentive for if you don't want to go through the ap process you just simply have to wait long enough and then you can avoid the process and the process exists for a reason like we we don't have the review step the last call step just for fun like they want people to go through these steps so that way we get the proper feedback at the proper times and the life cycle etc and just skipping them just because someone waited long enough i feel like is a going to lead to misaligned incentives hey guys i hope you can hear me now yeah uh there's i'm sorry this there's always the big

trouble with the audio i don't have a lot of time but i guess you are already discussing this like networking eip uh problem yeah so i have two comments mostly so i think in general uh the eip process is you know kind of okay and um i think that um it may even work for the networking eevs of the future but i think at the moment the discussion is about the networking eves of the past which i think are different because at the time when they were created also the e process was very different and it was less organized with the all core devs and i think it's just from a different time so that's kind of the the main

difference and then the other thing is that i want to say about it uh is that with the um so i mean i i think the the point of the e-process is uh to aid the client developers in making the correct decisions about implementing stuff and um you know also like aligning the client developers and for the ethereum consensus it makes a lot of sense because uh obviously they all have to implement the exact same thing so um it's kind of like the the e-process also serves as the kind of repository of the specifications for example because you just need

a specification to develop the change in the clients and so you know obviously the feedback is very clear and since everyone has to implement it exactly in the same way it's uh something that can also really easily be verified you know by tests and stuff if it's actually implemented and then with the networking things uh we are in a much better situation regarding the testing now but uh you know earlier especially when these eaps under discussion were created it was you know kind of we were mostly just trying to capture you know like the the the general idea and um since the clients were like so uh so kind of like disorganized regarding

the networking it was just kind of um you know we just thought it is good to you know like publish the changes somewhere in the sort of official way so that we can bring it up but um it's not really i don't think it is like as necessary for the networking to be like 100 aligned for the clients for example it would still be possible right now for the clients to use you know alternative networking mechanisms as well uh as long as you know they because they ultimately we want all the clients to be able to connect so they should implement some common thing but they can also implement arbitrary extensions to it or whatever you know like it's just not regulated like so tightly as the

ethereum consensus is and so for this reason i think the networking needs are more like you know like sort of like kind of like informational i mean like there is a spec and the spec says what you're supposed to implement but we have also seen that like half of the clients don't implement all of the specs so they already like out of spec most of the time and then you know other clients they just have you know like their own extension which doesn't have a spec so it's kind of like it's it's not really like as there isn't really like the canonical way to do it you know and while it would be nice if you know at some point we could all agree i think this will never happen

so it's kind of like the question maybe if you know like it's so necessary to really like use the very strict process for this stuff so i think that one of the things that makes me lean slightly towards not using the ap process is because unlike other consensus changes the networking protocol actually does have you know the uh like a webpage that defines it like it's actually specced out somewhere else and having the that's specked out and i believe you maintain that website right felix the rlp x stuff yeah um so the specs yes so it has its

own specs and but i can already interject right here so basically the reason why we have the specs is because i use these specs to document you know what the protocol actually is and my reasoning always behind the specs was that i want them to be very comprehensive but at the same time most of what's written there is is just basically also just documentation about what the clients are really doing so in a way um the spec there it's not it's not really like a spec first approach like i mean we in go ethereum we kind of do it this way so we kind of create the spec first and then we make the implementation

but we have also like i mean especially with the specs i have you know basically just try to write down you know what is the actual behavior of the clients uh and there was no respect for it like you know before and there was also no effort before for things like you know the transaction handling and things like that it's just it's just stuff that you know like was kind of like one-off invented by someone and then later i just put it in the spec because i think it's the right way to do it you know so i think yeah we cannot really make like so for me the the networking eeps have the independent purpose from the spec which is to you know like lay out the change in advance and then uh once it's implemented we can

always you know like you know refine the spec and you know also apply what we learned you know from implementing the eep version of the changes or something you know like this there's really like uh i don't really want to make you know like my own like ethereum networking improvement proposal thing because that is just silly i mean there's well so i think that there are a couple of examples where for example eth2 has a specs repo and their change control process is not the e process all they what they do is they have prs against that and then they people review those pr's know when the pr is merged that means it's final and that process is much more lightweight than the ap process and it works great for them um

similarly the json rpc is going switched to using a similar process where you have a repo that has the current spec and then if you want to propose a change to it you submit a pr people discuss the pr and then when the pr merged that means it's final um those processes in my opinion are lighter weight and generally better in fact i would like to move the ap process to that eventually the problem is we don't have a spec like in github for ethereum uh particularly the consensus ethereum consensus and so we can't do a pr based approach it feels like the networking stuff is at a place where we could switch to that so that's why i advocate for it is because i actually do think that's a

better way to do change control is to just have people submit prs against an existing specification document and then you can discuss on that pr what you know pros cons back and forth all that you can use that pr as a way to alert people of the changes so again using eth2 as an example um they very commonly will link those their their prs you know to each other and they come up in the eighth two calls or like consensus calls um and so the reason i advocate for this isn't because i like i want to i want the networking stuff out of the eip process it's more that i think this is a better process and since you the networking stuff is already very close to being able to

switch to this process it feels like it might be a good time to switch over um it avoids it also avoids having you know this this kind of two separate processes where one is you have the spec over here that you're working on and then separately you have the eips that you're working on and then you have to kind of merge them like you can do it all at once in one place okay yeah well i mean for me personally i'm not bothered by this you know like i'm happy to also you know like adapt this back for the eep and it has happened in the past once you have other thoughts matt i'm sorry yeah there was a break um so basically i think the the the the um

i'm not bothered by you know like putting other people's eeps into this back you know later as well like i mean i'm the editor of the spec so that's kind of okay nobody has to edit this back for me to be honest i would just you know rather prefer to write it myself you know so this is like another thing so i think personally the spec will be better if it's you know written in a coherent way so if the spec is maintained by community i think the spec will become you know like it it won't be good so uh is is better to uh kind of i think like maintain the spec you know myself and then you know have the changes be proposed by the eep so because i like the e process for the networking as well

also because uh the eep kind of forces you to actually put the changes into a certain structure and i found this very helpful with my own eeps and i think it's something that i would prefer to have you know even for the networking changes because it's so nice that in order for the ip to be formally valid you actually have to for example give the rationale and this stuff this this like rational text if there was just you know some kind of pull request based approach then it would i think it would kind of get lost because you we we're not really going to start like pull requests are too lightweight for this kind of thing you're not really going to reject someone's pull request because the description isn't you know

100 right but you can totally do it with an eep so it's kind of like something something different i think so i would prefer to keep the the e format because people actually have to justify their changes and then what i've done with the spec is kind of like i put um basically when i work the e content into the spec sometimes the spec the spec is only changed in like you know like 10 lines or something or is only like you know like a couple words added so it's not really like you know most you know the not all networking changes are like you know big things but it's kind of great to have the eep as well because then in the changelog of

the spec i can just link to the eep and say you know we made this change and now it's you know the version something something and here's the link to the eben then in the eep you can actually find all of this material that like led up to the decision so i think it's kind of like good to have both because you have the the the the final spec which represent the current state but you also have all of the changes with their you know respective justification in the form of the eeps so i think this is the value that i see in the eeps and also in keeping the eaps because it really makes you think about you know how you're actually going to justify the change you want to make because you know changing these things also really hard so you

kind of have to you know like kind of do some thinking in advance you can't just you know come along and say i want to change this thing like it takes like months to make changes there you know okay i think if if you find a real value in the ap process and you think that it's better that way than having pull requests like i'm i can be convinced of that like ultimately we want i i want at least people to find value in the processes that we have in place um i was under the impression that you guys weren't getting a lot of value out of the eip process because it seems like you and peter are reluctant to go through the actual whole process um but if you guys are are getting value out of it then i'm fine with continuing to have

networking yeah it's mostly just for the historical things where we don't get the value out because we think it's a bit silly to you know like retroactively try to you know like apply the process to these hips which are already you know like basically done like for us these pro these things are done because they are implemented they're in the spec there's no need for us you know to go there's no value in going through the process for these eeps but there's certainly value in the process for like any kind of you know like newer eaps because we would really like to receive the feedback and discuss it and you know and some things maybe not in the spec yet so you know for these things is is it is different you know it's just so so i i agree

as i was saying i i think that even for the historic erps there is still value in going through the process um not because we expect to make uh normative changes like like you said they're already implemented we can't change the spec at this point however i think there can be value and go through the process just to ensure that you have people reviewing it because it may allow us to flesh out things like the motivation or the rationale or clarify some things like if anyone reads it during the review process and says you know i don't understand this it makes sense it's a good opportunity to add clarity and to fix up those things that are make it hard for people to understand and so by going through that you know review last call final process you get to those reviewers to come in and

actually read them and so there are a lot of people who don't read eips until they hit review or until they hit last call and so each each step along the way you get an additional kind of set of people a set of eyes on them and those eyes can call out things that they find unclear call out things they like minor corrections typos all those sorts of things and so i do think even for these old eips even if the normative content won't change i do think there is value in just having it go through each of those steps just so we can make sure we get you know the very all the normal people who review these things can see it i know there's at least one person who has an rss feed of last call eips and they don't read any

eips until they get to last call and then like for me as an editor i generally glance over an eip when it goes into draft and then i give it like a full actual read when it goes into review and so there's a good chance that you know if an eip is currently in a draft no one's actually looked at it and so we don't have people who have had an opportunity to actually you know give any feedback on the non-normative stuff and that's that's my main reason why i would like to see it go through the normal process and this doesn't have to be onerous or long it's basically just submit a pr set it to review wait a couple wait a week or so just to give people time to review it and then set it to last call wait two weeks give people time to

review it and then set it final um there's a good chance you know no one's gonna have anything significant to say maybe these like i said i haven't looked at them closely but maybe they're totally great and no one will have any feedback or maybe they'll get just like some nitpick stuff about uh you know formatting or structure things like that or maybe some people will have some more detailed feedback on how we can better explain things or better more clearly uh present the change yeah cool so let's do it then i mean like i'm okay with this uh we can just do this it's okay yeah okay yeah so now if i may just propose one small uh not change actually uh can be an addition continuing the current process so

we will be following the process for the networking but i know the networking eips are generally not brought on onto the all core dev meeting but i think that would be great if we start doing that that will give an opportunity to the get team to announce the change that they want to uh bring to their client and if any other client is interested either to give feedback or maybe to implement in their plan they will also get you know um information kind of thing and i i hope that is going to be helpful for the team just to have one one point here to mention there are certain proposals i mean at least one i can see here is eip three four three six which is proposed uh by uh daniel farin

uh i was trying to uh reach out to the author and his point of view was like it depends on like get client so my question to felix here is like what to do with the proposals which are because gets implementation is like major implementation in theory if we come across certain proposals which is not by the get team but from some different team how do we want to handle that oh is it this one you mean the expanded click block choice rule right yeah um it's kind of interesting because there is actually an eat for the for the click so this is not a guest specific and it's also implemented by other clients as well so the either click protocol is eip225

and it is final so this one is just an extension of the two to five and um it's in review for some reason yeah i mean uh the question is mostly just who should review it and um i guess it has to be brought up in all corners you know because uh if it's a review uh it's something that kind of everyone would have to implement i guess what why why is this uh networking apa this feels like a corey ap this is a consensus change right yeah it's not well yeah it's a click consensus change so it doesn't really

impact you know like it implements a test net only but yeah technically it is a core erp the uh it's yeah i think he made i think we should change the screen by mistake yeah because the motivation says it's about these deadlocks in the in the in the test net and so it's it's but it's this eip is technically a core eip you're totally right it's just not related to the networking uh so by the way uh looking at that academic yeah so this we should fix uh puja i wanted to say uh regarding the thing you said earlier uh we have actually in fact announced uh the networking eips in all quarters it's just a very long time ago so um

i think we will absolutely bring on the networking erp's to the to the all core devs every time like at least you know me and peter when we write the next one which is already planned you know by the way we already have another idea for the next networking eep uh we will absolutely bring it onto the or quartus call and i think uh this is something that is also very valuable for us for us is always kind of the plan because we also see the all quarters as being you know like the forum where you can discuss these things so it's like great that it exists right for this so we will definitely do it is what i want to say

great so i i think we have a kind of consensus here we'll be following the same process but if i may request you to kind of either approve the eips which are existing in draft status um like i have created a couple of pr's just by changing his status either it can be approved by the author or if get team has time and they would like to create their own pull request and change the status so we can at least move the present which is like very very small numbers of eips which are not confirmed like not in final statuses and they should be we should be good to go forward and uh it is fine uh to follow the existing process yeah thanks i will i will just look for

your um for your pull request sorry i i think yeah we can send you price yeah i can yeah i can find it also in the github is okay all right thank you so much for joining us felix and i think we made a lot of this particular conversation and i will reach out to the author of 3436 or maybe if micah or any other eip editor would like to leave a comment saying that this should be in the core proposal then probably we can take it from there thank you once again yeah thanks a lot guys for like finding a good resolution okay cool i i have to go now but thanks yeah

right thank you see you thanks all right i think that went well and we actually uh had a conclusion that how we want to go ahead and look for the networking eips so moving on uh i don't know before we move on does anyone have any final statement to save for this topic lightlined if you may want to add something no i think that this is fine i think generally a little concerned with all of the different processes that sort of tie into the eap process it doesn't

feel like things are streamlined but i don't think this is something that we could just solve in one day i would agree i was agreeing with micah's proposal as well but what i understood from the get team is like if they have to move it to pr based the most of the effort would be coming from their end to it actually have it streamlined and and if if they prefer to go by the eip process i think that should be fine for us too all right moving on to the item number two which is progress update on moving to stagnant status by part i have added the link

so in the past a few weeks a substantial amount of work has been done by the eip bot and editors not sure how i feel about thanking alita for activating bart for this job because it feels like the number of open issues a number of open pull requests are back to where we started but i hope that it will be like closed in near future so ali i see you have left some comments but if you would like to go ahead and speak for it oh do you mean like a couple of them were open and then they were closed um uh um i mean the changes are the proposals that um i see that you have recently closed some of the uh issues

that we added uh to kind of modify the part accordingly like what would be the closing period like two weeks time or something like that i want to explain on that yeah so i mean i implemented several features here um for the stagnant bot now it kind of um so it auto cleans like any backlog stuff or if it if it creates a uh a new pr by mistake then it will um that was like a repeat of a previous one then i will delete that one on the next uh in the next run so anyways i i implemented a bunch of features and i fixed a bunch of bugs

with stagnant thought um i'm sure we still have a ways to go before it's like actually really good i know um i'm sure micah or people who like are actually looking into the pr's there's like a i think there's 200 right now for the stagnant bot which i mean if there's that many then uh you know but anyway yeah so moving forward over the next few weeks you can see my comment on this uh agenda but i'm really working on some bug fixes and feature requests i have some kind of final notes which are uh please leave any requested features or bugs you notice as a issue in the eip

bot repo because it makes it a lot easier to track um and then i think there was one other but that's basically it is the plan that after some amount of time has passed we will automatically merge those pr's if no one's commented on them yeah so they're just gonna be automatically merged no matter what currently after two weeks um so so if we don't want to merge we should close close them out before before two weeks passes right yeah okay and then essentially and then essentially like uh excuse me you're gonna close it and then it's

gonna be reopened the next week so you're gonna have to close it every week until i can implement some sort of better solution to that also the bot checks to see if um there is an existing pr of some kind against the ap right or just not do that that's not a feature implemented yet no but that excuse me it is a planned feature i would say of all the features that would be the highest priority one um because we don't want to have to uh because what happens is mark is withdrawn user comes in and says hey i created a pr to move this to review

but they're waiting for an editor to review it and sometimes it takes like up to a week or two and so in those cases the user is doing everything right um and ideally we wouldn't be opening a new pr against them you know every week pestering them because it's not their fault like it's on us to get their pr reviewed okay yeah i mean i can do that uh before i fix the bugs so the current prioritization plan was fix bugs associated with the uh the main eip bot and then do feature work but i can prioritize that feature above all else and get that done this week i think that i i wouldn't say above all

else but i do think that particular feature is pretty important just because it's going to be very confusing for users when they keep getting pestered about um their vip need to be withdrawn when they're doing the right thing i think it's very confusing for for people um so like if there's some critical bug i think that should take priority but um if it's just like little miscellaneous bugs then i would do this feature first i think i'm just because like to me this is almost this this is basically a bug um pestering people to close their aps that they've already done the right thing on okay

i will prioritize it [Music] accordingly all right and just again repeating it if you have anything that you would want to be changed in the eip part please create an issue in ethereum eipod github we have provided the link in the agenda item moving on um so the next thing is the decision on closing issues in the last meeting we were discussing how to address the open issues issue historically the issue section was used

for discussion but we kind of discussed in the last meeting that we would like to move the discussion to fellowship of ethereum magician so it would be convenient for all like eip author and decline lab and the community to just go and check the new ideas and improvement proposals there so in my experience it's not a healthy practice to have like a lot of open issues because it's not kind of good reflection of the work being done or managed by uh the team who is managing their github repository though and i know that people are putting a lot of effort and time into it so i want to you know kind of uh bring attention to it so we can come to a resolution and way out in the last meeting uh michael suggested uh

getting it done like resolved with the help of eip bot marking them as an style issue the way we are addressing the pull request but it's not under production yet so i did try to leave some comments on bunch of issues and a few people actually created a thread but the item like the issue is still open i'm i'm trying to understand here how we can like close these things or how do we want to handle this issue and how we can actually encourage people to open issue if there is an issue or they are looking for any help not for general discussion are you talking about the it's like people are creating discussion to your

sorry they're creating magician threads for discussions on eips and what we do about the old issue is that the question but that is one of the questions yes so uh following the advice uh someone would say just close it okay then that may be something that the api editor might have to do that uh or we can actually just leave a comment that okay find this has a uh like uh respective fem thread we can go ahead and close that so yeah i was also looking for some more ideas like how we can strongly should we add should we start adding the banner thing or

what are the other ways other than taking helper bot bottom and bot is our ultimate result but before that what can be done to encourage people using this for issue not for discussion i think just being more firm with people that they really should create a magician's thread unless they have some really good reason not to yeah like ken do you have any thought on that is laziness a good reason because it seems like that's the main reason most people just create a github issue yeah i mean the reason why i am like uh hesitant on enforcing this because i see

for even in the past three four weeks there are a couple of issues where people actually started storming in their discussion threat they have started adding discussions and i just don't want them to be get lost and at that point it feels bad to me like asking them no no you stop discussing here go to fdm i'm i'm i'm fine with that like just let people when i talk to people about that i usually just let them know hey we have we're trying to get consolidates the discussions for eips in the ethereum magicians forum um can you please move this conversation over there and me if it helps we can offer

assistance with that like if they don't know what assistance they would need but like if they don't understand the process or they don't understand where we can provide guidance right while we have alita here um um i'm just trying to understand anita if if i understand correctly the bot uh leaves a comment on the first issue if someone if some issue is created by new user they leave a comment this is your first issue go ahead and refer to eip1 is it possible that we add an additional sentence that if it is if this issue is created for discussing a proposal please create it at fellowship of a theory magician like would that be a good idea and how easy

or difficult that is to incorporate i mean yeah i think that would be very easy to incorporate uh probably do that in like 10 minutes that sounds good i am i mean if people agree we can yeah please go ahead i always need the the text for it i don't know do you have a specific text you'd like to use puja or not really i mean just just my idea was like as we are suggesting them to follow eip1 we can just add an additional line saying that if this issue is created to disk this proposal and add the link as discussion two please uh close it and create a um a thread at fellowship of ethereum

magician yeah this should be like uh as soon as we find the line that should be like a anyone can submit a pr to the bot to make that change then text i don't know where the text actually lives is is all do you mind copying that in the chat okay i will yeah i will send it to you okay in the uh and it's got channel so if we people want to change the text we can do that all right i think that would be a quick fix that will actually uh help us stop getting new issues as discussion too and then we will eventually uh take on the

existing issues taking it one by one is little challenging but maybe uh if we get bandwidth to get that help of bot for issue section i mean i understand this is not highest of the priority but we can add it to our to-do list no i mean like i can do it like in like literally 10 seconds not just this change there is another change i i'm not sure if you got a chance to look into the earlier meetings so micah proposed some changes in about a month back so i will let you know on that all right that that i think is going to

help us a lot okay moving on the next item is eips inside um so i have recently started like curating a list of eips which is moving from one status to another status this eip insight actually i know that it is going to be like used by very niche user base but i have a feeling that it can be useful in long term so for people who are interested in tracking eips and they want to follow what changes are coming up in ethereum blockchain um

this monthly report will be helpful so if if anyone has any suggestion to you know add things to this monthly reporting that people may find useful please let me know okay now we are at the last item i i think review action items from the previous meetings in the last meeting we we see three decisions taking the one adding execution clients and forward execution specs number two update eip editors in eip1 number three eipap meeting will now

longer be now be larger but only occurring once a month um i'm not sure about the larger part but we are at least following uh once a month so that is there and the other two um sorry i did not get a chance to create the respective pull requests i will try to see someone from the cat address if they have bandwidth to do that and if not then i will definitely try to do it on my own and finish it up before the next eipid meeting so that's all for the meeting today uh before we close uh

anyone wants to bring up any other topic yeah there was one thing i was waiting to maybe discuss i i posted about like 10 minutes ago so didn't make it on the agenda but there's been a lot of discussions on some sort of open roll-up specification i don't know how much people on this call follow the roll-up space but basically optimism recently announced that they were changing their approach to rollups and now they want to create a rollup that is basically one for one compatible with with mainnet and so what it looks like from a user and a developer is you're just using some ethereum sidechain

and in the back end it's uh has data availability posted on mainnet it has fraud proofs and so it has the security that you expect from a role but it looks like something that's less secure like polygon and there's a lot of drama between these teams there's a lot of like financial incentives of like successfully shipping roll-ups and so it's kind of seems like it's difficult to get people on the same page and have everyone work together in a in a happy manner and i was just curious if anyone has thoughts on like this you know developing some sort of open role of specification

what does that look like in terms of process what does that look like in terms of um output where do you think things like that should live etc so this is for standardizing roll-ups isn't part of the idea with rollups is that we don't standardize them so people can experiment that's one of the uh hypotheses that people make about rollups i think that things are changing a lot and what people are finding is that people want to have an environment that looks exactly like ethereum they don't want to

have to think about different nuances of the virtual machine or like different state layouts they just want all the tools to work exactly like it works in ethereum and so now you kind of have an endpoint that everyone is trying to converge on we want to be able to have a rollup that emulates the ethereum like mainnet environment and so it's a matter of like how can we create a fraud basically a specification for a fraud proof mechanism that allows that environment to be uh verified on mainnet and that's kind of what people are working towards and you know people of course can still implement their own things but i think there's a lot of value in

having something that's one-to-one with ethereum because now you get to use these tools all the tools that are already implemented for mainnet again for free on your up so i'm not personally a fan of this but i mean will be at me to try to stop anybody from doing bad things on the internet if people want to create eips for a one roll up to rule them all um by all means probably would be an erc i think um like i said i'm not a fan like i think that trying to like i recognize the value of standardization and i think roll-ups are not the right place to do standardization like i i get

that it's nice to have tooling that works across them etc yes but you know that's not how we progress that's not how we do better that's how we just do more of exactly the same thing we've already got which is not great you don't think that there is a significant amount of re-engineering almost the exact same things across every roll-up team and that's not something that you think is a problem so i think that so yes there is some amount of re-engineering um but there's also exploration and experimentation like people are doing different things and trying to figure out what works and i think that's incredibly valuable and if

we encourage people to all do the same thing then we lose that exploration and experimentation and so we lose that value and so what i don't like is losing that value yeah so i guess there's like two things i'm trying to understand which you're specifically talking about so there is the exploration experimentation of the actual runtime environment that people are going to be using and this is you know a different virtual machine a different state layout all of those things and there is the back end that the users don't see but that allows for the optimistic roles to be approved on mainnet and so with this new standard the idea is we already have a specification of what the runtime environment looks like it's just

ethereum and so now we're trying to develop a standard for proving ethereum on mainnet and you're saying um it's good to have this exploration of people doing different things are you talking about both of those one of those and do you think it's possible in a standardization process to have that type of exploration so i'm not talking about both so for example arbitrarium um has had i don't know i haven't paid attention recently but they had a different mechanism for doing their fraud proofs than optimism did i think i heard optimism of switching to arbitrary solution

because they found it better but again i don't follow very closely and i feel like that's very valuable like the fact that arbitrarium went and did something different and they tried something and it seems to have worked and they like it i don't like discouraging that and when you introduce standards um you kind of discourage that not i would say discourage but people are more likely to follow the standard because it's easy rather than going and exploring and trying new things which i would like to incentivize people to do at least a little bit yeah okay um so i'm like super on board with people who want to build different run times like i think fuel labs is building a different run time for contracts and totally on board with them doing their

own things and experimenting i'm like more worried whenever we there's a lot of people who have this end goal of recreating ethereum and now it's a matter of you have different families of proofs and so arbitrary has an interactive proof and optimism was originally doing a non-interactive proof and so these are just families of doing these things and if you have three four or five teams who are implementing these different families it seems like there's a lot of the same work going into you know rebuilding rethinking through like you kind of already have subtyped yourself into a family of how you want to solve the problem and it feels like if they just work together it would be

better so i think in in that case it sounds like maybe what you want is just an open source project rather than a standard so i think like if you have two roll-ups that are building basically the same thing it feels like they should have ideally in that perfect world where everybody gets along and works together happily there would be you know a library repository that both teams contributed to and worked on and that library would then be used in you know roll up one and roll up two and that feels like a better fit than a standardization process um it's just like they want to share code basically and you know the best way to share code is open source

i don't know if these teams are currently open sourcing their stuff or they all are yeah they're they're things are open sourced i think it varies between mit and uh gpl i'm not sure exactly which i think most of optimism stuff has been mit um and then anything that forks geth is obviously gpo um yeah so it's really a matter of getting people together and doing syncing together yeah and i'm definitely a fan of people contributing linux being an economical example you've got a billion different flavors of linux but they all have the same kernel more or less and you know just using open traditional oss processes to build that kernel and then everybody uses them i think is very reasonable

i don't think that like writing a standard for linux is the right solution here i think yeah having that shared kernel library is the right solution okay interesting all right similar uh thinking area but slightly different curious when you have thoughts on this idea the way that ethereum was launched we didn't have any mechanism and protocol to fund the development of the protocol and i think we're past the point where anything like that is plausible to implement in the l1 what do people think about rethinking this in l2 like is this something that might be plausible where

you have some mechanism where the fees that are burned are actually go towards some sort of public goods funding rather than just being burned to the protocol uh so the i i like the idea of somebody getting paid to build useful things i'm a big fan of that the problem historically has always been deciding who gets paid and how much this is much easier when you have like a company behind something and that company just gets all the money and then the people who lead that company can decide where that money goes it's much much much much much harder when you don't have a company instead

you've just got like some amorphous group of people who are all working together like you have on ethereum you know there's there's no i mean there's ethereum foundation but they very much do not run things um and so deciding does geth get the money or does another mind get the money or does vessel get the money is an incredibly hard problem so with rollups i think that if your roll-up is designed where you have some central person who is the development team um then yeah i think it's totally reasonable and i i personally don't have any problem with them receiving a reward for their work um or payment for their work if they're trying to build a roll up that is totally decentralized and has no

leadership um things get much more complicated yeah yeah i mean it's definitely a really difficult problem to try and figure out the correct distribution mechanism for the funds to me you know i think there are like ways of doing it some really bad some not as bad the thing that i struggle to to rationalize is why would people not just remove that functionality from the protocol like i can't think of a good like suppose you do have this open source project this is the role for ethereum many projects fork that and just deploy their own rollups what is like the stickiness that causes them to continue paying that tribute to public goods funding and i can't think so i think

i think the fee burning is a good place because the fee burning mechanism exists for incentivization reasons and we have to send those uh burned fees somewhere i mean on layer one we burn them like that's that's where they go they go to detonal however they can go anywhere like there's really no reason to pick one place or another other and the reason we picked on l1 to burn them was because deciding to go anywhere else was way too contentious and that's burning them as the non-potential solution if you're setting up your own new roll-up um you can pick where those go and you just say you know it goes to my account and they're gonna if someone forks and does their own thing they can send them somewhere else but they're still going to go somewhere like they need to not go to minors

that's critical for incentives um but that's basically it they can go anywhere and so i think that's a good opportunity because those fees do you know need to be collected for incentivization reasons and you know functionality reasons curious so let me give you like a straw man of how i think it could be done so you know my end goal is i would like to have some kind of social pressure or some stickiness factor that causes those funds to go to public goods because if it's just an address they can always replace the address and go to the dev team and it would be great if there was more friction to do that than just changing a line of code and so the simple solution that kind of works

is very similar to how e2 was originally described where you have the shards of execution and you have very quick communication between those shards because all of the shards move forward together and they roll back together and you could do something similar with roll-ups where you could say you know we all implement the same fee burning like you have to be part of this group of roll-ups where you have fast communication to other rollups you have to have the fee burning functionality that goes to public goods and so now you can like join that group of rollups and everyone rolls back together everyone goes forward together and you can quickly communicate within one block to other roll-ups this is better than the finality that you have to wait for for many other things and so that's that it could be a way to cause people

to to create friction like if you don't want to pay the public goods funding fee you can deploy a role outside of that but look you're going to have a longer finality period and the communication is going to be slower to that group of rollups i don't know if you have any other thoughts on like how to incentivize on a social or technical layer um so the the one the warning i would give is just that throughout history any time um charitable donations have tried to been forced they've eventually been captured like the uh if there is a group of people who are deciding where a set of funds goes eventually that group of people will be captured by some group who you know directs it to

themselves in some way often indirectly but usually they end up getting those payments and so by allowing people to do charitable donations um on their own you it is a very strong deterrent against capture of those shared relations because as soon as someone captures it people just simply stop giving that money to that that group um whereas if if you try to enforce that you know everybody who wants to participate in this you know conglomerate needs to send their money here um then you end up with now if it like you said it is very sticky and once that stickiness exists now there is incentive to capture it because it's very hard for people to stop sending their money there

whereas if it's just purely optional like people can send their money where they want then it's much harder to capture and that's i think my my biggest worry about trying to force people to fund public goods is that eventually it's going to get captured if it's enforced in any way all right in other words humans are terrible we just need to be ruled by our robot overlords ah yes please you're really making a good case for being high up in the human hierarchy of the robot world micah they're gonna see

this recorded i for one welcome our robot overlords all right thank you for this discussion i don't know if it actually answers to the question that you added here on the agenda light line but i'm happy to move it to discord or maybe to the next meeting if you would like to um before we go i have two things i wanted to uh like just bring to your attention here i don't know for some some reason i find eip 3779 i'm going to share the link here right away

so i find this pull request as marched but when i look into the proposal it is still in the draft oh sorry my bad i may have missed read it he actually have updated the ap sorry that was my back okay and the other thing is do we want to continue the one month or the four weeks thing or is it okay we we keep it tentatively for two weeks and if we don't have much things on the agenda we'll come back after two four weeks what do you think i have a week preference for uh meeting every two weeks and we just cut it short

if we don't have anything to talk about rather than having less frequently that way if something does need to be talked about we have a semi-regular opportunity to do so okay so let's keep it for like four weeks for this time as well and see if something comes up and we need to meet that then we will reschedule it earlier or whatever okay i was saying i would prefer it if we just have it scheduled every two weeks oh so that way nice yeah yeah yeah in fact i am also yeah i'm also in agreement to that i feel like having it two weeks put us into a schedule like okay we have to uh like get things done before that and uh

we have this agenda ready and if we do not have much then we will move it to the four weeks okay i'll mark it for two weeks now and then we'll come back thank you yeah thank you everyone for joining i know it went a little over time but thank you everyone for joining us today see you all in two weeks have a good one thanks butcher