RPC Standards #5

Transcript

Okay, let's get started. Hi everyone. Uh, I think it's being recorded. Yes, we're being recorded. Uh, this will get posted probably on um ETHCAT herders on YouTube later. Uh, we have an interesting agenda today. Welcome to the RPC standards call. Uh, number five, uh, we have uh, a couple of cool things. We have a brief demo. Uh, docsaurus has been added uh, so we can view docs locally. um we can discuss our process uh from a technical perspective, not a governance perspective, but from a technical perspective, how to get from specs through to the RPC compat hive tests. Um so I think that's that's an interesting conversation that we can

have. Um I'd also like to talk about filling tests. Right now everything kind of revolves around GU. That is not crazy. Uh but it's a little less than ideal. Um, so we can we can talk about how that works. Uh, whether or not there are any alternatives and what we think about it. Um, and then we have a number of PRs to actually take a look at and discuss. Uh, one for adding timestamps uh to log receipts and another for coming up with a better way to manage our error codes and the messages that they emit. uh when we want to cover those in tests. If we have time, um maybe we'll have a little open floor and we can

discuss some of the broader things that we need uh as far as developers might need. So, you know, it's it's one thing to have a technical process in place that outlines everything, but since this is kind of a writing exercise when you're writing specs, um what's our editorial process, right? Like what are what are the types of things that we prefer? what is style guide um etc. Um so any questions here at the top before we jump into things? Yeah, I think all good. Let's go.

Awesome. Welcome Zay. I understand you're from um the RPC open RPC project. Is that right? Yeah. Yeah, exactly. Awesome. Awesome. Awesome. Okay. Um good news. So let's do a brief demo. If I can share my [Music] screen, it's really pretty straightforward. Um, oh no, I'm not allowed to share my screen. Oh, is it because I'm not the host? Let's try it.

Sorry, folks. One second here. All right. So, I can rejoin before I can share. I'll be right back. It's going great. Okay, now this time I should be able to share. There we go. Okay, got this. Get this out of the way. So what folks may have recalled

from working with this is our execution API. Can everybody see my terminal screen? Let make sure I have my whole desktop being sh being shared. Yeah, I can. Okay, great. Thanks. All right. Um, so this is this is our execution API channel, right? Um, we've since installed Docsaurus and you see that this is just going to be a new thing that you have to do. I don't know if it's been added to requirements yet. Uh, but that's a whole thing. But now, if we run this, this is all special thanks to Acolyte um, who did a little bit of the updating

that we needed to get this running. uh now it'll spin up a server and you can actually browse the docs locally and so um you know it's it's docysur so I I'm not familiar with it but I understand that it's fairly common and um it's basically just gives you a a demo of the different API calls example requests expected responses etc etc I think there might be some issues let's see yeah I think there's some validation issues over here on the right with the params and stuff that are still being looked at. Um, but it's a start. Um, so that's that's fun. That's progress. Um, I encourage folks to take a look at

this, make sure that it's useful. Uh, give us feedback uh when it's not. And of particular interest, I think is kind of this landing page here, right? Um so the JSON RPCs themselves are all getting automatically sorry the the entries for these are all getting automatically generated based on the specs. What we really want to focus on though to add value I think is a lot of this stuff the narrative the introduction the contributor's guide right these are the things that are going to help people understand the writing style for the specs moving forward. Um so you know take a look at these pages. These are kind of just uh initial first draft uh

open PRs into it. Come up with discussion points on this call. Like if you think that you know this is a problem let's let's talk about it on the call. Add an agenda item. Right. Um so questions, comments, concerns. Zane, what's up? Yeah. Um this is awesome and and everything. So um as one of the co-founders of open RPC um there is like a mild concern. So um essentially the reason why dogs were struggling to run locally is that there had been a bit of

um rust on the original like open RBC generator that actually generates the docs. Um so at the start of the year um myself and like Shane like overhauled the uh infrastructure uh and so I found an issue. So I don't want to take up too much space but I just did want to say that like there are a couple issues with this. So with the docuour docs and the JSON RPC execution of the APIs um like it still uses like window.ethereum Ethereum hardcoded. So you can't point it to any sort of RPC endpoint. So if you

