RPC Standards #1

Transcript

[Music] Hello everybody. Welcome to RPC standards call number one. Uh this is a light agenda today. Uh it doesn't look like there was a lot of contributions. So what we're going to do is we're basically going to review our notes from call number zero which was two weeks ago. The agenda is linked in the chat. If anybody has anything else they want to add to it, now is your chance. This could be a quick one.

So, there is time to chat about stuff. Ah, Felix is here. All right. Maybe it's not going to be such a quick one after all. [Laughter] had a boy. Good, good, good. Okay. Um, so in review uh from our previous call, there were a couple of uh discussion points that needed to be considered and further thought out. Um, one of the things that we talked about, I'm just going to take this from the top based on the agenda, is the handling of error codes and the use of sub codes. Did anybody um go through the specs and or the tests that are um specifically the

RPC compat tests in Hive and find any assertions on error error responses that they felt were either over or under specified. Okay. So I I also haven't done it. I haven't looked into it. Okay, that's fine. We'll just keep it on the agenda list. Um, what about there was a ask for collecting maybe a list of libraries, frameworks, test suites, etc.

that might be asserting on messages uh specifically error code messages as responses from the RPCs. Did anybody look into that? Okay, that's all right. Um, one of the things that we talked about that we did not have a super strong opinion on was whether or not the tests should grandfather in existing clientspecific assertions.

Um, I am not sure how bad if at all this problem is. Um, does anybody have a sense of like, you know, h how often this happens? Um because what we needed to do was kind of come to a conclusion as to whether or not we want to grandfather those in and just keep them in the test forever saying that, hey, these clients respond a little bit differently, but they kind of mean the same thing or ask those clients to retroactively go back and correct them per whatever specification uh we we decide should be standard.

So, I haven't I I don't have a big opinion. I just remember from last time that someone from Nethermind said they would try to go back on some of the stuff that they added and um we have never had any representation from rest on this call but they are also in this situation where they have some extensions to some of the objects but yeah would be kind of nice if we get them on here or something, but probably we would have to invite them explicitly or take it to all core devs to announce that this call will happen

or whatever for them to come here. Either way, um chats. So, I will reach out to both Nethermind teams to ask them about that. I mean in general I can just check it right now but I think that I mean mostly I mean it's really mostly that like it's the it's in red we have one case where they added something and we in never mind we have a case where they added something else and these are the main cases where this happened and then we have this thing that seems to be somewhat universally accepted now with this transaction signature value V

in go Ethereum but since it's already kind of a part of the tests and like in some clients they already implemented that behavior to pass the test for example in in ref they implemented that and probably they implemented it off of the existing tests so they don't have this issue and as far as I can see in Nethermind as well they may have the name. No, actually they don't. Oh, yeah, but we discussed that last time. So, the main thing is that in mind they have generally seem to have a custom encoder per transaction type and this means that for the newer transaction types, they

didn't put the V. So, they are not aligned with the test right now. So that is like another thing that we have to decide on like should they be adding this into the output and I think they should but yeah that's like the last point but I think that that should be kind of it like in bisu I don't really see anything related to this uh which RPC calls are you particularly looking at with this I mean mostly I'm looking at like we have this get block type of thing so get block like either by hash or get block by number and uh I'm so right now I'm looking at the I mean I can just show

you this can I if if you want to put this uh oh here we go sweet can you see that yeah so now we are basically this should be kind of the latest test yeah this is from today and so we can see that like the way I'm assessing this is basically by we have this cool class here this like get block and for bizu for example I see that by the way now we have this we have new tests for each fork so basically I have added test so that each fork block is requested separately and uh I've done that so that we can

check whether there are some unexpected fields and um yeah for example Example, here we can see that Bizu is returning the total difficulty, but it's not in the test anymore. But I wouldn't count that as like a spec difference. It's just a it's just a a difference in the test. So this is not something that we I mean it's it's something that ultimately will have to be resolved, but it's not critical because the total difficulty was just removed basically. Yeah, there's no reason to ever consider grandfathering that.

Yeah, I mean it's lit. It's kind of a new thing. But if we check again for example here with ref then it's kind of like you can see that they have this thing in the receipts where they oh this is uh kind of an invalid one I guess but uh huh yeah this one. So here we have the block time stamp and this this thing is this is a ref extension this field and there appears to be some like the the way they did that is they there appears to be uh an open PR

