RPC Standards #13

Transcript

Loading developers...

[Music] Okay.

Heat. Heat. Heat. [Applause]

Meeting Introduction and Agenda Overview

Good afternoon. >> Good afternoon. So, okay. Um, welcome to ROPC call 13. Today's being 29th September 2025. Um so I don't have we only have two things on the agenda but if you want to um if you have anything any other thing apart from what's on the agenda to talk about feel free to also indicate but uh and that will be actually feedback on the um um error codes from my end I don't have any feedback because I feel like it's good to go but we still need to share it with the with other calls to take a look at it and but I don't If someone has any other thing in

respect to the error codes that was posted this week, last week rather. >> Yeah. Um, hey everyone. Um, yeah, just to reiterate, um, I think the doc or the readme file I wrote should be pretty self-explanatory and should give you an idea to review. Uh, I'd really appreciate if you guys take a look at it. And uh Mercy, if you have any contacts uh with different clients and if you can help them forward it and get some feedback, I'd really appreciate that. And um so we can we can talk about what's the next steps and how we can get this merged.

>> Yes. So the reason why I pointed it out was I was hoping to open it up here. Then if anyone has an opinion on what needs to be changed or what could be improved, then we'll talk about it here. Then we'll make the changes. Then we'll bring it out. Um we'll present it to the core developers to take a look at it. I don't know if this makes sense. >> Oh yeah, definitely sounds good. Um yeah, I'll give it a couple of days uh for anyone to comment. Um, and I can I can post this on the code developers channel. Uh, if that would make sense after a couple of days.

>> Yeah, I think that would make sense. Just from like an outside like operational perspective, it seems like it might be good to do the presentation for everyone uh at the core dev call, but it also seems like it would be probably useful because I think the core dev like time that you have to discuss is so small and narrow, >> right? >> Just be able to meet with different client teams. So, if maybe Carrie or Mercy could make an introduction to uh someone that's working on Aragon or Nethermind or any of the or Basu even if we could just take some time to talk

with them to just see like, hey, does this track that might be like useful in the interim before uh the all hands so that way like people have a lot more time to like look at it, get feedback, etc. because I feel like otherwise we're going to be in like little five to 10 minute chunks that people like see it for like five minutes on that one hour but then not again for a while. Um and it's the kind of thing where like I think a lot of people might have just like a lot of weird private stuff going on. Um yeah, not weird private stuff, but I mean like uh error codes and responses that are unexpected.

Um yeah >> yeah so that's actually what I was thinking but I wanted to like for us to discuss this in house in case of we have any changes so that we kind of like start changing it at hand then we'll take it to the JSON ROPC discord we tag some tag um some call developers there then if it is looking promising like if there's improvement or give us a thumbs up on then taking it over to each client teams and then maybe officially bringing it bringing it up again to the ACDiction um layer call ACDE.

Discussion on RPC Compatibility and Error Codes

uh but I know that it won't they won't give us much time but at least once we have like a reasonable feedback from each core de from each client teams that is involved we kind of like bring it more to a more um official ground and then even if it's 5 minutes they're going to take a look at it they will know that okay this is happening I don't know if that makes sense but I just wanted us to like talk about it what do we think do we have anything any changes we want to incorporate do have any idea improvement or something we need to improve on so that it will be let's do the hard work so that it will be easier for the core developers to just it won't take um a total change that will like take on a whole lot of

time. Let's just do the heavy heavy lifting so that when they look at it they'll be like oh this is good then give us a thumbs up then we can go ahead. Does this make sense? >> Yeah absolutely. Um, yeah, we can. Sorry. Go ahead, Gary. >> Oh, no. I was just going to say I think that makes sense. I can take a look. I haven't had a chance to look at it. Um, but I can do that today or tomorrow. >> And then >> Yeah, >> sounds good. >> So, um, about the RPC compact, do we I don't know. I was trying to look into it but I'm not sure how to properly um

contribute based on that. Is there like something we need to know for people that want to contribute because I think Cena did ask a question about it on the discord also here I think you're the best person to um for RPC compat I got a PR merged uh last week or actually this this morning but I put in a PR um to look for a spec it was already existing and execution ution APIs. Um, and now the RPC compat simul simulator respects that. So it's only so like for estimate gas, we don't expect clients to have the same like

