RPC Standards #2

Transcript

hi everyone welcome to RPC standards call number two we have a brief agenda today there is four bullet points listed on the um um tracking issue for the agenda here I will post it in the zoom as a reminder to anybody um and then um either we wrap early or we can open the floor for questions comments and concerns uh so first off uh I found a good example of um some of the thing that we've talked about in the past which is asserting on Raw error messages uh we

spent a little bit of time talking about aor handling and uh how it should be done how it should be considered in the testing etc etc um if you look at the first bullet point in the agenda you'll see an example where um this is running against Basu um where we failed a RPC compatibility test here um for a couple of reasons but one of them is it does assert on a um go specific specifically a guest specific error message um so that's cool that's exactly what we were looking for we were trying to find those types of things um in order to filter them out of

of the hive tests and then figure out you know how they how they got in there in the first place my guess is that they got in there because we're using G as the test filler and so you know I I don't really have any problem with that I think that makes a ton of sense because G is the reference abilitation but we may need to filter those out or um you know ignore the message as uh part of the test that we're creating any any thoughts or considerations on that has anybody seen this in other

places um is this a first time thing to people is this a surprise do we suspect that there's not much of this going on or maybe a ton of it okay sorry this is my this is my first time uh joining or looking at any of this so I have no context but uh no problem welcome um if you have any context that we can help you establish just let us know cool ESS just here to just here to listen right we heard these calls were

starting wanted to uh hop in see what's going on see if there's anywhere we can participate or help but otherwise yeah just here to listen for now yeah no problem um what team are you with uh we're with uh snake Charmers okay yeah I think the three of us are the um we're on the EF python team so we maintain web three Pi mostly um and we had a chat with both Felix and Marius that said the RPC spec needed some um more hands on deck so oh fantastic yeah so um I'm Carrie um and then Paul and fipe are both um on my team too Brad so

oh that's very exciting thank you thank you send in the calry this is great yeah so I as far as the error messaging goes I you know I think there's I think that's probably the biggest place that we see discrepancies between clients um but yeah it'd be good to stay on that awesome awesome awesome awesome okay great um how does that um maybe let's talk a little bit about meta stuff here right so I think this is one of the things that we keep circling around and we haven't really gotten any traction on is like what's the process here like we found a thing that's broken in the spec right do we just aggressively start updating it um do we

start building schemas or stronger type checking or like what's what's the plan here when we when we find these little things that definitely need to change and the problem is is that they're undefined and so everybody can say well I'm right you're not right etc etc like what is what does your team want to see as far as a process I guess is is my question um I don't I I'll speak for myself I don't know that I have much of a preference for process it would be nice if there was like some document somewhere um and I know there was either an EP or an ERC that had all this stuff at one point but it's my sense I haven't

looked at it lately but it's my sense that it's not very well maintained um and so I think like I don't know about the process exactly but just like having a place to point to to say um this is this is the standard that you know whoever cares agrees upon type of thing so yeah I don't know maybe that's just pull request and GitHub but how is it how have you been doing it in the past that's I don't think these are new calls right okay yeah that's kind of what we're trying to build you mentioned that you thought that there was an e or an ERC or something in the past that kind of covered this um is that maybe we

dust that off and sharpen that a little bit yeah maybe that's the best place to start um for now who all is involved in this um process usually um you yeah I mean I'm I'm consistently here Felix cares about it and has been here consistently as well he is otherwise obligated today um and then you know otherwise it's it's intermittent participation I one of the audiences that I would really like to get here is RPC providers so your alchemies your uras your people like that and you know they all have an incentive to run

multiple clients which we love and we want to encourage and then they have to build these weird load load balances in front of all of them to kind of normalize requests and responses and handle their routing so we could we could really simplify their lives quite a bit by better standardizing on these things and then expanding the coverage of what is standardized right now yeah yeah and then I think that like we all learned a ton from the engine API and going through that process and I think we want that level of uh specification quality across the board yeah I think that makes a lot of sense who um who maintains like the engine API spec like are there specs for that that's that's kind of weird is like

that's kind of the consensus layer has been driving that uhhuh um but it's the execution layer that needs to implement it and has to deal with it so it's it's actually outside of the EP process okay there are often new Eeps for new features that are introduced that touch on the engine API and add it but the the engine API itself uh is really just an execution spec yeah all right cool so maybe we can find that eips and erc's that you're thinking of and post them async in the RPC channel to start as kind of a a rout um

yeah for folks to reason about and work on yeah that sounds good is it the um in the uh research and development yes is the research yeah yes research R&D Discord there is a Json RPC API Channel okay cool yeah do that awesome um let's see one of the other things that we noticed is uh apis kind of sometimes represent things as hex when they could be decimal um and developers find this very irritating so anything that is like an integer