somehow uh or maybe it's an issue Yeah. So there is this issue from 2022 and they implemented that in red for some reason and so that's why this is here but it's not in the spec. It's just an issue on the so yeah we we would have to think about if we want that or what's the purpose like it would have to be judged somehow right?

Yeah, but basically that's their extension that they have. And then for ref as well, if we check there is the the get block, they actually seem to be mostly aligned like the get block by number and so on. They all pass. So they are exactly in sync. Uh get block receipts it has a difference somewhere. Yeah. Well, it again this block time stamp thing. So that's that's the difference there. And then for what was that PR number for the existing uh block time stamp there?

295. Thank you. Issue 295. Yeah. And then for and then they actually don't really have I mean they basically have this this is the whole like if they resolve that somehow either remove block time stamp again or we put it to the spec or something then they they will basically pass most tests since all of these failures here like these failures but also these failures they are related to that not 100% though like the other thing that's kind of new is that I have changed the test chain a little bit. So now we are getting again to this kind of like these really old blocks.

For example, here this is a receipt from a very old block and it they we used to have the state route in the receipt and now we have the status. So ref doesn't seem to implement that. I mean it was I think ref was created after we had already changed this. So they don't implement this but this is something that used to be. So I don't particularly judge him on that. It's just something that they should probably know that like either way.

Well, that's a good one to think about. Interesting. Yeah. I mean, it's just old. I mean, I don't really know if we should really take care of that or if this is important, but definitely it's like this difference is due to like we used to all return the root and receipts and the status is actually not formally available until much later, but they don't rep they don't respect that. It was like I think it's like before the London fork or something. So it's kind of it was by Zantium. Yeah. Yeah. Super long time ago. And um Aragon is aligned except for that thing. Yeah. Um so they also don't implement that anymore.

And um Nethermind author thing like that's the main thing. like this is the this is their difference the author in blocks and for and the rest of the so these are all of these differences and then here block receipts yeah I mean it's also with the root oh they have the root and the status so that's also quite interesting yeah no okay anyway got it all right so I will um I'll herd cats try to get people more involved and say, "Hey, look, these are legitimate

differences between the clients and we kind of need to come to consensus on uh how to handle it." Yeah. Yeah. Yeah. Yeah. So, that's that is definitely the the big one right now still. And uh the rest of the differences are kind of small, I would say. And and none of these are like dangerous per se. like if you have a client like it doesn't really matter. Maybe this thing with the root and the status, but honestly, it's probably fine since nobody really cares about these stage roots anymore anyway. So I would say that like all of the differences we have right now are just like cosmetic in terms of yeah it's it's not it doesn't really hurt

anyone except that we have this problem that it's kind of hard to compare the tests uh like this because they are I mean we could resolve it as well by just basically allowing the test to be a supererset like that would be a very high level decision that we just say Like generally it's okay to return additional information. But I would say it's kind of bad also because that just opens the door to everyone adding extensions and we can never really get a handle on these extensions then right because then the the downstream users get to start relying on them and then they become a de facto standard that we don't even know about or control.

Yeah. So that is kind of the reason why it's maybe not such a good idea. On the flip side, it might actually be good because it will kind of get us the passing test like a lot faster if we just say like, yeah, they can return whatever as long as they return the fields that we want to see. Yeah. So, that's why I was kind of asking like, well, what is the blast radius of this problem? And to me, it it feels fairly small. Like, I don't it doesn't seem to me like this is asking for a ton of work here to get everybody parody.

No. Yeah. Yeah. It's definitely not It's definitely possible to to fix this. Yeah. Okay. Yeah. I mean then um I don't really maybe check the agenda as well. Yeah. Oh yeah. You you were saying uh error codes libraries uh client specific assertions. Yeah. Got a caller on the line. Dustin writing in says, "For test passing purposes, is it reasonable to have two counts summaries, one with without supererset?" Oh, interesting. Okay.

So, like a lax and a strict results set. Yeah. Yeah. Exactly. So, so that way it's not committing to this idea of people can add any random junk that they might that that users might start relying on. So at in a sort of formal support sense at the same time um in terms of as a procedural or a methodological sort of get get the hive uh issue count to zero uh process it can speed that along.

