RPC Standards #12

Transcript

Hey Mercy. >> Hello. Good evening. >> Uh good evening. Uh we are live streaming this call on uh Ethereum Protocol YouTube channel and EC Institute Xand uh handle. So let me know whenever you are ready so we can switch into stream. Okay, thank you. Hello. Um, sorry. We will start soon.

Um, I think Zen will join. He said he's joining in the next 5 minutes. I'm not sure. Okay, he's here. Hi Zen. >> Hey. How's it going? >> Fine. >> Akash. >> Good. How about yourself? >> Yeah, >> I'm okay. I'm fine. Um, you can start streaming now. Thank you.

>> Yeah, we are live. >> Okay. Um, good afternoon everyone. Um welcome to RPC standard call 12 um being today being September 15th 2025. Um we don't have much things on our um on our agenda today but I would really love us to discuss about the stages of our PR because we have so much PRs on the repo. So um I think Kira you have um me right to to the repo. I'm I don't know if I'm correct on this.

>> Yes. Yeah, I do. >> Okay. I I don't I'm not sure how we're going to move forward, but I would love for us to kind of like move up with the PRs we have because we have like a whole lot of PR that has been still for a very long time and it's not really looking good at this point. Yeah, I think um I we I'm on the testing team and so we've been focused on um getting pusaka um ready to go, but I think in the next week or so that'll calm down a fair amount so I can start going through PRs um and just see where we're at with

those. I think one of my main priorities for this repo is getting the Hive RPC compat um test passing and so I think >> okay >> um to me I think still PR is it's not going to hurt them to stay there longer. Um, I'd rather get like the live stuff going and get the um the hive tests running first um and get kind of clients involved and then go through the sale PRs.

Is there something you need like we can help you with that? I don't know. >> Um I don't think so right now. Um I think the biggest thing is um do you know the hive hive test I'm talking about? >> Yes I know. >> Okay. Um >> which hive test is like failing out of curiosity. >> Yeah. Um let me >> there is like on hive test the last time I checked there was so many failing tests during um it it simulate call. We had that similar complaints during it simulate calls. So, um >> yeah. So if you pull up this um this

link here um like RPC compat for me it looks like the first one um the first category um and so clients are failing but some of those are just like ordering problems um like some of them aren't real failures and so some of them we need to change on the execution API side and then some of them clients need to change or we just need to mark some of them are from clients that support certain use cases And so, um, a lot of things we need to just change on the on our side and then other things we need to kind of bring up to the clients to have them change on their side.

>> Okay. So, what I'm saying is that the essence of this call is basically to push up anything that concerns Hive and the RPC repo forward. So if there's a way we can help or issues or anything, it will be e it's to be helpful to let us know and maybe I can work around it also because at this point I understand it's the the first the test failing is client specific but I'm not I don't I know about hive test but I don't really know um um the technical aspect of it that much. >> Yeah. Yeah. I think that's kind of the the heart of the issue is that um like we we just need someone who can like

look at these tests and um figure out what we need to do and what the next steps are for either us or the clients. Okay. Okay. I think I'll have to look into this and get back to you. Does anyone have something to say in respect to this? >> Yeah, just uh another quick question. I'm still slightly ignorant on on RPC compat. Um so the issues that are happening are also reflected back within the execution APIs and RBC compat is

expecting responses in a particular order and that like uh return from the various clients is not in that same order of the captured reference run from like say G uh and that comparison between the outputs is what is then failing. or is it um the >> I feel like um >> specification itself >> uh is much more specific than the data that's returned. Um just just curious uh as we're starting to think about um doing some more work around uh negative testing for like errors within the

execution API spec. >> So I'm not sure what you mean but talking about get has like the highest think the the test here passes they have 120. Yeah, but it I mean it kind of comes down to like sometimes we're too strict and sometimes the clients aren't following the spec. >> So, >> what could lead to that though?

>> Sorry, say that one more time. >> I say what could lead to that? What could lead to that? So I mean >> is there sorry is there a way to like make them sort of um reach a consensious? >> Sorry to make them what? >> Is there is there not a way to like make them reach a consensious? >> Yes. Yeah. And so we just need to go in and look at them. Um they're running against I think the um I forgot what it's called. Um but the testing tool that leg client wrote and >> Oh, so they're RBC test.

>> Oh >> yes, but they're running against the IO files. I'm pretty sure like I'm pretty sure they go they compare the results from those IO files from RPC test gen. >> Does that make sense? >> Oh yeah. No, now the whole thing is making sense to me. Okay. I don't think it's it is simulate alone. Um I don't know.