return the same values for the estimation of the gas and so we only look at the keys and so um there's a couple tests passing in Hive and then we probably need to add a few uh spec only flags on the execution API side. Um do you have specific questions? Does that answer your question or do you have other specific questions around the RPC compat? >> Yeah. Um so I did look at the simulate and then but I wanted to know if there's if there there is there a way to improve the failing at least to get a reasonable number of passes in the test.

>> Yeah, I'm still looking at that there. um standardizing the error codes will help a lot. There's a lot of um error code failures. Um and then like some of the stuff is just things that clients haven't gotten to like the block timestamp was just added not too long ago for each like get logs. Um and GE has it but no one else does um sort of thing. And then the simulate v1 is the other kind of big one that everyone is failing except GA. Um, and I think that's a I think it's sort of a lack of consensus across clients. Um, but yeah, I think those are kind of the

big ones that we need to address. >> Okay. Thank you. Hello, Luka. Um, I don't know. I think we have a client thing here. So, I'll just I'll drop the link to the error codes um file if you can get anybody from nether mind to take a look at it and maybe give us a feedback on this. This is what we've been working on. Good afternoon. I don't know if you can hear me.

>> Yes, I can hear you. I will take a look. Are you familiar with the error codes like um art that we've been jamming on? >> Uh with error codes what? Sorry, I didn't get that. >> Um so we've been working on uh grouping the error codes. Um so there's a way within the spec to be able to specify like what is a valid error code range. And so what we're trying to do is reserve uh ranges of error codes for the spec or execution APIs to be able to officially use. So as a client, if you

Error Code Standardization Proposal

had some error code that was like beyond like that, you could safely use like this range for returning back custom error code. >> Okay. Um >> so we're trying to standardize the errors. Maybe Sims if you wanted to step really quickly that could be. >> Yeah. No, uh he pretty much summarized it. Uh so the goal is uh for the cross clients um to return um a dependable error code um that that the clients or D apps or anyone can rely on rather than looking at the string of what the error is.

Sometimes even that's really vague, right? So we wanted to standardize usage of error codes. Currently it's pretty much non-existent. For that the proposal um you know is looking to reserve some error codes per category. We've split it into categories. We can add more category. We can remove it, modify it based on the feedback. But the the goal is to um you know uh reserve some error codes per category and also predefine uh the numbers to certain errors. For example, let's say nons too low should always return uh say 001 um something like that. Um which means uh any you can

return any any error string but the error code will still be similar just like in web two world. uh people can reliably start using these error codes slowly and you know will be a better crosschain crossclient experience for everyone. So that's the goal of the proposal and uh really would appreciate if you can take a look at it provide any sort of feedback. Got it. Um yeah makes sense. So maybe feedback from my side as a person who for example sometimes uh fixed some things that we were doing different on G.

Um that's sometimes it the hard thing is not maybe that there is an error code of of certain um value but the problem is that when this error code should be used and things like uh nons to n to high or ns too low is fairly maybe h maybe it's not even self-explanatory right uh and Sometimes there is also like uh an order of validations right and this order of validations can also be different per client or thing. So in similar situations you can get different error

code. Uh right. And sometime sometimes even like um yeah some some things uh end up in the same buckets in in one client which you get the same error code but different buck buckets in other clients when you can get different error error codes and those those things are harder and not just the existence of error codes but where like exact exactly specified which error codes should be returned where or um which error codes potent maybe less important but what um order of the error codes should be validated right things like that are also problematic between the clients sometimes

>> no very true and uh great point too actually uh last week when I was modifying few stuff I also noticed that um the nonsto can be returned directly from meool for certain clients certain clients do that at the consensus level especially let's say some L2s Um few chains do that too. Um it's a great point but uh with this provision we can actually add nons too low in both categories. Let's say you can add at um mempool level. Uh you can say 001 nons too low is mempool level um non too low and we can also go and add it into consensus level because we still have