were like uh like say on some other network that like still has like git block for instance um which they all should because the spec you wouldn't be able to necessarily test that unless you kind of went through this meta mask. Oops. Um the other thing is that there's validation issues um with the forum which I think you saw and then sort of the final thing is um actually because uh we no longer have access to the docu plugin we can't and couldn't update it to meet the new versions of the spec.

And in the new spec, we have a couple of major features that are like going forward the way that we'll end up upgrading the um the underlying like uh specifications um called the extension spec. And so there's no way to really support that. So this is really cool to hear that you're interested in um having more pages which Gatsby can do. And I think Acolyte raised that question as well. Uh I just didn't catch this PR before like it landed back uh I think a day before I reached a day after I reached out to light clients about all of the changes that had happened. Um so it's kind of a

weird confluence of things but no problem. So now this I get a good sense of like what Acolyte was saying that um about the additional pages. Yeah. Okay. So cool. That's my long long spiel. No, that's awesome. And and super important, too, because I am not a JavaScript person. I am way out of my element on this call. Um, could you uh explain a little bit about what Gatsby is and how it kind of fits into this problem space alongside or as an alternative to docysaurus? Yeah. So, Gatsby is a very similar um CMO style management. Gatsby maybe predates Docu Source and in terms of like being one of the ones that you

could then write markdown and have these all be like markdown or markdown X pages and then have it like render in docs. Um because I think that's like the biggest benefit is that you don't really necessarily have to go around like designing pages um and HTML and JavaScript. um you can just simply write the markdown and then you have a theme that gets applied and then it creates all the links and the sidebars and the the title um just like this. So it's essentially the same thing as docysource um just a different ecosystem. And the reason why we updated the package and the generator um to

maintain uh Gatsby is just because we were aware that execution APIs needed an update to be able to run like locally and we didn't want to break anything. Um, so like literally you can just bump the version and then you get like everything working locally. Um, the same as it was before. Um, but it seems like there are some improvements that you want. So, uh, that's what I would say is pretty much Gatsby's thing is that someone can develop a theme which we already have. Once a theme is generated, you can then customize that theme um mostly through non-technical like configuration or single JavaScript

or JSON. Uh and then whenever you want to add pages to it, you just add markdown and your pages directory and then um it will render the additional pages that you want. So um for instance, the introduction, what are execution APIs, get started, um all that's just defined in markdown. Um, yeah. H, cool. All right. Thank you. That's super helpful. Um, it sounds like the recommendation is to switch to Gatsby. Um yeah, I I dare I say to roll back one to either roll back the change or update the change because um the

problem for running locally was is that um the code had drifted and had pegged people back and earlier version of node. Yeah. But then since we did all of the changes, we basically completely overhauled the entire ecosystem. Um so uh you could use modern node. Okay. So what if um somebody took it upon themselves to do the Gatsby upgrade on a branch and then next call we can do like a side by side and folks can kind of decide which way they want to go.

Does that sound like a a useful exercise to people on the call? If that's what people want to do. Um I think uh Simpson Raj or Sims he has uh Sims he has a uh branch in a PR that runs the Gatsby locally as well. Um but we'll get to that. Yeah. Yeah. I can demo it. uh during my time. Uh I can also show how it ties to the extension specs uh but I'll leave it for that later.

Awesome. That's perfect. Okay. Fantastic. All right. Thank you, Zane. That was super helpful. Um I think by next week we can probably make this decision and have something reliable and local for folks to view their um spec changes. Okay, process. Um, one thing I wanted to talk about from spec to RPC compat, right? So, I think we all expect the RPC compat suite of Hive to be kind of our metric as to whatever standards we quote unquote come up with, they're

adhered to and all the clients um, you know, respect them. So the process for getting from spec to RPC compat is interesting. Um I started playing with this. Um I'm not great at it at the moment and one of the things that I noticed is that you kind of write the spec, right? Um it goes into YAML, the spec is generated. Um, you get example requests from your spec. Um, you fire them at an instance of G that has been preloaded with a

