RPC Standards #14

Transcript

Loading developers...

[Music] Thank you.

Heat up here. Heat.

RPC Standard Call Introduction

So, welcome to RPC standard call and we don't really have an um anything on the agenda but from the last call we had we discussed about error codes and we did had um um points reviewed from Luca that we took note and we are currently working on that. I think let me share the links to the um PR that was raised so that we can keep kick off from her. So, So on the chat I shared a link to the PR

JSON RPC Error Code Standardization Proposal

and the draft for the execution error. Although it's not yet a formal PR, we're still working on it and we would really want to have some impute on the best way to go about it. Any um recommendation or things we need to change in order to get more progress around this. I'm trying to get Sims to join the call cuz he is like the initial. Okay. Hello Sims. >> Hey everyone. >> Okay. So this is the Sims is the initial author of the Oracle standardization. So I think I should let him take off from her. Sims, can you make an introduction of who and what

this proposal is all about? >> Oh yeah, definitely. Um hello everyone. Um I'm Simpson and uh I'm working with Chainlink Labs. Uh we we set out to you know standardize the JSON RPC error code because there's an inherent problem with these. Uh that's pro basically unusable for most of the clients. Uh just like web 2, we don't have a standardization on web 3 error codes. um especially our company uh working across multiple EVM chains we've noticed that this is unreliable and we cannot use this to determine that any error code suggest any particular single error uh it's either crossed within the clients or

mixus across different clients and different EVM chains um so hence the proposal and if you look at the proposal proposal is really straightforward um we We plan we've proposed to group and categorize errors and reserve some numbers or ranges for each category. So let's say uh you know for instance not coding the exact number but if we know any any error code that's between 100 and 200 we can instantly associate that with gas errors or something like that and then we can react to those error codes however the you know downstream uh consumers are willing to. So that's the goal. Um and um it is pretty

straightforward like I mentioned. Uh we just classifying errors and you know allocating 200 and it's subjective change based on uh the client feedback. Uh but the proposal is almost done. Um the next stage where what I'm starting to work on is uh try and do negative testing uh which means try and simulate these errors across multiple different chains and clients and see um how or or if there are any conflicts or if we can improve anything more. But from an initial investigation we did like an year and a half ago. Um it was pretty wild that no one was matching.

Maybe the top five clients are fine but rest of the clients or rest of the chains um had numbers all over. So we wanted to standardize. That's a short introduction. I can send the details here or the proposal and the PR that we have. uh be it'll be really helpful if you guys can take a look at it and leave some feedback. I guess most of us here already know been discussing this for for a while. Happy to answer any questions.

Yeah, so I did drop the links on the chat. So I don't know if we have anything else in regards to this any additions. Felix. >> Yeah. So um I just posted some feedback on the PR. So um there are some things there that I don't fully understand. So I have no So one question for me would be like how did you come up with this list of of of errors because some of them are really weird.

I I generally think it's good to have a to have to start the standardization around it. But if we start by introducing a lot of error conditions that do not exist in the clients right now, this will basically mean that in all the clients we will have to do a ton of work to get to the point where we you know like we have to implement special logic to distinguish all of these error conditions. And as far as I can see in the in the standard really the only key change is that the me the only method that has been modified is send uh send raw transaction. Right.

>> Right. >> And I guess also in some ways estimate gas. >> Correct. Yeah. >> Yeah. So for this >> obviously it's good to to be able to distinguish some error conditions but we're not going to implement like 40 different errors for this method. Right. It's just >> Yeah. No, no, great qu uh that's a good question. Uh initially, so to add a little bit more context is um uh the the errors that you see uh is web v as a client of uh these RPC methods rely on uh pretty much most of the let's say assume a metam mask or any cross team clients uh would would look at to react to the error message. Let's say Don's

