Better EIP Reviews

Transcript

[music] Welcome back to ECH Institutees inerson podcast at Devcon connect. I'm very happy to meet with uh so many developers right out here and today we are excited to meet Yohham from Ethereum Foundation. Welcome Yam. >> Thank you. So for people who may not know him, Yoham have been working for a long time for EthereumJS and we have recently added him as a new EIP editor. So we are going to have some questions around his experience and would like to learn what he has to say and do for the new process that we would be expecting in MIA future

in Ethereum. Welcome Le Yam and we would love to start from a brief introduction of yourself. Maybe if you can let people know how did you join the Ethereum community and what is the work that you're doing right here? >> Yeah, so I'm Yom. I'm currently working for the prototyping team. So I was working for JavaScript but now for the prototyping and well I mainly got involved in the EIP community as uh well what I really like to do like at lunch or when I drink my coffee is like take a look at the EIPs and like review those uh and to well to provide feedback on those because I think that um for all the processes like feedback is like the key of like a process like you can't make an improvement without having

feedback because then you will just like uh just go this way and And without the feedback you you were like well crash into this thing. If you would get feedback then you would like avert like this crashing situation. >> Very well. So you mentioned two things here like uh you having coffee and looking at the EIP. I don't know if it is good thing or bad thing. I don't want you to be very much caffeinated but you having coffee and looking into EIP has been very well worked for us. >> Maybe it was decaf. Right. [laughter] >> All right. That's a very fair point. >> That's very good. Um I understand you were also a speaker at EIP summit. Thank you so much for joining us there. And you brought up the idea of feedback loop. Would you want to maybe expand a little bit like what are your thoughts

behind it? Any ideas that you would want to see be implemented in the process in future? >> Yeah. So what I would like to see like in the process and I not really sure if we can bake this in the process but like I want to see like more feedback. >> All right. Like I think maybe for ERC's like I like my main knowledge is about EIP so like for for core uh proposals and not ESC like more app layer proposals but for that I see that like the feedback which we are getting at like the official place like a fear magicians it's well it's not there >> or almost not there and I think for these proposals like what I tend to see is that sometimes there are like conversations in like private rooms or like like semi-private rooms like

there's some conversation going on but you need to know where this conversation is going on. >> And for this I really want like to to lower this barrier to also get engaged in this conversation. But what I also want to do is like I want to somehow not challenge and and also not force people but I want to give core developers or like people will attend these conversations like the message this feedback is very important to the EIP offer also. So there could be like a well a semi-private room as people discuss these things and they say okay well we have like this security problem with this EIP or like uh we need more tests or we need more benchmarks or we need like this or this figured out like that's like a valid concern but if this is not brought as feedback to the EAP

offer then the EP auto offer thinks okay this all looks fine but in reality then we go to ACD so like part of the EAP process or at least to get your improvement proposal inside of fork Then on that call people say yeah we have these and these concerns and it's like okay but why did you not bring this feedback up like in like this a magician strat so this is really message like I would also like to somehow bake this into the the protocol or like the process itself that developers should really realize that this is like super important also for the process because it's for an offer like very frustrating or irritating to hear this at ACD and then you think yeah but if you will just have told me that we have these concerns

like I will spend a lot of time like figuring these things out but if I don't know that this is a concern then there's also no no way to to figure this out. >> That is very well said. I understand it took us a long time to bring the fellowship of Ethereum magician as central place for discussion. We still are getting some discussion happening on GitHub repository sometimes on Twitter and it's still going on but for people to know that we are focusing on getting all these piece of feedback in fellowship [snorts] of Ethereum magician you did mention about lowering the barrier and trying to make things accessible so we can get feedback on time. It would be a good idea to have this feedback process baked into the

entire EIP process especially for the core EIP [gasps] but I'm just trying to think out loud like do we have anything in specific that we can perhaps make as a mandate for any of the core proposals to be following in order to propose for future upgrade. If we can do that then we can perhaps increase the visibility of such proposals and we can collect more feedback sooner rather than getting at the end of the cycle >> right I think it would actually be very hard because then you would have to write down like how this would look like and I think like what we also don't want is that we want like every conversation on the fellowship of magicians because then like these threads will get like super long we really want like to know

like okay there has been a discussion about this and like these points were made and we want like this this or get like these benchmark these tests or we have these concerns. I don't really know like how we can bake this into the process but yeah it will be like very hard to write this down and you also can't really put like a number on this. You can't say like okay like this EIP we want like at least uh >> 100 reviews. >> Yeah. Yeah. Something like this or like we want a discussion for from every client. Like I mean to me that doesn't sound like a very good one. >> Yeah. But I think it's more about like the the intrinsic process also for like also that core developers feel this responsibility like okay we have had this talk we have had this discussion

and now we let like the entire public know that we had this talk or this discussion and now we make this point like okay we had this and this discussion and just pointed there on the magician's thread >> that makes a lot of sense but I also have mentioned it in the EIB summit inauguration that everything starts from an idea since you have shared this idea I'm sure that we will be getting a lot more suggestions that eventually could be a part of the process and we will have a better one in future. Well, you are a core developer and we are expecting Fusaka upgrade early next month. I wonder if you have anything specific that you would like to share with the community any particular EIP that you are looking forward to or uh anything that comes to your mind when we say Fusaka upgrade.