But they stopped working for some months. I think I will have to get back to them. It wasn't from e simulate. I can I think I can remember. I'm seeing a lot of um >> RPC compact testers failing on e simulate specifically um they expected it's e simulate does not exist but the actual result is it it is returning some response as per the test suited I think it should be a simple fix I don't know but yeah looking looking at the some of the tests just eat some late I'm pasting a link here maybe due to the

eat because there was a latest addition to the methods and it's not expecting that method to be present. I I actually thought they faced it because Cena was saying Cena and um Mika the last call they had was about the last two calls rather was about this.

Oh, I'm not sure. Um >> actually for a different client it's different it's failing for a different reason. So eat is a I see as a constant but I also see Some of the test might need to be updated like uh Zayn mentioned. It could be the order, could be some formatting. I do see some formatting needed on the test test front, I think. Yeah, because when they wrote the test when they when they wrote the test, there was it was their test that broke um the ROC um CI that we had to it was expecting an ar it gave was

expecting an object but it gave up an array stuff like that. Yeah, I think the execution APIs like spec schema changed. Um I think uh NA had uh put uh yeah like you said an array and an object was like one of the issues. Um there was also like some mal foration in the schema itself that was causing u issues. And then um there was also the uh sort of negative testing within the uh spec. So, um, the tests that were

generated were for bad params being thrown in, but the way the RBC test gen works is there's not really a clean way um, currently do the test for like throwing in malformed parameters because uh, the schema validation will just throw back error. Um, so they got rid of the negative test and then reformatted from the object to an array, which I think was supposed to be the original spec anyways. And maybe the rest of the clients just haven't caught up to those changes. Um, but it's been about maybe a month and a half since that. Um,

>> yeah. And it seems like a lot of the problems are just like e simulate v1 is not available. Um and then it wasn't exactly clear just me taking a cursory look at the code. Um like why the method wouldn't exist unless it doesn't exist on the clients that are running the test and maybe that's the case. Uh >> yeah, that that could actually be the point because I don't think then it was only Bessu um rather nethermind and get that was working on it and get did not finish their implementation that I'm sure but I think the best thing is to like get back to the implementers and

then maybe get a proper feedback from them because they have an intrinsic idea of what they are building and what they expecting. So, I don't know what do you guys think? Yeah. So, my priority for the next um little bit for this repo and I also, you know, I don't work on this full-time either, but um is to figure out like what what do we need to change for these RPC compat tests? like is it that you know Aragon needs to support um e simulate v1? Do we turn those off for

Aragon? Um and trying to figure out what to do on that front. >> Yeah. >> Okay. Just to be clear on that front, do we need to contact the client devs involved? >> Eventually, but I don't think we're ready to do that right now. I don't know which failures are ours on the execution API side or which failures are like theirs >> if that makes sense. >> that makes that makes a lot of sense. The one other sort of question um that I know on open RPC side that we've been thinking about um that may also just like help in these kind of

scenarios um is um adding a marker for like what methods belong in like what fork. >> Yeah. Yeah, that would be super helpful too. >> I do think um >> Oh yeah, go ahead, Carrie. Uh, well, I was just going to say I do think they probably run on a certain fork, but I'm not sure about that. But yeah, it would be nice to have a marker. >> Yeah, because um that's one of the things that we want to add to uh execution APIs, which is like proper versioning.

So uh execution APIs and the the whole spec could have a version of major and minor and then um we've been floating around across two different possibilities. So one is that the open RPC document uh itself is versioned by a fork or it's individual methods. So the individual method approach means that you'll be able to um potentially tag methods for future forks. So you'd know that this method came from Fusaka, this one comes from Glamsterdam.

Uh and then you could potentially uh roll through the document and pull back all the Fusaka methods and then you would be like, okay, this is what we're going to run. Um, one part that makes this a little bit funny is uh thinking about all the methods before Fusaka or all the methods before um all the different sort of forks themselves. So uh like how do you pull that back? And so maybe that's a combination of uh having a semantic versioning for the open RPC. So that would be like major minor patch and then that you would put in uh like okay

anything with 1.2 and Fusaka and that would just pull in everything uh past a particular date. So the major minor uh patch would just kind of be like that mile marker to grab everything past that. And so maybe the major or minor versions are just going to be the forks and then uh that allows you to pull all those methods or to specifically grab things from a fork. Just throwing that out there. Uh that's some of the things that like we're thinking about uh as like an upcoming like useful thing.

for for those that are spec maintainers and spec knowowers. >> Yeah, I think that makes sense. I think um I think the forks forks being majors versions I think makes a lot of sense. Um and I think that's how you know that's how testing versions as well. Um I think it becomes a little less flexible if you're trying to be like extensible to other eco systems. Um but yeah, it would be super helpful for us.