too low, gas to intrinsic gas too low. So we can bump up the gas, we can you know increase the gas or increase the nons and things like these which are apparent and which is most useful to the cross team clients rather than between clients or between execution clients or consensus clients. Uh that's the focus at the moment here. Uh but of course like you mentioned uh we can always tweak this is not a finalized uh proposal. it is a proof of concept showing how this will be implemented but the error itself or um the ranges can be changed and it's not set in stone um just looking for feedback here and uh if you think for example and again like you mentioned yes for now I've uh shown it

only for e send transaction or send raw transaction um inherently also the estimate gas um uh just focusing on mostly when you send transaction you get an error so you can react to it uh from the from the D apps perspective or an apps perspective. Uh that's that's what I've been focusing on but of course again happy to extend this or reduce it uh whichever makes sense and some of these errors could have been like really from long back. Uh again I I can go back and fix some of them. Uh because I think the original classification it was was like from one one and a half years ago. Uh I haven't

done the new new checks again. Uh I can fix that. Uh I can go back and check it. But any any type of context you guys leave will be really really helpful for me to um cross check the cross. Sorry Marcy I cut you off. >> Okay. Yes. No problem. Um Sebastian you had a question. >> Yeah. Um so given that the uh basically the RPC layer is a multi-million dollar industry with many again multi-million dollar individual companies behind it.

um have uh we kind of included them proactively in the process gotten their feedback because if I think about it the number one reason why devs today are not using Ethereum but are using alchemy you know let's face it is because exactly these edge cases are handled much much better right and I don't need to have you know client specific forks in my in my kind of uh back end or front end code so I I think there's a lot of us for us to to learn here and I'm just curious if any of them have been involved this far or if that's the process if that's the plan.

Developer Preferences: Ethereum vs. Alchemy

>> Yeah, again great question Sebastian. Oh sorry go ahead Marcy >> sorry um sorry for continuing I wanted to chime in a little bit on this. So I did reach out to some um ROC providers but um there's kind of like reluctancy in joining the discussion and moving this forward. So I'm not pretty sure how we're going to go about it in that end. >> I mean we can just resolve it right here. I mean literally it this is the way it has always worked with >> Felix. We lost you.

>> Sorry. Yeah. I'm sorry. I I I dropped out. uh just quickly wanted to say the way it's always worked with this API is that we basically need to set the standards from the client's point of view and then the providers will follow the standards that you know have been proposed by the by the clients or have been set by the clients because for many of the APIs uh the providers will pass through the responses from the client as is or they will cache them uh you know in a generic way and so on. So it's actually for the RPC providers, it's pretty rare that they would have their own custom responder uh for any of these things. So they will mostly just like if

we fix it in the clients, they will, you know, just go along with that. >> Yeah, 100% agree with that. Uh I we've noticed only probably two major clients like Tenderly and Alchemy have the rappers on top. Um most of the other providers we checked with um just pass through the RPC responses they get. Um and we also have good working relationship with these RPC providers. But we need a base or a solid foundation to even you know tell them hey you got to um stick with the standards for that.

We need some sort of documentation or proposal to be merged officially in the open RPC or sorry Ethereum Foundation to guide them on what to implement so they can also stick to the standards if that answers the question. Yeah, I mean I think that it would be good to start but the the the proposal itself I see the main thing is that it has it has a lot of errors and some of them very questionable ones. So we have to see kind of where we can narrow it down. As far as I understand the main things that are required for the transaction submission is the is the uh question of like was it is there like

the the transaction pool errors. This is like the important category basically here that you have where it's about the >> it's about either that or then you have these gas related ones. So they look quite good because they basically mirror the actual conditions that can occur when you're submitting a transaction. Some of these other ones they are a bit more sketch. >> So >> sorry um could you could you give me like one simple example of which one would be just to get an idea? >> Yeah. So um so for example I think this the more I look at it you made this document there it's this execution errors.yaml file containing this group of and it has

codes for for example nons too low nons too high >> execution reverted invalid op code and then this out of counters thing. So out of these I would say the only thing we really need is this execution reverted because everything else is just like I mean how we don't distinguish now like invalid op code is it doesn't even exist in in EVM like invalid op codes are not really a thing so and I understand where that's coming from or like probably >> okay >> maybe generated by AI or like I don't really >> no no no I can explain that uh I can okay now I understand the confusion Um uh you don't have to implement all the errors here but let's say if you have to