value um when we represent it as hex is another set step and a source of friction for developers that arey trying to debug things and do analysis where they kind of have to keep a calculator open and you know be be converting things back and forth between hex and decimal so I could have swore there was a PR either into the spec or somewhere else that was proposing everything that's not data is an integer a decimal integer usually wrapped in a string because those decimal integers can be huge um and then the only place that the rpcs would use hex is for raw data so binary

data usually [Music] rlp I could have swore that light client had a PR or an issue that had been opened somewhere addressing this and last week I was looking for it and could not find it so I have a to-do item to follow up with him to see if I just hallucinated that maybe I'm talking to the wrong person etc etc um but I think I think that would be a cool thing for us to add to the RPC specs and um yeah so like for instance Bas here right now kind of does both it'll accept input and it'll try to be smart about it and figure out whether or not it's decimal or hex based on a

leading zerox uh to the string um we we could uh simplify things a little bit bit by getting rid of that um and yeah yeah it's just kind of an improvement to the spec that that we found um that kind of is very Broad and goes across the entire thing um pause for a moment there okay uh one of the other things that we

noticed this is item three on the agenda is dealing with kind of aged out Fields so for instance total terminal difficulty we don't or total difficulty rather um we don't really need that anymore right because we're not doing we're not doing proof of work um it has been removed from uh the execution apis uh but that's kind of a weird one right like if I'm requesting a block that's pre- merge shouldn't it still have the total difficulty field on it um and so this is maybe an opportunity for API versioning or I generally would like to avoid API

versioning whenever possible you know this could be a case where you just make a field optional and it stops being returned later on uh but it is a it is kind of an undefined point that's that's a little bit weird so I don't know do folks have any um preferences on these types of situations um I don't know that I have a huge preference I I I also don't love the idea of API versioning um but I think making it optional makes

sense um and maybe if it's only you know if it's only a pre-merge block it like automatically gets returned I don't know if that's possible in the client but um it seems it makes sense yeah it seems like Json should be fairly accommodating of that right yeah the clients that that parse it should be able to to handle that so might be thing that we suggest I I don't I don't know of any other examples that kind of spring to mind um maybe preand Dow um yeah some other mer specific things um could be the requests that

we're adding in pectra might be another thing that um is just not present in earlier blocks but optional in later blocks um so maybe the action item here is you know a paragraph and whatever our document that we put together is on optionality and you know when it's allowed when it's not allowed how it's represented and how how clients should deal with it cool um and let's see the last one is a link

to a PR execution API pquest 600 this has been out for a bit yeah this has been out since October and I guess what I am asking for is not sure if I'm asking for anything why don't we

just socialize this maybe a little bit harder to get folks to approve it maybe that's all that needs to be done here here so this is specifically addressing improving error handling for the call methods and I believe the thinking here was talking about a um vertical slice through the API where we use this as an example for improving our error handling and error reporting so I suppose what would be fun would be

for anybody in this working group to kind of weigh in on that PR and imagine this approach being applied more broadly and deciding whether or not that's a good thing or a bad thing and if you like it then I guess we just uh weigh in on this approve it and um adopt it the pr itself does list three different issues at the top um that all kind of um they're all symptoms of this

problem yeah it'd be good to get this standardized I can take a look at that today awesome well that's all I have on the agenda we're only 20 minutes in so do y'all have anything else you want to talk about not for my end um yeah thanks for having us we'll plan to join um more frequently from here on out and see where we can lend a hand you're very welcome it's awesome to have more

support here I'm just kind of like I'm an amateur cat Wrangler I'm trying to trying to trying to do what Puja does in her sleep and this is this is an area that I think a lot of people are really interested in and just does not get much attention and it's you know it's it's kind of old a little long in the tooth the the the RPC methods have been around forever and um Everybody kind of looks at the way that the engine API works and wishes that they had it elsewhere so I think this is doable I think um we definitely have engagement from client teams when when we need to make changes

or update things um everybody that I've talked to has been super into it but they're also kind of like you know they got other stuff to do and the work that eventually gets done is probably pretty trivial for them to do they kind of just need somebody to make the decision Speck it out uh get the tests in front of them so that they can see that they they work or don't work um and then they and then they'll just grind them out today that looks like the RPC compat tests in the hive Suite okay so that's that's what we're imagining being the real um driving mechanic for cleaning all this up e yeah thanks

Puja all right rad we'll close it early then nobody else has anything else they want to add um but a pretty productive 20 minutes now that the calal is here so thank you and um yeah most of this most of the work will actually get done on Discord in the RPC canat Channel Etc ET ET cool um it's all very asynchron so thanks again awesome thank you thanks y you can have some time back see you later awes thanks