specific blockchain. And then whatever responses come back go into the tests and we call this process test filling, right? The tests then do an exact string match on the request and the response. Um, and so for instance, I think we'll probably get to this when we talk about the error codes and error handling right now. Um, it's a little problematic. You know, our tests don't have a lot of latitude. They're very, very, very strict. Um, and I don't know that that's a bug or a feature.

Um, so I think that's probably one of the first things I'd like to discuss more broadly is like what do people think about a test suite that is more sophisticated than just doing kind of a strict uh string match on the JSON output? Um, does anybody have any experiences that they you know like to share on the matter? I guess uh like you mentioned this is where the error codes come in. Yeah.

Um yeah, string it it's exactly the same issue we've been facing uh internally and uh I've noticed a lot of people complained from the community uh uh the the string matching isn't isn't great. um exactly why we started writing the spec for error codes. Uh again, I can discuss that later, but that's like like you mentioned, string matching isn't isn't great at all. Thank you, Simpson.

Yeah, I think um like I think that general game plan kind of makes like sense. uh years ago when I used to work in work for Ethereum Classic um like we also generated a test suite like that and a lot of the things are just like if you have the blockchain in a particular state then it's great for testing things like uncle block and then the range of responses that you get from that because it's like the blockchain needs to be in a particular state in order for like the gaff response to return back

uh specifically what you're looking for to make sure that okay it did get the uncle block from uh it did get the uncle from the block uh and like it got all of them or uh it did the proper thing for figuring out the heaviest chain and all these other sort of questionable like things. Um, so I think some of the exact matching probably makes sense, but I think when you get to multi-client compatibility, um, you kind of need more uh information about like uh like Sims was saying

earlier, it's like you need more information about how to like what is acceptable and the acceptable range for the response. Um because a lot of clients I think even back then which was about four or five years ago and like parody client was a lot bigger um back in the day um it uh like parody would do different things than what gaff would do um in terms of returning error codes uh and so you'd kind of have to like know that.

Okay, thank you. All right. Um, counterpoint. Are there other areas of the RPC API outside of error messages that we value ambiguity? So my my counterargument being yes exact string matching is too flexible. We don't actually need that flexibility in anywhere other than these error messages. Is that true or am I just being a negative Nancy?

Um okay no one answered so I'll take the opportunity. Uh I did notice uh I I do feel that we need that flexibility. Um we cannot probably give error codes for all use cases. Um what I mean by that is um some chains behave very differently than rest of the other chains. For example, uh some chains have run uh RPC clench as a just a client and doesn't do any execution forwarded to maybe some mirror nodes or uh completely different architecture. Um in that case

um the same error code could mean same error message could mean a completely different thing for them. Um I've noticed a couple of instances where I'm so confused if I should assign a error code for a certain error message or not because uh the error message in a client let's say Basu is completely different from what we get from a different chain which has their own client. So I I I do believe the string matching or the flexibility is needed uh at least until it all evolves and gets standardized much more.

But what we can do for now is probably focus on the bigger use cases where most people rely on uh or the common error messages or code that is particularly useful for the community rather than focusing on every intricate details of every single chain or every single client. Um we can you know probably take them use case where people do rely on like know insufficient balance. These are really straightforward. These should remain same across different client compatibilities but it could take some uncle blocks or difficulty where some chains have difficulties and some chains don't. Um or um yeah a few more examples like that. I do believe for now some are

a bit of a flexibility is is still required. Okay. Okay. Cool. Thank you. Yeah. I mean it's JSON right? Like there's going to be tons of places where the order of properties is not specified and you could break a test just by rendering them differently. Should should that be flagged as an error in our testing suite? I don't think so because the clients won't really care. Um they shouldn't care that you you know the order of properties in in most cases. Um yeah, I I agree with you. I think I think it makes a lot of sense um to be able to have like some flexibility on that because like you said you

can over you can test only your expectations um for data. So like if you had like you said some sort of thing that relies on the order of the um JSON properties being in a particular thing you'll never catch a reorder JSON property which is still like a balanced state of the data to be in. So it feels like there's like some argument to have like uh a way of generating the particular client states that you'd want to test.