implement one of these errors such as invalid op code you would use - 31603 or execution revert - 31602 the invalid op code especially the out of count counters is a zk stack specific issue where they they maintain a counter on producing zk proofs and when that runs out they they send out an error call out of counter zeros uh which is a common across all the zk sync stack not zk sync zk stack uh uh chains that we worked with and it's a specific to them and doesn't mean every client have to implement all these errors it is um if you want to let's say baso has a

specific error related only to baso they can always come and add that error which is which will be reserved for them in the future and they can just use it or any other basus based client can use that not necessarily get have to use it. So that's that's how it is. It's not that all the errors need to be uh used by every single client. >> Yeah. So what I got from uh last week's meeting is that uh the scope of this is way bigger than just Ethereum clients. It's all EVM like things. >> Exactly.

>> Yeah. Yeah. Exactly. Even the chains uh I I checked ZK sync chain some of the ZK stack chains um uh uh different uh providers like Alchemy Tenderly um just to get a lay of the land uh and it's not specific to just top five clients that we have EBM clients. >> Yeah. Well, I mean the main issue with adding all of these errors is that yeah, I mean the errors will be standardized quotes, right? right? It's not really it's kind of meaningless then because what really needs to be standardized is like for which specific condition requires your client to return this error. Like it doesn't it's not so much about like I mean yeah it's good maybe

to have the the the the error codes. So that's a good step but it's also kind of important for us to know like when should they actually happen. Uh and I guess that's >> something where I would say it's maybe better to start like bit more minimal and try to define the like top five errors that we really need. I mean it's I think it's an awesome step to start with transaction submission because honestly it has the most errors. The other uh the other uh methods they are mostly these like you know read methods for basic blockchain information and you basically have the option of like the client failed or the item is not there in which case we don't return an error return null or we have the you know we

get the item. So it's not there there aren't too many other things that can really happen but the things that where we need it the most is the transaction submission and then in some ways these like index queries like get logs where it would be good to come up with some errors for the edge cases I guess but these are not even included here. So I guess yeah for the transaction submission mostly I think we we can we can go into proposal. I have another question by the way. So you made the uh all of the codes you kind of assigned into the negative integer range. Could you maybe explain why you uh did that or >> Yeah. Yeah. Yeah. Someone commented on the PR2. Uh it's not Oh, maybe it's just

you. Uh >> yeah, >> it's we can choose any numbers. Again, like I mentioned, it was just to show how we can implement it. Not necessarily. And the reason why I chose that is it's an immediate range uh next to the JSON RPC. um standard uh I think the JSON RPC standard ends at minus 32,000. So I chose the next immediate range. We can of course choose the positive integers too. Um no no constraints there. >> Yeah, I think this is kind of a common misunderstanding. So the JSON RPC standard doesn't actually tell you that all errors need to be negative. It just puts its own errors into the negative range because then they're going to be

JSON RPC Error Code Standardization

out of the way of the application. But I mean, we are the application here. So, we can just choose it by ourself. And we have some existing error codes. Uh, as far as I understand, we have two or three defined error codes even now in the spec. Uh, they are a bit random, I would say. Like we have, for example, with in GU, we've been advocating for a long time for this error code three. Uh, which is uh, >> right. Yeah, >> for this with this used in specific place in ETH call. So ETH call is another one of these that could really benefit from some standardization I guess because there are a lot of conditions that can happen in ETH call.

And then we also have the error code 44 44 for the history expiry which I guess we kind of chose it because it matches the E and it's a very sort of we felt it's a good signal because we had to choose a code but I guess for the that means that like currently we have uh between basically number zero and number 5,000 you probably shouldn't choose. Yeah. Yeah.