Yeah. I mean, if we wanted the pro the the count to go to zero, like the failure count to go lower, then we could just always make this change. But I don't think it's like really the goal here to to absolutely I mean, it's not a goal in itself to remove the failures. It's more like we want the clients to be aligned because we want them to commit to this process of extending the spec in a formal way. like the next step that we we touched on this in the last two calls as well. It's kind of like we are not even really sure how to decide on specification updates in general. So there's just no process right now by

which spec updates are decided. We just sort of put we we are in the phase right now where we're just trying to capture with the spec what's there in the clients and we mostly have it. So I kind of want to get to this point where we all agree on the spec as it is right now and we should have tests confirming that and then we can do the next step and say okay so what is the process of extending the spec and we can formalize this process by then saying okay once we have agreed on an update to the spec we will create new tests uh we expect client to pass these tests and so on. This is the same process we're using for example for

the regular like blockchain state transition updates with all core devs and we kind of want to have a similar process for the RPC. It doesn't have to be all core devs but it has to be like a defined process because right now there's no process at all. So I think if we just allow clients to do this we won't make any progress on this bigger goal of creating this formal process. And that's why I don't want to give in and just say, "Well, yeah, we'll get those tests to pass." And yeah, yeah.

Yeah. It does require some participation though. Like that's the other thing is kind of like I mean it's it's kind of inconsequential right now for clients to not adhere to the spec too much because they don't really get punished for it. Like if you just add an extension to the API like who's going to be mad at you except like I don't know some people who are more into the formal is it doesn't really hurt anyone either. So that's why this is unfortunately why we are in this situation in the first place is because we don't have any handle on like individual clients to say like oh yeah you did something bad there you're trying to like you're not within the spec. It would be much easier somehow if we had something like protocol buffers

and a version schema because then nobody could really extend the schema too much without breaking compatibility. But that's not really what we have with JSON RPC. It's like it's an open format with text fields so they can add at any time. Yeah. You can't you can't force your clients to all adopt like strict schema checking. So that's that. I mean we can basically the only chance we have to to make this process more formal is basically being very annoying with clients or like I mean I do see some progress here especially with ref like ref because they are running these tests in their CI as well they are definitely aware of the failures right now so they know which tests they are failing and

that is definitely a plus we didn't we used to not have that so they and they have fixed a lot of the failures that actually matter So it's it's progress anyways. But then like we were always we let's maybe it's a good segue. We don't really have to make this call too long. But so the last point is this thing about fill transaction. So obviously from a G point of view we absolutely want fill transaction. Uh I was kind of surprised last time or time before to hear that nobody's really implementing it. But so that we were we were saying like you Justin, you were saying like this could be a good example of something where we actually try to do like a bit more of a

formal process. So maybe some ideas how we could go about it. Yeah, let's put our thinking caps on. I mean it would have to be something like so either we go down the route of doing doing the interface EIP. So that's definitely a possibility. Right now we do have this category of of EIPs. Um it's a bit of a mess. Wait, what are you what are you referring to? Interface EIP. Um yeah, I can maybe again share my screen for this just so you can see it.

One second. Let me just see where I have to sort my tabs. Right. Okay. Okay. Yeah. So um you should see it now. So when you go to this to the EIP site you can see we have the categories here and we have the core category which is for changes to the state transition. We have networking which is for P2P and we have interface which is traditionally for everything that isn't the other two. I mean we also have some other categories but basically interface is kind of more for this kind of stuff that affects users. And you can see some of the final

ones. It's a very weird category because there's some stuff here that I mean I have no idea when these were discussed or in which forum or who made them like final or like by which process this was decided but I mean somehow these have made it to this category. Interesting. And do you have any any history on this? Do you um I know you've been cat hurting on the uh EIP editors for a long time now. Um does this predate your history? Do you have any light to shed on here?

I I think the question is less of a status and more of a category, right? Like I think I think it makes No, I mean it's fine. It's it's just a question of like the the question is what does final status really mean for interface. So for example, we have things like the watch asset RPC method. I mean this is not implemented by the clients first of all. This is like a wallet thing and they have here they specify the JSON options very strongly. I mean