So it's like oh this should generate this and then we should get back this. Um and that's a very broad expectation that okay you should have these uncles. Yeah. So that's kind of a good segue to the the next question that I wanted to discuss is like okay how do we fill the tests? Right. So right now we fire them at GU and then we get a very specific GUP specific answer back. Um, and so is it up to the user that's writing the spec to mark up that response further? Meaning say, oh, this is

actually a wild card. For instance, here's an error situation. Yes, I want to do an exact maybe I want to do exact numeric match that the value is equal to or greater than or less than an error code. um or I want to wild card out um the message or make sure maybe the message contains a certain substring that has particular value from the input. Um the process that we have in place today doesn't really have any mechanism for that as far as I know.

Um well, how do you have your hand up? Uh yeah, sorry. Um I was just wanted to go back actually I mean it's uh to the error uh code and its importance in the spec in my opinion I think we should uh after listening I was kind of I'm I think there is flexibility of course the JSON one is obvious but for error code I think one advantage of being very specific is that uh even the test can fail and then we as a community we have visibility on where uh the client differs And so in some way by being specific we open up the conversation to everyone saying hey look we should fix that and if instead we keep it flexible we are

kind of giving up on trying to to fix it and I mean that's one way of of saying maybe it's a bit exaggerating but um I think there is benefit in actually being okay this is the code for that and also there's another thing we could look into is to have specific code ranges for other chain for that don't uh follow the like the mainet for example or um and also it's also come back to the there is another place where error code are very important is on the the wallet integration because there is also you know there is kind of there is also you know this RPC call we call them RPC call but they are actually you know wallet call like you know EIP193 and so error code will also be

useful here and I guess a range for wallet will be also interesting Thank you. I'm just notating all that. That's great input. Okay. Um, yeah. All right. Good, good, good. So, test filling. Is this a subject that anybody else has thought of? Is this something that we maybe want to put a pin in and have discussions next meeting uh after folks have had some time to thought think about it? Um I I have thought about it

and I'm kind of of the mind of well either you fill the tests from your reference implementation which is guess and that's that is what we do today and I don't know what the alternative would be right so I don't know what the ore is the ore could maybe be the executable execution specs they do not have an RPC component right now like you you kind of just interact with them with transactions and blockchains themselves and you know block imports. Um so I don't know that there really is any option other than filling them from GU.

Um, so I I I guess what I would ask for is someday we fill things from or I shouldn't say someday in the short to medium term to improve this process. I think we should continue filling things from GU but also add the flexibility that we're uh we think that we need as part of a manual process for the spec writer. So that's just a thought. I don't want to be prescriptive here. Um but I I I see that this is the direction that we need to go in.

Can you say that one more time? Yeah. Um I guess I guess what let me just rephrase and summarize that a little bit more concisely. So today we specifically depend on GU and we depend on the specific output from G meaning requests from the spec get executed against G and the response becomes the test case and exact match to that response is our test case. We have two options to proceed from from from there. One would be okay, we'll use something other than GU and we don't have

that. And the other is continue to do what we're doing, but allow for authors to more specifically curate the responses, right? Go in and edit them and have more flexibility that says, "Yes, this was the exact response that I got from GU. Um, here's the assertions that I want to put around that response. And our process doesn't have any room for that right now. Yeah. And I guess like maybe if we think about like working backwards as to like sort of like what's the overall goal of

like that? So like part of it is is like okay your data can be still on spec and even if it's not an exact match and certain things are required. So you may have like required fields and required like formats. Um, so like but the required fields and required formats just speak to um just like being able to do something that's more specific that's more flexible than exact match, but maybe even if you're going to say like a JSON schema spec for the responses, which I think there already are. So you could

then validate that schema against the response and then as long as that's there but then on the flip side there's this qualitative like version of like oh it matches the the syntactic quality of the response but the actual values may be wrong. So like you need these values to be there. Um, so yeah, that's a good So I think that's probably a broader conversation with Ethereum in general and the testing team specifically like what does the RPC compat test suite expect? And I think that might be a reasonable line to draw like maybe you don't check the values for um, you know, maybe you're not