>> And then my question would be um yeah, I guess there hasn't been like a major breaking change for a long time since proof of stake. Um so that would be my only sort of push back would be whether or not it would land that forks or minor version updates. in general. >> Yeah. Yeah, that makes sense, too. Um, yeah. I think it I think it just depends on on like you you guys like if you want to use semantic versioning >> as like true, you know, like a major is a breaking change versus just like the

feature changes that come with each fork >> because I don't I don't think they're getting rid of RPC methods usually except for the merge. >> Yeah. or occasionally there's a deprecation like um I don't know Eve account but it still exists on G. >> Yeah. Right. >> Okay. Yeah. So I think that makes sense. That makes sense to me. I I just like noted it for like sort of my personal notes for going forward.

>> Okay. Um so is there anything we would love to discuss? Zen, I thought he had something on the agenda. So, >> are you there? >> Sorry. Sorry, Mr. Point. Um, can you repeat that again? Mercy. >> Okay. Um I was asking if there's another thing we would love to discuss.

>> Oh yeah. Yeah. Um yeah I can provide an update. Uh yeah I've been talking to Zayn. Um uh if you remember from our last conversation I was able to add a bit more um cohesive range reservation for each category. Um uh discuss with Zayn. Zayn also discussed with Shane. Um I think we have a good solution even though that may not be final. uh but we've decided to move forward with this for now and um I'll be writing a readme file for you guys to take a look at it so it's easy for you to review the whole PR uh this week and uh once I get a you know uh thumbs up from you guys I can

start implementing the other part of the solution which is RPC testion uh for validation and extra verification of these ranges uh on top of what I already have So it's uh it's looking really close to be getting done. Uh so that's that's the update for me and uh I'll be pushing the uh readme file once I have it in the channel. >> This is for the error codes >> standardization. Is that yeah correct? >> Do what sort of buyin do we have from clients on this? Um so this uh we we tried to present this in the Ethereum uh developer meeting and um they nudged us

to this meeting. Uh we have Basu working with us. Um that's the first one. uh but other than that no other clients seem to be interested but I heard a lot of positive reviews on the first meeting where we tried to present uh but no client has reached out yet and this is not going to be restrictive implementation initially uh it's going to be just a kind of a warning saying hey stick to this uh error code range or error message um and then slowly start pushing it as a strict measure later on uh depending on how flexible we need to be. But this is sort of like a guidance for protocol implementation

uh to stick to certain ranges or stick stick to uh a standard. That's that's the goal at least for now because we >> we acknowledge that it'll be really restricting if we push every client out there immediately to adopt to this and uh it would require a lot of changes on their end as well. >> Yeah. Yeah, that makes sense. Do we know what sort of like breaking like downstream effects it would have? >> Literally changing letter code to the right one or should not be any breaking changes at all because we made sure that the uh proposal is backwards compatible and same structure uh what Ethereum currently does and um just formalizing the existing implementation that we have

and maybe even providing a little bit more. I haven't written uh the spec for that uh but we have it in our original proposal where you can actually change or interchange the me messages for an object so you can provide more stack for for the users to refer but right now we haven't implemented anything just slowly rolling it out at least get the error codes out so anyone who wants to use these sort of standards can use it that's the goal for anything you want to add, Sane?

>> Yeah. So, I'll add just a little bit to that. So, um a lot of the sort of thinking is is like, okay, um we have all these error codes. Um like you can actually return back anything. Um, but it would be great if the spec actually like covered what you should return and then there's like uh it would be also nice if like uh the spec itself had a reserved set of ranges that could grow with the spec that then we could allocate towards certain sort of categories of errors whether those be

like execution errors like you see with like E simulate or gas related errors. Um, and we can say like, hey, look, um, oh, we don't have these methods that use this and we don't have this specific error, but it's a large enough range to where we feel like, oh, if we add like 500 different spaces for the code, we can eventually formalize on like, oh, let's assign like 32503 none. Um, and that prevents um downstream consumers from just like grabbing at error codes to do certain sorts of like functionality.

So here's a kind of weird complicated thing that like we'll eventually need to sort of sort out. Um so on the consuming side of clients uh there like clients like MetaMask and like say Flashbots for instance just because this is one that has come to my awareness recently um they like MetaMask has some codes around cancelling transactions and then MetaMask will do some things like call get transaction receipt and get transaction receipt uh returns back uh a code But uh the way MetaMask is structured, it is not going to cancel a transaction to a certain sort of like