there's a lot of specification text around what is basically just an address and a chain ID. So it's um quite something. And um I mean this is probably in Metam Masks. Um Oh boy, there it is. Yeah. So I mean they have it here. They have error codes and I mean this this is something that MetaMask supports and they support it very much. I mean they have a lot of it's very deep. Yeah.

But it's kind of a simple thing. So this and they even link the EIP here. So this is uh something that exists in MetaMask. But who else has it? We don't know. Like that's the thing. It doesn't even have an implementation section. It's just something that I guess they added because they wanted to standardize it, but nobody was around to standardize with them or something. So now it just or maybe it is I don't know maybe other wallets do support that as well. It's just something worth thinking about. Or this thing this is kind of like another wallet type of thing. It's like in the browser you're going to have this object in the JavaScript namespace that has these properties. So they I

mean this is relevant for application developers obviously but it's very hard to know like is this really something that is universally accepted or is this just something that someone came up with and wanted to publish basically. So this I would say the final has a not really a meaning here because it can also come like go out of use or something at some point like what if this is no longer used in the future like is it going to be final forever or do we move it to like historical or withdrawn or like this type of the process doesn't really work for this but it's mostly interesting to see like I mean the stagnant ones they I mean we

have the draft ones which are kind of new or well actually this one isn't very new either. this these types of suggestions, right? This is like, yeah, it would be interesting, but I don't know. Is it ever going to happen? Hard to say, you know, like this EIP, who's going to decide that? What does this decision mean? It's Yeah, it's okay. All right. So, so we're we're um if I can maybe like quickly add some light on this final status. So when we were like dividing the EIP and ERC categories, we we thought of this particular issue where interface proposals are sometimes not at all relevant to client developers. They are mostly re relevant to wallet. So uh interface uh is also a part of EIP and

ERC as Felix have rightly mentioned it like it may not be like you know adopted by client but may have been adopted by some of the wallets and that's why it reached to the final status. How however uh like these proposals which have reached to the final status they are considered to be there whether or not they are being used. We do not have superseded as an as a formal status anymore which was there at one point of time. So we knew that this would not be used and there is some new version of it. But right now the way standards are being maintained are uh list of specs which was once proposed and functionally they are correct. Whether they are used

or not is not on the editors. Yeah that makes sense. I mean I I mostly I just kind of wanted to showcase this because the thing about interface is that it's kind of a grabag of things but there are some valid proposals here and there are some I mean there are some proposals that I mean this could be used for sure to propose I mean here they tried it. So for example here they they really did try it for example with the get block by hash. This was maybe kind of an attempt that was a bit too uh fine grained like they tried to for example change get block by number to introduce the base fee. The thing is the base fee

was added there later. It's now called I think base fee per gas and they ultimately specified it in EIP559 itself. So, in in there, I think they somehow I'm not 100% sure, but somewhere in here. It probably No. Well, maybe it doesn't say that, but either way, it was added to the spec. So, we do have B per gas in the spec right now. And but it wasn't done through this EIP. It's just that they added this to I don't even really know why. and and they made an EIP for each method which is kind of a lot as well. And these are

all stagnant even though they actually became kind of current. So we could go the same route and and basically make a new EIP that says new method fill transaction with the following semantics and so on. But then it's the question okay so we have this EIP who is going to first of all who are we going to discuss it with like where should we bring it up? So to answer that question here um yes this was we should have a new proposal that's the reason you are seeing lot of like you

know maybe a single line uh code change proposals are there but if I remember correctly there was something related to blob base fee which went into 1550 during the London upgrade so that's why uh these proposals could not move forward that may be the case however If people think that there is any other proposal which is already into stagnant status and may work as the uh right set of specs for future, we can bring it back. But if people are planning to propose something new, it is always um uh recommended to go with smaller EIP even if it is one line change make it one. The reason for that is sometimes these EIPs are dependent on others which comes into the requires field. So

because of one proposal not getting say for example there are three dependent EIPs and one EIP is not moving forward the proposal has to be stopped and that's the recommendation is like go with smaller spec smaller EIP if you even if you have to do a number of EIPs that's not a problem all of them together the question is mostly just like what what's the forum for discussing it so I mean puja it's actually good to have you on the call because you are so widely connected in this community. Is there maybe like a like a wallet type of call where you guys did it at at some point discuss these wallet related EIPs actually? Yes. And the next call is