validating on specific values. I I don't know. Maybe there's other test suites where you do that. Yeah, it's interesting because if I think about goals like if I'm a client developer and I'm writing a new like say L2 client and I want to know that like okay my client does the right thing given a certain set of data it's going to return back the right thing then I need to know that the values that I get back are like exact Exactly correct.

Um and then there's other cases where like I want to return back a super set of data that is still valid um according to the spec. So I guess maybe in my mind it's like the thing that is the most important is to just figure out like am I executing to spec and is my client behaving properly. I think that's what you're getting at. It's like proper behavior and proper syntax are two different things. So it's like uh if you call get uncle and there are definitely uncles in the um block according to like the data that's set up in the test but you're not returning back uncles but you're

returning back you're not returning back all of the uncles but you're returning back two out of three of them and the correct format then you would like pass. Um because syntactically there's nothing wrong with what you're returning back. But um I guess I want to say semantically, but that's not actually right. It's just the values are wrong. There's no fuzziness to it. You're just missing parts of the data. So you've kind of got the syntactic thing which I think is the easiest thing to validate and then you've got the value thing which is like I'm missing my client is wrong. And I think like compat should help you maybe test both controversially. I don't

know. That's that's the qu. Yes. Controversially, right? Like that's that's the thing that I'm wondering myself. It's like is it a good practice to layer your tests like this because theoretically you would actually have kind of two suites of tests running at the same time to use your example. Maybe there's an uncle's suite of tests that validates that uncles are, you know, all the different types of logic that we have around that. Every single test in there is going to rerun schema validation on it, right? If you layer them like that. Um, so I think you know what what is the the broader testing strategy with regard to layering these things? Maybe there isn't one.

Maybe it's just more tests are always better. Um, interesting. All right. Yeah. I I think just like discussing it and thinking about this problem for the first time in a while, it's like uh I feel like uh it feels like my intuition says that the syntactic testing is like so easy and so light um that you simply if you return back the spec and you're just spec then you're always validating on like you return back valid data and then

the other thing is like the other layer of that is you return back valid values or expected values and I think to your um statement earlier is how well defined are the expected values um so like if uh any of the other uh L2 clients that are out there we'll even say like Basu um returned back uh something that's slightly different in the uncles or a super set of data like does the spec like is it well defined enough to be able to say

like Gaff is returning back the right thing. I guess that's the that's the real problem. The real problem is we don't know that Gaff returns back the absolute right thing for everything and so we just use Gaff as a reference because we think that Gaff is implemented accordingly to spec but it's not like formally validated. In the past it has been formally validated or people have done formal validations of it. Um so we kind of trust Gaff as that canonical reference for this is the right thing. this is the way you should be handling uncles. But if there's a client bug in G, then everybody else has to kind of hit that. But and through

test, you would hope that Basu who ran compat and got back a different value for let's say the uncles than what Gaff returned would then be like, "Hey, look, Gaff, we think you're maybe wrong. We tried to fix this." And you hope that like GE being the reference doesn't drive other clients to implement the same bugs. Yeah. Yeah. Yeah. The more that we talk it through, I think just do JSON schema, I think, is kind of our answer in the medium term. Meaning that when we generate we write the spec, we generate requests and hopefully JSON schemas to

validate the responses and then yeah and then you just check your filler against the JSON schema but not necessarily a strict um string check that would over you know that would cover the data as well. Um, and I think that actually speeds up our testing development process as well, right? So like right now if I find a problem in a spec um, and or if I disagree with a test, I have to actually update GU.

I have to like open a PR into G and kind of, you know, interfere with like a lot of parts of the ecosystem that I really shouldn't have to um in order to to refill the test. Now if the test was just rerunning the validation against the JSON schema then I could still move forward and then raise the data issue with the guest team for them to um solve it elsewhere with regard to you know to use the uncle example again right there's probably an uncle suite somewhere else that now needs to be fixed but I can at least pass RPC compat because I'm passing the schema Um Simpson your hands up.