flexibility. We haven't used the ent ranges. If you want to go back and add it to the ranges, we can also extend the range. Uh we can keep adding it. So now the users will actually know exactly where this non stool is happening. If it's happening at the consensus level or if it's happening at the mele level. So even they can react to these different sort of um uh hierarchy of validations on the client side. So we we still have provisions for that. But we haven't defined these overlapping error codes yet in the example or u or the proposal we have raised right now. But we can definitely add it without causing any confusions.

That's that's why we have grouping uh error grouping. We have like uh mempool uh we have execution cl errors. We have consensus errors. We have network errors. We can again also add more grouping or reduce reduce grouping or split grouping based on how we want. But the overall general idea applies to pretty much every single client because they have a me pool, they have a consensus, they have a execution layer. So that's how we are basing these classifications on. So we can still add these overlapping errors into different categories >> if that made sense.

>> Yeah, got it. Got it. Um maybe it would benefit from a more explicit um spec when when this should be thrown right so for example what is uh non too low for transaction pool right probably based on chain head etc right if if the for example I would say like proper spec would be uh that the states um that the nons for the address of uh sender of the transaction, right? Um that is already in the state based on the current block um current uh

fork choice updated head, right? Message from the fortress update um head uh nons is smaller than uh right smaller than provider, right? So >> yeah, >> a bit more verbose what exactly does it mean? Okay, for nontolo it's >> pretty obvious but there are especially in ETH call let's say uh scenarios um there can be really custom not custom but really more complex uh scenarios where this verbosity would be uh nice to have.

Oh yeah, the that's a really valid feedback. Would really also appreciate if you can point me to some uh this is me coming from directly using let's say a client perspective rather than a protocol perspective. Um working with multiple chains. So we I I went ahead and tested lot of different chains checking what is the value they return back to the client or the users in the JSON RPC. Um uh and that pretty much aligned with what what the spec I have written right now. But definitely we can add uh any of these overlapping messages too. And um more to say that we don't want to uh you know restrict users on returning any sort of uh string based

error messages. Uh that is up to the user or clients to define um whoever is going to adopt the spec. uh but we'll just hold the number. So we will know if we get anything between let's say 001 to 0010 it's going to be gas errors which means we can sort of manipulate the gas and yeah >> especially on things like reverts etc users are relying on messages >> yeah we have execution error specifically defined class category which means it is coming directly from execution clients okay >> uh which is sort of telling the users hey this is coming from execution ution layer uh you cannot have automated logic on top go and check the error messages

Error Handling and Automation: Discusses automated vs manual error handling

and act manually but if it's a gas based error which if I get uh I'll by default I can you know try and bump the gas or try and u you know bump the nons try and bump the gas limit to you know make sure the val uh the transaction go through which can be an automated process rather than uh it's a retriable uh logic rather than always failing logic. So that's how I'm trying to classify and also give more room for both clients and users to initially see how the specs uh spread out um rather than being too restrictive and too instructive to the clients. Hey, you have to use this sort of error message for this error code. Um and you

know um just just follow the spec uh to the t. Uh so the code right now is like let's see if I do nons error and if it's going to be 8001. If you want another nons error in execution layer if you still want to return it to the user directly without having a filter on top you can add it to the execution layer and still return it. U but you'll have for the for the users they will start looking at the spec uh they'll say hey okay I see nons too low error both in mempool as well as in execution. So I need to do validation for these two and react to these errors in a in a way that I want to. Um so it was also a little expandable in that uh in that sense.

>> Okay. I won't go into details but I can point you to one of the PRs we recently uh did that can uh for example help you with understanding some of the problems we have with aligning to Gaff, right? Um because the the problem for us is also like there was no spec. So GE is the spec >> and in order to you know and then someone complains that's okay they they get different for example error messages. Um and the only way to do it is try to uh reverse engine your gaff right how the messages and this is exactly a point when I think this kind of thing happened and it actually wasn't

Spec Alignment Challenges: Talks about aligning with Gaff and error standardization

a completely straightforward um uh thing it was also about reverse here I think a bit >> I see no this is very helpful uh I'm going to actually look into this and see if I can incorporate uh this into the example >> that because we went from some two-state uh two-state uh results that we're returning something deeply from EVM to free state results let's say uh and depending on that we had to uh adjust the error but I think this is more mostly for ETH get call >> if I'm correct uh there's also a issue for that Uh yeah. So those are the most