point which has some ramifications for like the minim or transactions on like sort of flashbot side. So what Flashbots is proposing to MetaMask is that they return back a very specific Flashbots like error code. Um and then MetaMask of the consuming side can then say, "Oh, I got this weird client error." And then I can respond to it and I can just cancel this transaction because like Flashbots has it in their private memory pool and it's all good.

Uh and so like there is a potential that there are lots of these kind of like almost side deals that are going with the error codes and because we don't have a formal range right now. Uh anyone can just like start throwing back anything and then that could then come into conflict with the things that we're already trying to do um with error codes. So the sooner that we're able to define a range for returning or um what is acceptable then like the better it it works.

>> completely agree with you. more truthy it is and then the more we can actually test against it uh or like hey is the client returning the proper error code for this and the more developers can rely on it and that kind of thing. So, so that's kind of the motivation um behind it and the thought is start with all the stuff that we already know, define it, put it in the spec, make it really nice to actually use. So, error groups kind of do that in a way. So, it's like, oh, you can reference to a whole group of errors versus needing to individually list out every error on every method. You can

just say, oh, this like e.get get gas or if call can return back execution errors or gas errors and we're just kind of done. All right. Um, so that's that's that rant. >> Cool. Yeah, I think that makes a lot of sense. As long as it's not too like constrictive to, you know, it won't like break clients. I think that's a good good approach. Sounds like >> So, I also like to Okay. Sorry. Sorry. No, go ahead. Mercy.

>> Yeah, I wanted to say if it would be nice if we get like a docu documentation so that um or kind of like send it to the various clients because the earlier they give us a feedback if that is any the better if not keep running around in circles and keep spending more unnecessary times on it. I don't know if that makes sense. >> No, definitely agree. Um the last week I was able to do the error ranges. That's where we struggled a bit because conceptually it made sense but technically it was a bit harder to implement. Uh but last week um with sane's feedback I was able to get that done. Now I can actually write a um you know spec or a document for sharing it with other clients. uh it would make a

lot of sense now because before there was no way to restrict anyone or not restrict like guide them to say this is the range we've reserved for for an error group uh now that we have a codified solution uh it will made make a lot of sense to associate with the code now um yeah I'll get started on it really quickly and we want to actually get this out sooner than later um we'll we'll we'll keep you guys posted on the channel. And again, thanks to Zane and everyone for bearing with us so far.

>> Thanks to you. >> You >> good idea. I'm just here to help make these things like happen. >> Definitely. You know, you've been massively helpful. Say, >> cool. That's it from me. >> Okay. Thank you very much. Um, is there another thing? Sorry about that. Is there anything we want to discuss? Um, Zane. >> Yeah, sure. Um, I will just give a brief update on some of the thinking that we're having around like the docs like sort of rework, rethink. Um, and part of that is is that we're leaning towards um

trying to do something that's like a little bit more generic and maybe easier to work with from uh many different documentation like sort of framework aspects. Uh and by that I mean uh we're thinking about like sort of generating the markdown into the repo itself and then doing things like say generating do not edit like uh tags for the markdown. And so this kind of has the effect of making it easier to work within uh various frameworks that anyone may have. So, if you had like the Docysaurus or like even if we were to

say, "Oh, we're gonna keep this Gatsby," which we're not. Um, but it would make things uh much easier if you wanted to do readme docs, you could do that. If you wanted pan doc, you could do that. You could do PDF if that's where you wanted to go. Um, and then to just kind of make that really easy. Um, and so that's kind of where we're thinking like infrastructurally we'll go. And then we have a bunch of like sort of features around that to generate MDX for the more specific things like being able to run curl on things or to do a lot of the nice uh modern API like specky things.

Um the other thing I would say about that um oh I had something else. Ah yes um so in the revamp what will probably happen is um the markdown that would be generated would be for individual methods. Uh and so that talks about like doing individual method pages um kind of like uh the route that things were headed um before we had to kind of revert to go forward again. Yeah, that's that's pretty much so the update.

Um, I guess while I'm in there, I'm also kind of curious to hear um from the users of docs. Um, and just general docs in general, uh, general docs in general. Um, just docs in general. Um, what do you find yourself doing a lot of that is somewhat frustrating? Uh if you have any of those things, feel free to let me know. You don't have to say it like live right now on the call.

Just like drop me a thing in the Discord, a message, and uh I'm happy to like hear about it because now is a good time to let me know. >> Okay. Thank you, Zane. Um Oh, definitely. So is do we have anything to say in respect to this or we'll talk a sec. Okay. I guess not. So any other thing we need to discuss before we end the call? I think that's

um we've covered most almost everything. All right then. Um, so okay, I think that will be all for today and then see you guys sometime in two weeks time probably.

Thanks. Thanks. >> Thank you. This >> Thank you.