>> But I that's fair. Yeah. >> Like we >> any number is fine. And then most recently we actually had a some some some requests where we were thinking that yeah maybe we can just continue from three. So like use code four or so I don't really know like we just have to in the end just like choose something. >> True. True. Yeah. Uh we can change the numbers. uh if everyone feel comfortable using positive numbers definitely we can go with the positive numbers. I just chose only because it's next to the range of standard JSON RPC. So people will be familiar. Uh but again zero other concerns for changing it to positive numbers. Of course we can change it.

I can I can do that change and uh yeah next next meeting we can have it a little bit more nuanced. So from what I'm getting uh I can reduce the number of error error codes that we have uh to focus on uh probably top errors. Um maybe even remove some that's not maybe relevant to the clients. Uh just keep it to the minimal minimum ones at least the ones I can go back into our codebase and see what are the ones we are evaluating against. I would assume most of the clients also need to use them. Um so we can keep it to that uh to start with and then we can propose adding more if that works.

That's that's really helpful. Um, any other questions? No, I mean it seems it seems good to me. I was curious a bit. So, um, in your PR also you um you added this ex you are now adding this extension for the error group. Um, I guess this is kind of a temporary workaround until the open RPC allows us to uh support the the errors. >> Oh no. Um, okay. Uh, a little bit more context there. We worked with Open RPC Foundation to bring out um the extension specifications. I'm not sure if we have

Open RPC Extension and Error Grouping

Zay here. Okay, Zane is now here. Uh so that that's why it took us long because we were working with open RPC foundation for like over an year to implement the new specification called extension specification. So this is an official um error groups uh adopted by open RPC foundation. So, but what does the current proposal that doesn't do that uh Zayn responded is I'm extending the extension um to to reserve error ranges so we can natively validate if the error uh codes that returned by a group or a method is within within the range that I'm expecting. That's the only difference. Uh right now we don't have a way to do that natively in open RPC but

I'll be working with Zane to see if we can avoid extending the extensions to add these um native conditions like a range condition but open RPC natively supports that is what actually made this solution possible because otherwise the open RPC or the Ethereum spec would would be like massive and would have to copy paste all these errors across each method which means ETH send transaction will have let's say hundreds of error codes copied under and also ETH call will have all these 100 errors again copied. So now we can create a group and reference the group from any method we want to.

So that's a that's a feature supported by open RPC. >> Okay. And then I'm I'm also curious. So in your in the actual error uh group files, you have the codes of course, but then you also have the message which is in your case not really like I mean the messages are more like identifiers and then the data says the it's it's like it's like the I guess it's the error message. So >> so yeah. Yeah. Uh great question again. Uh initially we intended the data um so even now it is possible as per the specification. Now you can use the data as any data type you want. For example, if you want to if you want to return an

um a stack of error message with multiple different fields. You can use the data field. Um uh again it's backwards compatible but we are not enforcing it currently. We don't want to break any features but uh we've added future proofed it for for for all the clients that if we want to send more error stack to the users they can use this data field um that will be supported by the specification in the future. But right now all we are focusing on is just the code and then maybe move on to using the error um uh message and the error message could be like a standardized thing string if you want to. If not, it's okay. But yeah, we

we don't want to break any compatibility at the moment and we want to be completely backwards compatible. Um, so we are not insisting on using the data field. But the data field is an object that can be reused as a string or an object. >> Yeah. Okay. So I was just curious like what's the meaning in this like because in the meaning in the in the files you you're defining the code the message and the data here but I don't know what it what if this if this means that if I for example implemented this error in the client then I have to return the error message as it is given in the specification or >> um yeah so we had a conversation about

this but if I uh if I if we enforced the message um it would mean that uh mo a lot of clients will need to change a lot of um like lot of implementation and it's a huge lift. So we are still currently debating if you want to make sure that we you know enforce implementation of message um uh so before it was data right so data field or data string used to be in message now I move that to data uh because we wanted to see if we can standardize the error string also um let's say gas to low any client can use gas to low as well so if any other if any other client uh or or D