Um yeah I just want to check um the existing J open RPC JSON schema does the value validation too. I see lot of uh validations present in reax form for pretty much most of the fields. Okay. so, so we're we're talking about the behavioral tests of each field or responses or just about the data. I think we would like it to not cover the data for now.

Gotcha. Okay. Okay. Then okay, which is already present in open RPC uh spec we have uh which means we should remove it from there. No, I like I think we're conflating a couple different things. So I think like the specification that's in the open RPC document is just saying that the values match a particular pattern. The test and compat say the value should be 0x F3788900.

Okay. The Oh, gotcha. Okay. If you're not that, then you've done something wrong. Ah, it makes sense now. Sorry about that. No, no, no. It's good that we get everything clear because then we're sat in a good level, right? Understanding amongst us to talk about it. Yeah. No. Yeah, this is a valid point because uh I okay I understand now because I face the same issue when I want to extend the test for RPC comp the the error code mapping. Um uh yeah that's a good point to talk about. Uh the way I was thinking of solving it is by doing fast tests and uh expecting the value that the first test would expect

rather than preloading the state. Uh but yeah, I think it's much more complicated than that. Uh and like I don't think that we can really get rid of data validation because well uh because I think the client developers like need some sort of way of knowing um that their data is wrong or potentially wrong. Yeah. Um, yeah, but I don't know how like uh the state loading I guess like I don't know the process and you were saying that Justin you were saying that the

state loading happens from uh like inside the gaff client that you have to basically construct whatever block data and to the go package is is that the the process? Yeah. So when you when you run the fillers basically um you you provide a block import and when you bootstrap the filler you import everything off of the disk and now you have executed all those blocks and you have a particular state in mind and when the developers write their assertions they will have done that as well.

Interesting. Yeah, maybe there's a Oh, I was maybe there's a way to like tease all of that outside of death itself and like then it's just like, okay, I have a filler for this thing. But at the same time, you kind of need the coupling between the version of GE and the responses that come up. Yeah. So, like you kind of have to Yeah. This is why this is why I've been kind of ambivalent about is this a bug or a feature, right? Like I think it's kind of a feature because you have like you said you have to um you need a reference implementation.

Yeah. Um there's just no other way around it. I think probably um for some of the other things it's just more of an application of the of the spec uh schema to the outputs um for schema validation but you also are going to need the data validation. So it shouldn't just be strict match. It should be like pass a schema validation and then you probably have to write some additional logic to validate the inputs of the data like because they're going to be just in different orders and things like that. Uh probably the cheapest thing to do is to just key

value pairs sort keys that comes to mind. So that way like yeah you can't alphabetical order is alphabetical order like okay you have to read it it's JSON it's not that big um it's not like millions of lines it's like at most a thousand uh key entry bears um so I think that's like pretty I think that would probably bring the flexibility to where clients respond all kinds of different ways you get the JSON on schema validation and you get the value uh validation. And then probably my second or third recommendation would be like to think about generative test in

the sense of like testing scenarios. So the process that you do to create the like say the uncles um open that up so other people can create uncles get back results from G and then like kind of have a way of loading in their own fillers to be able to like have it be not specifically tied to. So you do the thing that works specifically and then and a more stringent test would be to do the fuzzier thing which is like here's a thing that generated some uncles.

This is the expected result that there'll be two uncles and then you should get two uncles back. What those uncles are I don't know. It's like the process to generate the test data but you can do it on your own um kind of a thing. Okay. All right. I want to put a pin in this. We're we got 10 minutes left and we still have a couple PRs I want to give folks time for. Um, but this is a rich vein of discussion. So, feel free to continue it on the Discord anywhere you like asynchronously and I'll make sure that we continue talking about it on the next uh meeting agenda.

Uh, next up, Wua. Am I pronouncing that correctly? You had a PR for adding timestamps to the receipt schema. Yeah, exactly. Yeah, my the the nickname is wigawag. Uh wigawag. Got it. Uh yeah, that's yeah. Um yeah, that's exactly that. Yeah, it's a it's a PR like to add um the log the time to logs and other other related uh RPC methods as well. Um I think I cover them all because of the way the schema structure. So I think um the PR cover all the case but yeah the main interest was driven from the need