>> I think for the Fusaka upgrade what we have seen there is some concerns about EIP 7825. So this is the EIP which sets like a boundary on the gas limit of the transaction and we have seen yeah this might actually be like a very good point also like process wise. So we are now like hearing like a lot of concerns especially from like people using the network like oh wow but like now my transaction actually will be invalid on mainet because I have these transactions they are like at so this this new limit is like 60 million 60 million something and people are sending transactions sometimes with 30 million gas limit. So these transactions will now be invalid after Fusaka. But if then so what we ask de developers do not want to do is like

for like to lock people out of their funds like this would of course like not be very nice. So we want to like to collect this uh this feedback and want to know like are we actually shipping something which breaks something. Well there are a lot of concerns like uh okay this is maybe not part of the magician stat. I don't know I I've not seen I think a lot of there but uh I hear from core developers like they are getting messages like wow this is breaking this is breaking this breaking but then we are looking into it and what we see is yes okay this specific transaction is breaking but what is this transaction doing it's deploying five contracts in one transaction and you can also split this up in like multiple transactions.

So this is also somewhat part of like the feedback loop like uh this this is a concern but then also maybe a message for also like maybe do like slightly a little bit more research also like is this really a problem for you or is this somewhat easily solvable and well I would say like for the for the things I've seen that these are well easily solvable because it's basically already in the transaction like you you can already spit like you are not going to deploy five contracts now you will just deploy one or two and it will still fit into this guest limit. That's pretty interesting like when we say fusaka upgrade most people talk about pieras layer 2 and all but it is interesting to know that there are other proposals which are like equally making impact and people do care about it that's very well

said you are going to be EIP editor and would be looking into more proposals having reviews for um authors and perhaps uh conducting EIP editing office hour as well. Would you have any word of advice that people should be very much mindful of when they are submitting their proposal for uh EIP documentation? >> I think well like how I would see that an EIP looks like uh optimally will be that they are self-contained.

>> Mhm. >> And that you can read it in one go. So like this minimizes the entire process of like everyone like if you have an IP EIP and you need to read it like three or four times to actually understand what's going on like to understand the EIP completely I think that's not the right uh way that is also like more about the quality of the EIP. So what I mean with like reading it in one go like you sometimes see that a constant is defined somewhere but it is used somewhere before and this is like not nice because if you are reading it then you first think oh wait like I have this constant but but where is this actually defined and sometimes it isn't even defined like that's that's also not not very very helpful. Uh but this of course like just just an example. Um and it

should also be self-contained like some sometimes it's um like if it refers to something it should also be clear to what it refers to or sometimes it also introduces like some new methods like uh well could give an example we had an EIP this introduced like this seal 32 methods and then you could imagine somewhat what it would look like but it was defined nowhere and this is [snorts] also somewhat dangerous I would say because if you would then implement this EIP you are going to assume like this is going to look like this this method But uh the offer actually meant something else. So like to speed up the process of like discussing the EIP to integrate the EIP uh and also to review the EIP like as a core developer you should have this EIP this document you should read it in one go. it should be self-contained and

this would like help the entire process and I would say that for like a draft proposal like you can self-re it but then still like there are some things which you might not find there for inance like this constant thing because like if you write an EIP like you have this concept already in your head then you are like reading like section one and you see like this constantly like oh yeah but I know what it is like you will you will like not see this problem uh with the with the draft so with the selfie view so I would say like also get people even people who are like not super technical like to proofread your EIP before you're like drafted to uh to the EIPS because like for also from like an editorial point [snorts] like um we will basically check the format but we

will not really check like like the contents this will be more like the reviewing part of the EIP [snorts] and I think like also for like a draft like do a self review and like have maybe like one or two or maybe even three people like just proofread it for like maybe the same way as like you would hand in like report at like high score like something like this like it's really nice to have like other people also people who are like not in your into your research to read over this >> I mean you have shared very good points here the proposal has to be self-contained you might want to make it fully specified and just put everything at one place so people don't have to go anywhere else to figure it out and of course the feedback is important as much as for author same for the community and

the client because they would have to implement and they would not want to spend their time if a proposal is like just halfway through half baked and maybe coming out of because we did not get enough feedback on time. That's a lot of piece of advice here. One thing that I would like to add is like be present as well like you know you have to keep interacting with editors, show up on editing office hour if you have questions, comments, concerns and then try to learn the process in order to move the proposal forward. Thank you so much Yam that was really great. I wonder if you have any final words that you would like to share with the community before this wrap-up. Yes, I think well what I really want to say to everyone also for like adding things uh or like being involved in the EAP process like

um I think there are some misconceptions like I think there's a very high mental barrier to actually enter this process. I think that everyone can actually help for this. So also like for what I just said about like this proof reading part like you don't have to be like technical you can just like read this document you can say okay like from the technical part I don't know it but like uh you should like move this section there you should this move this section there so that you can read it like in one go and also about the EAP process itself like you should you you are not required to be like a core developer so everyone can help there and I would really like to say like we are building Ethereum but we are also like shaping Ethereum and we are like doing it together

>> very Well said. So listeners, you just heard Yam. He is saying that we are building the future together. So come and be a part of it. Thank you. Uh I wish you all the best for rest of the Dev Connect. Thank you for talking to us. >> Thanks for having me. Yeah.