app is uh trying to reference that they can they can sort of check the string too as an option but um right now we don't have um um say in it or a decision made on that particular topic uh just I I wrote it this way so it is indicative to rest of the clients who are going to implement saying okay gas too low it's straightforward let's do 31800 but if I say for example transaction price must be greater than base fee for for it could mean a different thing for a different client. So I don't want to um make it too verbose. So just you know in short uh you don't have to implement the message at at the moment and you don't

Future Direction for Data Handling

have to use the data field to return the data but it's uh it's the direction I feel like we should go in the future to make it more expansible or expandable um so we can uh send any more any data or data stack uh as part of the header uh in the data field but right now um just focusing on her. >> Oh, any other questions?

>> Yeah, sorry. Go ahead, Mercy. >> No, I just wanted to ask if there's any other questions or contribution on this. Kira, can you please go on? >> Um, I'm wanting to change the topic a little bit. So if there's any more questions about error codes or want to talk about error codes um I can wait >> yeah I have one more I have one final uh comment about it. So before we before we continue with something else. So the um I I posted a link there now in the zoom chat uh for some for some hive tests. So this is actually the current situation with the error code 3 and maybe it's something we could actually change. So um I'm pretty happy to see that. So for this specific error

um this error is the the error code three is the one that should be returned when the in ETH call the execution has reverted and it should give in the data field the raw data returned by the EVM uh from the contract. And uh this is this was like this error code 3 thing was for me like this kind of little experiment to see if we can kind of make it like start the uh the standardization uh here because the the at the time when this was added we like

the clients were returning results all over the place like some clients would return wouldn't return the error data or other clients would return wouldn't would return the error data but it was already parsed from the AI and so on and I'm now happy to see that at least with BU and Nethermind they are actually returning the raw error data as intended but they are not returning error code 3 in the situation but they are returning a generic server error so um it would be good if uh in Bizu and in Nethermind We could return the code three in this specific instance. It's not I think it's not that much of a change honestly and it would probably

like help us resolve that thing at least just >> code free on what on execution reverted. >> Yeah. So that was basically this this has been this proposal has been kind of open for a long time. I actually don't know if we have it even merged in the spec, but I think we let me see if we ever did.

So it looks like we have not merged it to the spec. So there should be some kind of open PR maybe. Yeah. So it's this PR here PR number 600. I will also post Yeah. Yeah. Yeah. Carrie posted the link also. So yeah, that was the proposal for the spec and uh we did add it into the test suit. uh kind of long while ago and I was just thinking like I mean can maybe we can this is this could be one of these cases where we just kind of resolve some of this issue like right away on this call because I think we have representation

here from Bizu and Netherm and so we could just you know decide now uh how this is going to be handled and then yeah we can make some progress. Sure. I'm I'm being koi, but it seems reasonable. >> Ah, I see. We had uh recently a PR doing some changes there. I see. Okay. There's a description about this code free. I'm also licking it but we didn't change it

there yet. Okay. So >> yeah, I mean that would be great like if we couldn't because like I said I I added this to the spec like I added this to the test kind of sneaky way because in when I added the test the the the error data was not correct and somehow in between then and now the error data seems to have been corrected just the code is not correct still. So if we now also change the code, you guys going to be passing one more test and we'll finally have like two clients or three clients returning the same. >> This probably corrected the error. So some parts of that, right? But not the error code. Okay.

>> Yeah. And then I think in the next step for ETH call uh we could actually figure out some more code like the revert like the for ETH call the uh execution reverted is basically the most um important condition because people kind of want to know when the contract failed they kind of want to get the solidity error message and so on. It's just so that is that is kind of the the the the the big thing. But then there are some other things. For example, if the gas is out of range for the client, like if the node doesn't allow the the gas because it's over the like configured cap and things like that, there are no defined error messages for that. It's kind of hard to test these things, but I guess at least we could define a code. But

this is this is something where we can create another issue. And then this is also going to have some overlap then with the other proposal that we discussed before because we should probably use the same codes >> that we use for the transaction submission also in E call. >> Basically call is going to have a subset of of them. >> Yeah, I can I can probably try and use the same error codes that you guys are returning. uh at least I want to make sure that let's say if execution errors happen it it it falls in a range of 1 to 100 and gas error is in like 200 to 300 something like that uh but we can try and reuse some of the previous errors I