for the logs in particular. Okay. Um I don't see any problems with this off the top of my head but I'm not a maintainer. Um so I will ping the maintainers uh to remind them that this is out there and um that they should provide any input on on the PR itself. Perfect. Cool. And then um yeah, I think Simpson has a big PR to discuss with the um JSON RPC error codes.

Yes, thank you. Um uh is it okay if I share my screen? Yeah, please do. Thank you. Right, I'll just share the whole screen. Uh, oh I have to I have to quit and come back. Oh, you can see it. Okay, I can see you. Oh, great. Uh, all right. Cool. Um, let me start with a initial proposal I wrote a long long ago. um wanted to write this as an EIP and then got to know that this has to go into execution API repo. So we kind of modified but the gist is all the same.

Um currently we don't have uh a standardized error code as everyone knows and every client every chain handles this in their own way uh which results to catastrophic reusing of same error codes for multiple different errors or multiple different scenarios. Um so you cannot use any of the existing error codes. The the the field just occupies and it's of no use. No one can be using it if they're working with multiple clients or chains in short. And uh I've done study again the study was like done long back across multiple different clients and stuff. You could see the same uh error code across multiple

different um uh different scenarios and uh different values across different clients. uh overlapping and reusing the same error codes such as um now 32,000 or 32,62 um uh same thing happened all over uh there was no way I could find out an o overarching uh unique set of error codes um hence this whole proposal um uh that was that was the first thing and I started looking into is there is there an actual way I can rely on these these error codes because the error matching of string like you mentioned is really errorprone because every time the client

goes through an upgrade they change the space or they change a dot and it entirely breaks our systems and uh we cannot rely on them. We have to go and modify find out what was breaking and then modify the uh rejects to actually match to the new error message. error messages are are string or paragraphs and it actually doesn't make sense to uh you know rely on them to have an um stable um environment uh for anyone to rely on. So the proposal is we have um we have a provision to use the our uh error codes that we we are not using um already. Why not just use that? Um so

that is that is all what we are talking about and I've noticed so many people in so many different communities have actually recommended the same thing. It's just no one has started it yet. Uh even though this was very apparent. So I'm not doing any magic here. just uh implementing what people are actually recommending it just going ahead going ahead and do the work. Um the the way we are proposing may be different. We can we can come to an agreement once we discuss this or once we get a feedback. Maybe this is not the way we want to implement actually and uh send it out.

But this is what I thought was best based on common scenarios that everyone would interact on a day-to-day basis. And then we can of course cover ext um overarching or other than what's mentioned here what people would do uh that I'm not aware of. Um the way I initially did is we have these two uh if you open up the JSON RPC spec um here they've uh they've given provision for others to use. They've uh reserved these error codes. Rest of their codes are open for you to use. So these are the existing standards and uh we can see the existing standard already defined and uh this is also existing uh for implementation specific. Uh so we leave

these two ranges and use rest um any any of the rest. Uh here we've decided to stick to this range uh which gives you like 20,000 error codes to be occupied uh for EVM purposes. We want to if we can extend we can extend shorten it and um and the next thing we're trying to do is grouping. Grouping makes it really easy for users to understand unlike so there's a problem uh with HTTP error codes. It's obvious to know 400 range tells you something and 500 range tells you something. Certain error codes are um you can resend the request for certain error codes you cannot resend

the request. It's not easy to do that with um uh uh blockchain clients because uh one error could mean one thing for a specific client but it doesn't mean the same thing. You cannot resend the same uh request as it is uh to the to a different client. So the better way to organize this is just by grouping um well-known uh concepts across different uh execution client which would be the the the classification I mentioned is just from the top of my mind from looking at different things uh which can be is not is not set in stone. uh gas errors which everyone relies on like insufficient fees um you know gas not uh in a for out

of gas ran out of gas all that uh same way like transaction pool the the transaction already in me pool already known transaction um uh things like these so that essentially that's all uh we allocate uh 200 error codes to a group and uh leave the rest for rest of the future future implementation or future um where clients can claim these uh ranges or like implement specific error code into any of these categories and uh just add it to the spec. Uh so if you add it to the spec uh you do 810 uh for your air code you you have flexibility to add it in the future. Um