coming up on Wednesday. This Wednesday this calls happens every Thursday. Every third Wednesday and it is run Yeah. It is run by Sam Wilson and we do have a dedicated discord for wallet related proposal discussion. And so is it is it is the um I have never attended this call. So for me this is very interesting. But also the question then is like is is would you say the interface category for EIPs is actively used or reviewed on this wallet call?

Is this something that actually happens or was it also kind of long time ago or it does happen. Yeah, there are so many Yeah, there are so many wallet developers they join and they do talk about either some new uh proposal with respect to wallet that has been uh released or they are trying to propose or the existing proposal. I see. Cool. So I guess um it does sound like we should actually create an interface EIP for our new method that we want to add and it should be discussed on the wallet call maybe.

Maybe I want to propose one other exploration um you know thought exercise. The consensus layer they do they don't do EIPs for their RPC specifications do they? No no no no no. So the the but it's because they the yeah so the consensus layer is the because the the API is only provided by the node um they don't have this problem they can just discuss it on their like core apps call and that's that like it only really affects them there like the beacon API is I'm not sure if there's like a beacon API provider maybe

but it's just not so for instance RPC providers infrastructure providers ers don't really have an interest in that um interface. Yeah. So that's like a the the difference with the execution API is that the execution API is provided by the node. It is provided by RPC providers and by the wallets also. So there's like three stakeholders who all have independent implementations or at least in the case of the providers they have a load balancer that is aware of the semantics of the method or something. So it's yeah definitely yeah I'm back on I'm back on any IP I mean the main thing is that we have

this pull request so that's kind of the thing I mean this B request is a bit out of date but basically thing is that we did create this pull request and um it just adds it but it didn't really go anywhere because we were not so sure like who is going to authorize the merging of this. So I guess we can go with the EIP and see how it goes. I would say the EIP is pretty easy to create. I'll I'll try to get that done.

I'm not sure if we will get it done by Wednesday. Probably not. Maybe it will have to wait for the next wallet call, but I would say the wallet call might be a pretty interesting place to actually surface this. And my we can also try ACD But then the thing with ACD is that it might not get a lot of responses there. So people might just say like, "Yeah, okay, whatever. It doesn't really affect me." And and that's that. So I'm inclined to start with the wallet call and then move our way up to ACD.

Yeah, that's how I was thinking as well. And then potentially what we could do is kind of try to use this like I think that yeah, the EIP makes sense to me, but basically let's try to make it like this. So we propose the EIP we propose it on a wallet call see if they like it once that's in like once we get like some kind of signal there we could then bring it on SD but then we can explicitly say that like we just want to mention that this is being discussed on the RPC uh uh interop call and the next call is on that date and then basically just as an announcement to bring more people into this call as well because I have a feeling that ACD is kind of a weird

venue for this. Yep. I would also maybe uh propose it on roll call and then I don't know that we have one for we don't really have an equivalent for infrastructure providers but I would be happy to kind of do that asynchronously though and kind of reach out at least to the folks that they just come they just have to come on here basically. Do you think roll call is all right though? I'm sorry. I would like to add one more thing here. Um, as as a process, we are now going to start an additional office hour, EIP editing office hour. We generally have it once in two week covers both EIP and ERC. But Gajjender

Singh who is one of the EIP only editor and he has now started taking this office hour in which we are discussing EIP's related problem uh recently kev come up with hardware proposal hardware uh EIP like what should be the specification it did not get enough attention in the ACD call because people don't want to dedicate the entire call on deciding how it should move forward but these kind of proposals can also be brought into the editing office cover where editors will be there and authors can ask all the question and get all the support that needs to merge this proposal.

Okay. Yeah, thanks Pio. All right, cool. So, that sounds like progress. Um, I will I will see that we can get this EIP created, but like I said, I it won't be till Wednesday. It might take a bit like a week or so because we have some other stuff to do. But yeah, that's that might be a good step forward. Awesome. And then it's the question. So, we have some other proposal as well. I don't want to share screen again, but basically I'll just say it. Um so we do have a bunch of other proposals uh in issues and pull requests in execution