mean there is really there aren't really any that's the thing like there are no errors right now I mean the clients all return errors but it's just they all return these like generic error codes from JSON RPC and this is in part what has led to the current situation or for example certain apps parsing the messages uh because it's just there was just no other way for the apps to really distinguish these very important conditions. I mean you know this because you as you said you worked on that kind of library as well. So this is it is obviously very important for us to agree but the clients at the moment don't return any kind of coherent error code and the only error code we tried to establish for this was this code three like I said because the and then the other error code we tried to establish

is the 4444 when the history is unavailable. So I guess we still I mean I'll I'll get back to you with some more codes that we could possibly add but >> that would be awesome. Yeah, that would be super awesome. Thanks Felix. Yeah. So the the point here is to have ETH call and send transactions having the same error codes, right? What weird. So the point here you were making to have the ETH call and you know all other call like things uh to have the same error codes as uh set transaction.

>> Yeah, I mean send transaction is just going to have more errors. That's the thing for ETH call there aren't really that. I mean the main thing is that for ETH call one of the things you can do is because you can target ETH call to a specific block in the history which obviously you can't do for the transaction submission then it's kind of that uh there's going to be some of these like history or state related errors as well. We're not really touching these in this in this in this initial proposal, but at some point there will have to be a list for these like errors related to the state where there's going to be something like the client is missing the state to execute this call or the client is missing the history to execute this call. Things like that and we don't really there's

Error Handling in Transaction Submission

none of that exists right now. I don't even think we have really standardized it within the like I don't know what kind of error we return right now for that kind of stuff. But yeah, that would be like the stretch goal. So, in general, I still think it's good to start with transaction submission because it has the most errors. Just >> Yeah, I'm fine with that. Awesome. Thanks for the feedback. >> Okay, I guess that's all for the error codes. K, you wanted to say something?

>> Yeah. So, I'm just curious like how what is the best way to like make changes in this? Is it that um we like put the RPC methods through the eat process and go that route? Is it um that we merge changes into the execution APIs and clients start failing on um hive? Like what I what's easiest for client devs? One thing I've been thinking about is like versioning for execution APIs. And so like we can announce when we're going to make changes.

Um, but I'm curious from like a client dev perspective, what's the best way to like make changes or get input even? I mean I can give a quick comment on this. We discussed also before um this turning it turning the changes into EIP has been tried but and there are some EPS in fact for for that are still open in the interface category for for these changes. Uh the problem is just that um the interface category is very overloaded with some stuff that nobody really understands or it's like because

it's coming from a coming from like a different universe like for example they are trying to standardize the wallet internal RPCs there or they're trying to standardize like for another chain or all these things. This is not there's a lot of noise there and for just specifying like changes to the execution API as it is implemented by the Ethereum nodes it will just kind of be lost in this because if we now start to merge just the EIPs which are related to the nodes then everyone's going to be asking like what about the other EIPs or like is it's kind of hard to draw the line once we like I think for now the consensus

has just been that everyone kind of gave up on the interface category. I know people are doing some stuff there, but like for the clients, it's never really mattered because once they start looking there, it's going to be kind of wild like what which of these proposals are, you know, should be implemented, which one should not be implemented. It's kind of impossible to decide it. Yeah. I think the silence here is very telling. This is this is kind of the big question that this subdomain of Ethereum has struggled with in the past. So I'm

glad we're at least thinking about it. Like I can I can give an example like for example there's a there's there e such as EIP6 695 like this is a very old EIP and this EIP for example this added the uh the like chain ID method. So this one if you submitted this today like this would be probably considered one of the like acceptable ones right so I mean yeah this as an as an Ethereum client you can very easily implement this method and in fact it is implemented in all the clients it's part of the spec now like this is one of these examples where someone took the effort they put in the EIP long time ago it was agreed that