we can extend the these ranges more uh but just for now to to come up with a point or like to paint the picture um we kept it to 100 for now. Um uh and I've gone through multiple clients multiple examples of what error they return and what could be the best error code for that. Uh so all the examples are linked here or like the code the link to the code where it was actually there when they did the investigation. Um but yeah and so this is grouping and how we want to do the structure of the error message or response is uh three fields code message which is already done uh by uh

most of the clients we want to add one more field um this is backwards compatible so it's not mandatory for you to add or anyone to add this is only to provide more context to the user where if you want to return an whole error stack for a user to understand more. So what would that would allow us is you can standardize the message also for the known well-known error codes. For example, uh if I scroll back let's say insufficient funds every different client returns this in a multiple different way um in all different combination. This allows us to actually also standardize the message um the the standard message. This doesn't have to be this way. We can do like short codes,

error message codes, uh not a numerical but an alpha value. Um and can standardize that too. Uh it's again it's not implemented now just it opens up lot of possibilities for us. For now we'll focus on the error codes. Uh but we can also do the error messages. So it allows you to add more extra data into the data field. Uh that can be even a a strct or or an interface. you can pass in whole different um uh information through data field rather than just restricting yourself to string. Um so that's that's the gist of the proposal. Um uh I will move on to how we plan to

implement it. uh initially the RPC open open RPC specification did not support multiple error codes or or or an array of error codes or grouping of error codes. So that's where Shane came in. Uh Zayn came in sorry uh we worked with Zayn and then um luckily we were on time so Zayn had the idea of extension specs. Uh you guys should check it out. It's it's amazing. uh the extension specs what it does is it allows us to define a custom uh specification implementation for any purposes. So uh happy to say that error codes was the first official extension spec that open

RPC uh wrote and adopted um which we can uh directly refer from open RPC's um repos and standards. Uh now what that allows us is actually group errors and specify more than one error which was not possible before. Before when you had an example I can take up an example where you can see you'll have one error message or one error code uh returned for a sample uh me method uh ethereum method. Um now we can we can add multiple this again allows us actually not to redeclare everything and complicate the spec. Uh so the spec is still readable and you

can do references, you can do inline, you can uh use the same error group across multiple different uh methods. So which is what we've done here. So you've see um submit.yamel which is a e_submit transaction has these error quotes and uh the same is reflected in um I don't know the second one but um yeah please go ahead. Well, we're just at time, Simpson, so unfortunately uh Okay, got um maybe I'll take a one minute and then uh summarize what I'm what's happening here. Yeah, I mean I don't mind actually picking this up because this extension is very interesting and I think I guess it's just you and me on the call and Zayn um he's probably familiar with Okay, cool.

Cool. Okay, just not that. All right. Anyway, um we have Let's pick Let's put this on the agenda also for next next meeting as well, but continue. Sounds Sounds good. Sounds good. Perfect. Yeah, I can explain again uh next meeting. Uh yeah, uh to summarize, we can now define multiple error codes uh and we can see that in open RPC spec.json uh we can see uh multiple error codes reflected for a particular method. Uh without having to redeclare everything uh that's one and uh we can even implement the um in spec check we also implemented the validation of these error codes. So a get invalid number or get storage invalid key if the

error code doesn't match with what we have defined in the spec. Currently for the flexibility we are returning warn um we can extend the validation to include the error message in the future if you want to but currently it's not done again. Um uh so it is it is possible to validate all the returned error codes for now. So I'll I'll stop right there. Okay. Now that's interesting. it actually gives us more options for solving our problem where maybe we do want a standardized message but we leave the data field um completely unchecked. You know that's another another option that's interesting. Okay, cool. All right, thanks everyone. Thanks for hanging around after we went over apologize for that. And um I have a bunch of uh notes.

I'll post the agenda for two weeks from now in the next few days and see you on the Discord. Well, awesome. Thanks. Thank you very much. Thanks, Dan. Byebye. Thanks, Samson.