hard things to to to get aligned on because like Yeah, sure. nonsto which is a static check that you do before even going to EVM is relatively easy to standardize. >> No. Yeah, definitely agree. Um yeah, we can discuss this uh offline too. Uh this is really helpful. Uh I'll take a look at the PR and see if I can also use that in the uh or previous serve for your use case. But um the main goal here is uh whatever error being returned to the users or D apps or client uh on a on a JSON RPC level >> um should be categorized and classified

so people can start relying on error uh codes rather than messages rejects and stuff. Uh but yeah, definitely we'll take a look at this. Uh thank you so much. >> I think like this is somewhat already done in the clients. Uh like the easier errors are somewhat standardized. U again probably the devil is in the details and like if it's 80% standardized and 20% not, it's still um problematic. M yeah but that's my at least on never mind uh feeling that this this is mostly especially the the simple errors the static let's say the static errors

>> which are you know right there on the surface that you can validate and on on the surface level without going deeper into uh into the um the calls that you have some that you have propagated back from something somewhere deeper >> right >> uh in the architecture picture uh those are relatively easy and mostly done but again I'm haven't looked into ref or argon or bezel that deeply so maybe that's only but I I expect they have similar experience >> do you have any thoughts on um uh being able to like list out or

investigate the dynamic calls that may throw track different errors. Um, yeah, what would be >> that's a good question. Uh, probably uh the best way would be to go through through an implementation like GF and um find all the errors there and create a test for each one.

and then try them try those tests on different clients and see what happens right and that would show you and then uh don't already assume that maybe G is super correct and others are not if you have this discrepancy uh try investigate a bit why this discrepancy where where does it come from and which way you should on the rice, right? Let's say that's that's how I would approach it >> if I had to do it.

>> Mhm. >> Okay. I have something to say. Um I don't think like wouldn't it be better if we don't always rely on get to validate? >> Can we do something about that? Because get can't be right every time. >> Yeah. So uh there are two things right we need to define the spec because it's not defined as a spec right so that that that's should be the goal in my opinion to define the spec and now um g is a good starting point because um g is the spec to some extent because there is no spec and g was uh the main client for so long that it kind of became the spec so that's but so that's why I say it's a

very good starting point but on the other hand I'm Not saying that you should blindly follow GEF if you see that discrepancy between clients but then we can investigate that scenario and figure out what the specs should be but starting with G we need to start with somewhere and so the that's why I said and you I don't expect people to dive into multiple code bases. So diving into one codebase and generating test based on that one code base is a starting point. >> Um yeah just a small point I when I was writing the spec uh I think like an year

ago uh that's exactly what I did. I I attached the um um Excel sheet but these are very basic tests that I I did. uh I think I extended it at a later point but I don't have the stored results for that I was not able to find it but this is basic ones I did really long back uh but you can see it is testing baso get coraly even chains like zk sync and few other chains um uh it's it's very inconsistent across uh at least when I started maybe there was some sort of standardization uh but it's not written anywhere for rest of the client or chains to follow unless you forget or like you work

really close closely with get. The goal now is at least let's write it down so some you know everyone has some place where they can look this up and follow it up rather than diving into one code base like you mentioned get >> uh okay that's a good data point let's say but uh how should I read it uh is there a good way okay but for example just just to looking you you were doing get balance with the latest parameter Right.

>> Right. >> Uh if those are in different points of time, you will get different different uh uh responses, right? Because the balance of this address could change, >> right? So these are trying to simulate um uh uh failure cases mostly uh which means like if I'm getting an error uh what is the error code? I'm all I'm focusing is on error code like >> but again this is too old. I can try and redo this test with a more expansive use cases, but with the basic ones at least like even the standard ones, we can actually see how different clients written completely different error messages or error code or reuse error

Error Code Standardization Challenges

code that you you can see minus 32602 for get balance also for like get code um um even for incorrect method name and stuff. So it is it is nonreliable uh even forget we cannot say this one error code means something >> this error code means uh invalid parameters or something what's what's let me double check what this is because I don't know them by heart so uh where do I have this okay what what's it as set never mind uh yeah this is invalid params. Right.