this is a good direction it was put in the spec and so on but this sits next in the same list you have things such as I don't know like an EIP that's saying uh you know the window EVM providers object or something like that. This is not an EIP like this would be EIP 57449. So this one doesn't really concern the the Ethereum clients at all. So now it's just kind of the question because with RPC it's always so open-ended uh who implements what or like where does this even apply like which I mean obviously the first EIP right 695 we could have brought that up on ACD but like the second one maybe

it was brought up on ACD at one point like when it was discussed I have no idea how this you know when this was merged or when this was turned final or who should even implement that and there are some other ones that kind of got left by the wayside that are in a similar direction but they didn't really make it. So it's not like with the EPS it has some downsides. If we start using EPS for this then we first have to kind of clear up the backlog of the existing EPS that are kind of I mean people are still proposing EES there and I mean there are some in last call. I guess uh one of them has been in last call since 2021. There are two of them which are in last call. One since March, the other one since

or like until March and then the other one until like ETH config was kind of speed kind of speedran all of this process I guess because it was deemed important. So it's a bit of a mess. Yeah, I feel like um I don't know. I think there needs to be some sort of process, you know, rather than just like yolo merging. Um >> yeah I mean definitely it would be good and that's why I was

also like for me the ideal case would have been that if we somehow manage to ever get to like this is also one of the reasons why we didn't expand the tests so much in initially because I kind of was hoping that at one point we will finally get to to the to to to the exciting moment where several clients are passing 100% % of the tests and then once we have that stable base we can like very carefully extend it and like see what else we can pull in under the standardization effort and just kind of kind of do it a bit in lock step but it was just very hard to like get to this initial passing state and I feel we're closer to it than ever now uh with the RPC compat test we have very few

failing tests for some of the clients so I mean if we can put a little bit of extra work in to for example resolve the final differences like for the total difficulty with Nethermind and so on and then maybe for some of these like error codes for the unimportant cases then I think we can be very close and if we ever get to the situation where you know it's the default to have the green tests it's going to be quite easy to say you know what guys we added five more tests can you please check them can can we can we try we never really got to this sort of initial moment so we're still kind of trying to play catch catch up on the existing issues that are years old.

Yeah, I think that makes sense. All right, I can keep bugging clients and sometimes it it's on the execution APIs too that need to be updated, but So is I don't know if there's another thing on this end. Okay. And the floor is open for an open discussion. If you have another thing pending we want to discuss on this.

Yeah, Baronabas, I can quickly give an update on that. So, we have been Yeah, this is I don't know if this is like depressing or or or exciting, but like on the GU side, we have been working this year on a proposal for like some kind of minimal rest API. Um, this is coming as an kind of reaction to the frustrations that we felt especially last year with the JSON RPC. So for the rest stuff, we were just thinking that we'll basically have a brand new proposal. Oh wow, it got the download. So we we've been thinking that it might be easier to get started on like a very small um proposal that basically has a minimal

New Minimal REST API Proposal: Discussing a new API to replace JSON RPC

and fully trustless API for like the core functionality offered by the nodes. And if we could have this then it would maybe somehow be possible to implement the JSON RPC of uh interface on top and also since it would be a new API we could avoid some of the problems of the existing API notably this kind of scope creep and the overlap between the wallets and providers and different chains and so on and basically start something new. The downside with the rest is that since the JSON RPC is kind of uh sort of an industry standard in the web 3 space, it's going to be a bit hard to convince anyone to use it.

So yeah, I mean we don't really we we're still working on this. We have the proposal and um we have we've just started working on a demo implementation of it. So we can at least have something to show and I guess it will be presented if you guys are coming to Devcon we will uh try to present more about it at the ETH client summit at devcon connect. So that's where we were hoping to kind of introduce this and uh you know start off a bit of a discussion between the nodes on the like available features and so on.

Um, so Zen, I don't know if you have any other thing to say. Zen is from the Open RPC team. >> Actually, sorry, I'm joining really late, so I actually don't know what said. >> I can add one thing for a little bit of context. Um quickly um uh Felix was asking um about the extension specifications. So if you want to give like a couple of lines about extension specifications that you help cook up.