APIs and then the question is for some of them it's just um smaller changes but there are also larger ones. So if um the question is then should we start telling people that they are supposed to create EIPs? I think we'll know the answer to that after we do this. I think I think this is our vertical spike, right? We're going to do a we're going to do a test of this process and we're going to run through it and if we like it then yes I think we do do that.

Yeah because like multi call, right? ETH multicol. People have been talking about ETH multicol forever. There's PRs for it. There's, you know, issues for it, etc., etc., but there's no E for it. So, I think if this works, then that then we just direct them to do that and we work with them in the editing process. Yeah. Yeah. I mean multiore e simulate definitely interesting one but I also mean these like the main problem that I want to highlight is that there is um there is a category of changes that can be done in the client by just doing some implementation work but there is also another category of changes that can only be implemented in the client if

it has an additional database index. So this is for us always the kind of thing where we try to it's hard to it's hard to say for us like what should happen with these proposals. For example um let me just quickly give an example. Recently we have received a couple of requests where people want to have um access to the transaction EVM return data. So, I personally think it's a bad idea because the transaction return data has never been used for anything and is definitely not indexed by um any client as far as I know, but doesn't keep people from wanting to

access it. The qu I don't know what they would do with it, but I mean it's Wait, wait, wait. You mean like historically or like in line with current block execution? No, no, no, no, no. So basically what was proposed I think it's actually open as a as an issue. I I I cannot find it right now but I know that it's something that uh someone wanted and they yeah it's actually a pull request. So someone created a pull request on the execution APIs. It's pull request 542 where basically they added this field return data to the receipt and they were

like this should return this field should contain the return data of the transaction for all transactions. Wow. Okay. So obviously this is not this is not available right now. Like this is literally just not available because nobody has it. And but then it's like for me it's kind of an interesting example because then it's a question like okay I mean obviously this one person wants it so they have proposed it but it doesn't mean it's going to get added but what if this gains significant traction and people say like we absolutely do need the transaction return data. Usually this process has been driven by the client authors. They will say yeah well I mean the client supports this so we give it to you. But

in this case it would have to be something where client actually have to implement an additional index. It's going to take I mean it's going to take significant space on disk for example. Sure. And I don't really know like is this I mean this specific thing is probably never going to happen but I'm just trying to say like in general like these things do come up sometimes and then it's a question what should be the process then like this this I mean that sounds like a full-blown like EIP and all core devs like process like that is a big one there there's a big impact I think you know people like Kev who's thinking about um you know node requirements Like that's definitely a discussion that needs to go down.

Yeah. Yeah. Yeah. Yeah. So all of that. So then it's kind of the question for me like we have to come up with a framework for judging proposals against the RPC because for I mean we've always done it. I mean we can just literally continue doing what we've always done is like when people propose changes to the RPC, we're just going to tell them you know this change is fine. We can probably make it or we tell them this change we cannot make because it would require client consensus and a database change. So we do have this internal framework for for deciding on these things where we're just going to say you know like we cannot do this or we can do this but I would like to see it more formalized where we basically have to somehow make it so that more people can

participate in this judging because it shouldn't always be me and I don't have the authority on it. Like that's the thing I've been telling people whenever they come for example to the death issue tracker with these kinds of ideas. We've we kept telling them like you know it's a fine proposal but it's not possible right now. And then I mean nowadays people come to the execution APIs because that exists now and they put their proposals there and then like occasionally I go through them and I'll answer them and be like you know nice proposal but it's impossible. So I feel like it shouldn't always be me who does that or we should have some kind of formal framework that says if you want to propose something like that there is a path but as the requirements in your proposal like grow the amount of effort

you have to take to actually get this through the pipeline will also grow. So there there's got to be like some kind of process that we tell people they have to follow in order to ultimately reach acceptance of their proposal. How much process do you think is really necessary to do that? Like um depends on the proposal like that's the thing. If they are if they propose to add a field to the receipt that is already like for example the block timestamp thing that is easy to implement because in every place where we have the receipts we also have the block that they are attached to sort of like it's it's not really a big difference right now at least. So I'm pretty sure all clients could easily implement this block timestamp thing just not even judging if it's useful or