So it's a very generic error code. >> Right. Yeah. >> So if the parameters are invalid like you cannot the serialize them. Right. >> And for example there might be different different uh reasons. Right. But you generally don't don't differentiate them. You cannot serialize parameters. Yeah your request is wrong. And maybe we can put in message what Zachary is we have a problem with and that's fine in my opinion to some extent. Uh we not sure if there's point well maybe there is a point of doing more detailed but yeah I'm looking at at

your sheets the jumping through bezu argon g and they are more or less returning the same error code in in those scenarios. Um but even okay so yeah I let's do this I I'll actually do more um a little more expansive uh test cases. I know this one I tried to more you know try and simulate more on the basic error codes rather than diving deep into the execution logic. Uh I wanted to initially check how the standardized error codes that JSON RPC currently uses is being used. Um even with that it's uh um I can exactly point between which ones are colliding or overlapping but I

want to actually do also use the system and feedback and do a bit more execution based uh error codes um and try and simulate um you know um failure error cases uh that might be helpful for >> let me rephrase what I said so looking at the the the sheet you provided >> bezu argon and g more or less I'm it's hard without a proper like diff uh on that more or less return the same error codes. I don't see anything obvious when they return different error codes.

>> Uh true, but also um the same error codes for different methods. Uh >> yeah. Yeah. But if Okay. But if a error code is invalid parameter, it's regardless of a method, right? If you cannot the serialize parameters for a method that's a generic generic error codes that can be used on from different methods. >> True parameters >> and this is the most one that you that you have in >> there. Yeah, that's the most one I'm I'm actually trying to look for because it's been long. Uh I'm trying to remember which one. >> For example, if you get if you take a eat estimate gas uh on let's say basu >> and it's returning minus 32,000 saying execution reverted. Uh it doesn't say

why it was reverted. I actually don't know ex uh what was the simulated simulation >> log. Okay. Okay. Okay. And that's that that's the what I was saying about the complex error codes because this goes and spin ups the VM. VM uh VM does uh its thing and then it reverts right uh uh in DVM and there might might be multiple things why thing is reverted. It might be a revert op code directly from the contract and this revert op code might have some data attached or not uh or it might be out of gas probably is might result in the same thing or it might be something else. So

um now it gets complex and this is completely unspecified >> right no true I I agree yeah that's why I want to do more execution based uh test but if you look at the same error code in ZKVM you would see that for even >> um wrong uh parameter uh for for example if you take invalid block parameter format >> uh line 20 it's using the same error code for non-executionbased >> okay okay got it But that's the key I'm thinking. Okay. I you you are going beyond Ethereum clients. Okay. I don't have I don't have an idea about beyond Ethereum clients. So yeah, that's that's where I agree with you. Sure.

>> Right. So this is going to like this is sort of like a guide for everyone any client any chain >> uh to be like hey we have a standard that exists. Please try and follow the standard. Even we are in a position where we can work with like really nent chains uh EVM chains and say hey please start follow the standard so all the D apps can you know uh by default work with you without doing any modifications. >> Got it. I I do agree especially if you like start uh adding like uh niche implementations right uh to to the mix this this this may make sense. uh what I was saying was mostly more more from perspective of

Promoting Standardization Across EVM Chains

established uh Ethereum clients like the big five let's say >> makes sense yeah no definitely I agree I'll also try and do more tests and see if I can find any inconsistencies between even the big five um um but yeah so the point was >> I find some but I I would say it's it's not as bad as you might think No, I agree. But the goal is for cross EVM chains like EVM um all EVM chains or EVM client should be standardized. How we expect the whole JSON method standardization? We're expecting pairs as well.

>> But where those other EVM clients come from? Most of them are forks of of GF. Uh they might be they might be stale forks of GF. So they are not updated right and that that might be one of the problems uh while for example maybe G standardized something or fix something and they don't have that fix or >> not true about zitk VMs uh that's a good question but zitk VMs now uh most of them would also run a customly compiled uh EVM uh implementation That would also come