>> Yeah. That's that's easy enough. So um so open RPC has an extension specification uh which basically allows you to define extensions to the spec for things that are not officially a part of the spec but may be on the road map to be a full member. So those are things that like sort of provide an upgrade path um for upgrading open RPC in a sustainable way as well as allowing for customizations uh that may be application specific. Um other high level things I can say about the extension spec is that you can include an extension in the spec itself and so other people will be able to read

and consume this and validate against it. So for instance with like sort of error codes or error groups you'll be able to um like pull that down as uh a person that's just like say writing a spec against something else and then be able to define like oh cool error groups I can put x-roups and these locations and then everything else will sort of fall out from there depending on what the consuming system like renders or doesn't render. Um other things about the extension spec

um extensions back sort of changes or improvements. So initially um we kept the extensions back to be tied to um the actual sort of specification objects. So like method object or it could be like errors or things like that. Um but we started to use JSON pointers uh instead. So you could be even more specific. Okay, Mercy, go ahead. >> No. Um so this is actually out of context. I wanted to ask you about the any update on the documentation font.

Open RPC Documentation Updates: Rethinking documentation and improvements

You did mention about um some improvements in that regard. >> Yeah. So um Open RBC team has been um rethinking the way that we do documentation. So the way that it was a long time ago, it was like soda the state-of-the-art um with Gatsby like four or five years ago. Um but now we kind of want to move back into this docu direction, but even more generic than that. So our thinking is is that we're going to create sort of a generic base that produces the open RPC in markdown and then consuming projects can then uh depending on how they want to redis that um display that in markdown. Um so for

us it's going to be almost slightly two-tiered. So one is generating a sort of markdown generator um which is going to be almost no changes from your perspective. The only difference is is that now the open RPC won't be an opaque uh contribution to the repo but it will be generated code and then the consuming docu plugin will then have nice sidebars uh curlability and you'll be able to drill into individual methods and you'll also be able to do um sort of the sorting by type um which has to do with document tags.

So one of the problems that we kind of identified with the execution APIs is that um you don't exactly know where a method comes from from what fork. So being able to tag this and then the drill down like what's coming up in Glamsterdam or what's coming up in um Fubar fork is really useful. So we're going to try and bring some of that versioning nuance into the docs. Um, so we're just looking for a great baller experience. And if people have like other sort of UX uh leaning improvements and things like that, um, just let us know. You can drop us a line either directly in our Discord

or you can just at me and the, uh, JSON RPC API context. Um, but that's just like a little bit of where we're going. And then the sort of longer tail of that is uh thinking about errors and negative testing within the spec. Um which is kind of where Sims is is talking about, but we're thinking about doing something a little bit smaller to just like get us started. Um so just taking the standard errors that we have right now and then making that negative test work through um the uh light client's like coverage tool etc. Um, and we also have some additional coverage tools that aren't currently being utilized um, by EF, but

could be utilized and would be like probably super beneficial. Um, okay. So, I kind of rambled. I got in there. Let me know if anyone has any questions. Um, yeah, and happy to talk about it. Um so okay thank you. Um thank you everyone. I think this should be the last point of discussion or do we have one last things to talk about or we should call it for the day and also um I just wanted to say um I

don't know if Kira is still here about some PRs on the repo itself. We need to if lifelines can be made available to look at some of the pairs and also especially the ones that have to do with typos in um in the docs itself needs to be merged. >> I can look at those if you want to send them to me. >> Okay. Okay. Thank you very much. Thank you all for joining today's call and I'll also urge us to join us next week. Our calls happen bi-weekly. So this would be um a great point of contact for us to have discussions like this and actually get things moving because we're kind of like um on a more slow pace. So

if we have these discussions and we we are more we get clarity on the things we need to do and act on it will help us move faster and then achieve more um tangible results. So thank you everyone. Thank you for joining. Bye. What's up?

things.