not just like from an implementation point of view in the nodes this is super easy to implement. It's just putting an additional field to the JSON that probably exists in memory of the client at the time of serving the request. It's a different question when it comes to these things that require database changes for example, but it it's not always easy to tell for people that like some things are easier than others. So I kind of but I think I I don't see much of a difference as far as process is concerned that current EIPs have. like maybe it's just maybe it's just engagement with the submitter saying that okay here's the problems that we see that you're going to encounter when you embark upon the traditional EIP process going through all core dubs

here's here's what we foresee here's here's how you can mitigate them here's how you can get in front of them and say like oh yeah I thought about the um you know I I've documented that this is going to require a new index and this is going to require um x amount of increased storage space um all those kinds of things so I I guess what I'm trying to do is I'm trying to air on the side of creating additional process and then maybe just add a little bit of social lubricant to um the existing EIP process. What do you think about that? No, I mean the idea is good. The idea is good. What what I'm trying to say is there are some things that don't require as like I'm mostly just saying this whole full-blown EIP thing where you try to you know like create demo

implementations in two clients or whatever and you know like try to convince everyone and make like a massive argument that's not really needed for simpler changes such as this block timestamp thing where they just propose like let's add this info that we already have. We don't really need to create like a massive EIP process for that. It's much much easier to accept this versus changes that like I'm just trying to basically figure out how can we relay to people the difference between changes that are easy and changes that are hard.

You know what I mean? Like it's Yeah. Maybe maybe what we need to actually relay is the other direction like hey here's a trivial change that somebody wants to do. By the way, core devs, you're going to start failing RPC compat tests when we adopt this. So, so here here's your heads up. At some point, you're going to want to adopt this trivial change. Yeah. I mean, yeah. Yeah, sure. Like that's the thing. It's much easier and we have done it in the past by basically just Yeah. Like we added it in G and that's it. But it's kind of Yeah. It's just that some things we cannot just add.

Yeah. Yeah. I mean there's a there's some other things. I mean some some proposals are also more like in the middle. For example, Phil transaction it does require logic in client but not a lot of logic but it's definitely something custom. So it's this is in the middle. It doesn't require any additional data to be stored but it does require additional logic. and and and by that I mean it had it's a new method with totally new semantics that accesses like different things that are probably available in the client in most cases.

So let me say it like that. So it's kind of in the middle there. Whereas some things is like I just want to add this quick field that's already kind of there then that's like super easy or I want to add this other thing that's a whole new index that's kind of hard and then adding a new method that like does something with the existing information. It's kind of in the middle and I would say this a similar thing to for example fill transaction is this thing that g has which is uh e call overrides. It's also kind of something but um we are not proposing that for the spec because it will kind of be superseded by ETH simulate.

So but we used to have this like before E simulate or ETH multi call or whatever it's called. But we used to have this already kind of in G. It's like in ETH call you can put an additional parameter with overrides where you can basically set the code of a certain contract to something else for the duration of this call in order to allow you to I don't know query some information that the contract doesn't have a reader for or something like that. these um uh this this is also kind of in the middle I would say because it doesn't require new database but it does kind of require significant changes into the logic because you have to implement this override stuff in your state

implementation and so on. So it's definitely a bit more complicated than just adding a small field. Yeah to to reiterate I'm hearing two at least two maybe three different situations. One is wait for permission and the other is ask for forgiveness. Right? So like in in one case you know the extreme case like the receipts scenario you you wait for all core devs to say yes you you should do this and go ahead with it. we are aware of the impact and we are planning for it and accommodating it as opposed to oh you added a new RPC and now the RP now the RPC compat suite is breaking for these guys ask for forgiveness okay sorry is

it is it can this still stay in right um the the middle ground that you're alluding to I don't have a good metaphor yet yeah I mean the main thing is just that like I would say that intuitively for me this like EIP process with all core devs and discussing it and like creating not maybe not just RPC tests but also I mean just basically it these like very complex changes they would definitely require multiple rounds of discussions and all of that and intuitively these definitely require

like EIP and so on but Then for the smaller changes for example even just adding a new method that does something new maybe we can like my hope would be that longterm we could resolve it on for example something like this JSON RPC call we would be able to actually introduce new methods here and make clients implement it without going through the old core devs because usually this core devs process is not really prepared to judge the usefulness of these methods anyways like that's the thing if we tell people that that's for example example why e simulate it had its own call where it was discussed because it doesn't really make sense to do it on all core devs most people are just going to be like oh yeah well I