from big five and maybe EVM1 or Eter which is also like a newer client right but I think they mostly run compiled ref at the moment I know because we are trying to compile never mind to to this format uh at the moment we have a big initiative around that uh and hopefully we'll uh also join soon um GF is also being compiled I think to 64bit uh riskv uh so those those imple those those implementations that are running compiled uh let's say Ethereum client code will inherit the Ethereum client properties in this regard I think I'm not sure if

they will >> yeah okay maybe maybe they need a bit of additional code additional instrumentation there >> yeah okay that's a question mark then on my side but they could they could potentially inherit that to some extent. >> Yeah. No, sometimes I've noticed uh some of these chains right uh run just an RPC layer on top um just to do certain sequencer based validations or add few more functionality and uh they sort of return completely different error messages and codes just because they're running like a RPC uh wrap layer on top of ex any existing clients like get or

RPC Layer and Error Standardization

any other fork. So uh the goal is for them to also say either use already standardized follow the spec because spec also follows the big five clients that's that's why we are working with the Ethereum Foundation to make sure you know this is set as a standard so everyone can follow and um just you it's >> and what for example if you have two two problems like gas price too low and nons nons too low um do you want to define that in this scenario So you you have to return one over the other or like a priority like I said the order of of validations or whatever you want at this point

>> you know that's up to the clients uh at the end of the day whatever the clients um I mean we're not trying to change the logic of validation just the the value that they're returning uh just add proper number your existing validation will remain >> you be very precise in your tests if you write test after that if you provide And in my opinion with a spec there should be a test set provided to to when you're doing the test that only this one thing has to be wrong in the request. >> Right. Yeah. Yeah. Because if there will be more than one because if there will be more than one uh then you can get discrepancy between >> uh between the results and it will only span confusion

and people will just say that those tests are garbage because for example they return the thing in g order and never mind has a bit different order and now the tests fail. Right. >> Right. Right. >> And it will be just frustration. No, completely agree because uh we've been talking about this a bit too because um the the tests negative especially the negative test case is not going to be straightforward and um uh it's going to cause a lot of confusion. So >> um depends which ones the simple ones are not that not that bad. Go get a proper working case and just change one thing. Right.

>> And you you can get something relatively easily. uh targeted, right? Let's say uh the more complex one that involve execution. Yeah, those are a lot harder to craft. >> Yeah, exe execution ones and consensus ones are really hard to achieve. Uh definitely. Um yeah, we haven't gone to that stage yet. Writing negative test cases. Uh hopefully with the test I'm going to do across clients may come as a base for the future. But right now goal is like non-restrictive spec documentation out there. So people start looking at it and start using it and then uh we'll have the test uh to make sure that they uh slowly start

Testing and Spec Documentation Challenges

being comp compliant to these specs. It's not a spec like that's why we didn't write it as an EIP. It's more like a suggestion and guide for now. Um we are not making it restrictive that you should return this code again because it's almost impossible to make sure like you said the order of validation and making sure um we cover all the use cases all the scenarios of errors um for any client. So for now the goal is keep it simple at least the one major ones the client the D apps or wallets uses and rely um on those errors to do some reactive logic. Uh we just focusing on that at least for now. So at least

that part will be seamless and making it easy and then move on to complicated slowly. Uh that's why the spec is expandable for the future. Okay. Uh but I'll work on the test. Uh that's definitely a good feedback. Uh really appreciate that. It's also going to give me some points um to modify the spec if you need to. But I'll work on the spec uh the test. Mhm.

Okay. Yeah, it looks so that looking at this current spec, it is okay, but it's very very minimal at the moment. >> Right. Right. No, very true. Yeah, we'll be keeping it very minimal intentionally like just the ones that is being used by the the apps or clients. >> But yeah, we can we can discuss more we can cover more tests or more error codes. good to in the general one just one thing it might be good to expand a bit what is parcel invalid request invalid params uh how >> oh those are standardized we so those are standardized already yeah yeah

>> we can we can do that too right they are standardized by okay JSON RPC spec okay got it >> right right yeah we are not touching that range >> okay cool got it and that's fine I didn't even know that player standardized there. >> Yeah, they have like two implementation standard and just spec standard. Okay, got it. Um then that's fine. Um yeah, but I like like I said for Ethereum clients, this is not really that useful what you have there for the main ones, right? because I think almost

everything should be like that already. >> Yeah. U there might be an exception here or two, but you won't find it until you write the tests, >> And run it on everything. >> Right. So I mean I was initially thinking of changing the error codes to be in like an order within the range for now. Um there is no particular range defining these um categories, right? um like gas errors are not belong is not belonging to let's say 32,000 to 32,200 >> but you want to change the existing error codes >> right yes >> oh man >> uh I think that's already

you know like you would have to change both the Ethereum clients and then all the users of those server codes, >> right? I mean, currently they no one uses their codes as far as I know because it's not it's not reliably >> that's a very bold statement. >> I I I'm I'm working I just a bit of a context. I'm from Chainlink Labs. Uh we work with so many EVM chains, right? And >> uh at least personally I have worked with like 50 60 EVM chains. uh and for 95% to 98% of the chains we don't use error codes at all. We rely on um string reject mapping internally uh to react to

these errors because a mainly because um even the RPC clients just like an RPC provider have their own wrapper um return completely different error code for a different >> for for any error message. So we don't use it. And as far as I >> core devs did it core devs did it properly and then RPC providers and users it up. >> Right? Even for core devs but there is no definition written down anywhere right uh no spec or document saying hey if this is their code which means this is going to be the behavior. And that's what we want to achieve at least like um giving a pointer. Yeah.

>> Got it. So you say that if we remap the URO that's work would be mostly on the on on us on the core developers and potentially like RPC providers. But uh the thing with remapping is that um there will be a lot of inconsistencies like in between flights people running different versions and that would cause even more chaos to some extent. >> No I yeah um definitely agree. Um I'll also think about it how we can sort of make sure there's not break again right uh at least for initial couple of versions this is not

Error Code Standardization Challenges

>> there are so many numbers there are so many numbers that you can say up to this point those are legacy error codes and they were defined before and now we are defining new error codes in this in this >> rightange >> legacy >> legacy yeah >> so like yeah we could try and do it in a way that it's like uh it just keeps it like the old values as exceptionals and then >> yeah that's what I meant more >> yeah yeah and then >> yeah we can do that >> there we should say from this time forward on we are no longer doing that >> yeah that might actually be best because I'm thinking about um like if a uh

producer or consumer is aware of something happening, then they're probably there's always someone that's relying on it that like in a weird way that you wouldn't know. >> Exactly. >> Yeah. >> I'm thinking can you have two error codes for the same code? One in legacy, one in not, but not really. That's wouldn't work out well. And uh initially we're not going to force uh clients or anyone to you know uh fail the validations of let's say high validations or RPC test gen uh at least for a couple of couple of versions it'll be a guide uh saying hey we're not

expecting this error code for this range um so try and change it and then slowly start uh you know at least for the basic ones start moving to um stricter their implementations. >> Mhm. Like I said, implementing those basic error codes is very simple. Uh >> yeah, sometimes when those are the those deeper that come from when you get to v virtual machine execution and then you need to map that to error code that's that where most of the problems come in.

similarly and you do that in a lot of places because you do that in simple ETH G call or gas uh estimate but you also do it in for example >> uh said transaction goes to transaction post you don't execute it directly >> but yeah so there are different cases of that that might also differ now there's ETH simulate which is uh big piece of its own uh complicated. I think we we did pretty well define error codes there for the ETF simulation part but simulation also involves running virtual machine and

again th those error codes bubble can bubble up from there in some regards maybe not I don't remember maybe they are they would be covered there okay I don't remember detail yes there are so many details that uh I I it's hard to grasp everything. Yeah. Okay. That's my feedback, I think. >> Cool. No, really appreciate. Um I I I have some stuff that I need to do on my end. Uh but yeah, at least the goal is let's do basic simpler codes, make everyone's life a little bit easier and

slowly move on to see how we can expand this. And that's intentionally left out the the reserved range. We still have the ranges that you can use. Uh people can still rely on them but then slowly move towards using this as a base or a guide and we all of course is going to contribute and set the actual number or value and we can actually keep adding it. Let's say Basu has a special use case and only Basu returns in the future. We can add it to the predeserved ranges. Um, of course it's going to be a version bump. Um, people can start relying on it. If not, send a completely newer message. But at least the ones that everyone is going to rely on across different clients is uh at least we need