mean it doesn't affect me I'm not a user of it so what can I say about it so this would be my hope that like these medium difficulty type changes they wouldn't require ACD and the easy ones they definitely shouldn't require ACD So, this is kind of I'm not I'm just not really sure how to how to how to like where to write this down or how to relate this that like it's an intuition anyway, but I think it's something that is worth.

Yeah, it is. It is intuition, right? It is a little internal to the devs, but we can provide a rubric for categorizing these. I think like I think the nature of most of these calls will be outside of protocol, right? Like that's that's the vast majority of what they're doing. many of them are going to want to be standardized across the user base, meaning wallets, L2s, infrastructure providers, and some of them will have performance impacts uh operational impacts to node users.

So, I think we can likely outline a rubric um with with with those things described and some guidance on, hey, if your thing falls into this category, here's the amount of process and overhead you should have. And we always want to air on the side of minimizing that and yet still keep the complexity of Ethereum safe. Yeah. Okay. Yeah. So I'll I'll I'll think of something to to to to document that more formally. I kind of just want to it's also for me kind of important because just so that we have a way of dealing with the existing proposals. It's kind of where I was getting at like we do

have existing proposals. I would say about 10 of them or so right now where we have to make a decision like where are we going to go with this? Should we just flat out reject a proposal? I don't know. it's maybe not so great or should we just provide a path forward and be like if you really want this you have to follow these steps and it's going to be a lot of work or it's going to be not a lot of work or you know just so that we can actually be done with the proposals in their current state because most proposals right now are just hanging out as like PRs and issues on execution API with no way forward.

Yeah, I definitely prefer the latter. I don't I don't think any of these proposals are so ownorous or um difficult that they should be totally torched and started over. I think they can all I think everything can be saved. Right. Okay. So then we have to but then we have to outline it somewhere like how this actually works. Yeah. Yeah. Okay. Um so we got five minutes left. I just want to be uh respectful of time. Does anybody like what they're hearing and want to contribute to this conversation? And so it's not all on Felix's uh shoulders like he's got some writing to do that he's proposing to think of. Um does anybody want to contribute and help? I do. I'm I would love to u you know workshop some some

phrasing of these different categories and maybe put together an outline for people to follow. Um does anybody else want to participate in that? All right. This is me high-fiving Felix. All right. It's fine. It's cool. Just awesome. All right. All right. We got four minutes left.

Does anybody want to take the floor? I would like to maybe just suggest a couple of things. I loved all the information sharing or thought sharing what happened here in this call about possible pro processes or maybe something that we may need in future. I would love to encourage to you like document all of those things as Felix said. And if this is about a process that we think can be um across all the breakout rooms like Justin were talking about rubrics and certain ideas like what needs to be done when we are into certain scenarios. It would be a good

idea to document them as a meta proposal. Depending upon what would be the frequency of changes expected with that proposal, we can keep it living uh and uh that may be helpful in future to like solve smaller issues in these kind of breakout room meetings, smaller spec changes and the bigger one would come up with another proposal normal core or interface proposal. So, EIP is a good way of documentation because that is historic um thing that we are sharing with not with the present developers but upcoming or uh people or students who would want to become potential developer one day. So, we should maintain the

process of EIP. However, if there are changes suggested or requested, we are open to discuss in EIPIP meeting or just document it into a proposal, put it on the GitHub and fellowship of Ethereum magician. I'm sure we will get some engagement. We'll be in a position to come up with a good process for future. Okay, I love that. Um, and I'm going to include that in my action items moving forward. I think one thing I would I would consider though Puja is is maybe we write the meta EIP after we've done this a couple times like so if we're going to say fill transaction is our vertical spike then maybe we start pulling in some of the other ones that

are floating around to see that that they're salvageable and how they work and then once we've done to me three is the magic number once we've done three of these I think we have enough experience that we can really codify that stuff in a meta EIP and say hey here's the process that we've done a couple times and it and it works. Um, but I think that's a really good target actually to keep in mind um for the near future. Rad two minutes. Anyone else?

Well, cool. That was a super productive call for kind of yoloing the agenda. Thanks everybody. Thank you. Thanks, folks. See you on the internet. Yep. We'll

see what happens.