to standardize that because it's it's again like I mentioned doing 60 plus EVM chains as an org. We've done more than 100 chains but we haven't used this ever in any of the use cases or scenarios. that that's not what I would expect. >> So yeah, that's that's exactly what I'm trying to fix >> in my opinion when people not using them is why they are not being respected because like I said uh and I and I disagree that people are not using them because we did have some um tickets to to align our error codes with GF. So, so there are definitely some people

using it. Uh, and I think that the biggest biggest challenge for you would be getting your board RPC providers and making them compliant. >> Yeah. Yeah. It's going to be a little difficult. Yeah. >> Making client devs at like say like I said big five is trivial. Uh we we would love to have it uh we would love to have test so it will show us where we are not Uh but uh RPC if they have their own rappers and the rappers do whatever they

RPC Provider Compliance and Testing

want then uh yeah that's on them and they need to fix that by themselves. So >> yeah. Yeah. No definitely this is a long goal. Um like implementing a standard is never easy. Uh but at least we have good communication with most of these RPC party providers >> um and personal relationships with chains uh where we can uh you know say hey now uh Ethereum Foundation has a standard uh and we work based on this standard. So we sort of come in like a middle man and saying please work with the standard so it's easy for everyone >> and I think you need those test suits

because if you just say them oh this is the split please please comply and they would say yeah whatever and if you say oh uh this is the uh test suit that e every client if you run them locally every major client complies with and you just don't and we can run it on your endpoint and see you don't uh then that may you know budge them a bit and it's and for this code >> for the simpler error code I think it's not that much of uh work on their side to to be >> right right yeah the end goal is um implementing this in a hive test and

incorporating this in the fortnight test that runs I think um I'm not fully sure but Yeah, the end goal is get this included. >> What I also mean you you need to like we have a page for hive test you need to target the uh alchemy infura etc. and uh as the test there to some extent um okay it might be hard because some are state some of those will be state based but some are not. So at least with that with the stateless test uh that's like you send a transaction with invalid nons uh that's a stateless test right if you >> if you have

small amount of gas on on you have a private key right whatever you can probably do that right >> uh so you can send a valid signed transaction >> and this is like doesn't cost much >> uh yeah so for the for the basic things uh you should also like, you know, put them on the pedestal. Yeah. You're you're every you know, you're you're the problem here, right? And fix it. >> That's what I mean. Like uh you you need a bit of a stick to to agreed. Uh yeah, definitely. Um we'll start working on the test. Um I was just trying to gather uh more feedback on the proposal so I don't have to rewrite the

Discussion on Proposal Feedback and Testing Steps

test but test is definitely the next step to this. >> Yeah I'm fine with proposal I find it basic uh like from my perspective never mind that I expect it's mostly compliant with it already. >> Cool. Awesome. It would be good to have a test case when if we are not compliant in like three or four of those we would probably change immediately. >> Oh yeah. Yeah. That's definitely coming. >> Thank you. I do want to give back uh some time if anyone has any other opinions or some other topics we want to discuss. Mercy, I really appreciate the feedback. Uh thanks so much.

>> Yeah, I don't have any other thing to discuss. just I I need to um carry I don't know there was a chat um on discord about the ROPC test suit so did ask for regular updates so that they can track the process in resolving the issue and then if you can like summarize the differences that needs to be addressed so I don't know if you can like work this out behind the scenes and then we'll get back to Sena on this. I don't know if you saw the chat. Um, I didn't, but I um I have a spreadsheet going so I can >> Okay. Okay.

>> Was that physic or >> can you just send me a DM or I can I send a DM? >> Gotcha. Yeah. Yeah. >> All right. >> Okay. That's all from my end. I don't know if someone else has something to say. The floor is open before we wrap up. All right, I guess that's all for today. Thank you all for joining and it was really nice getting all this feedback. Thank you, Luka. >> Yeah, sure. No problem.

Open Floor for Additional Topics Before Closing

What's up? Thank you.