RPC Standards #7

Transcript

Hi everybody. Welcome to RPC standards number 7. It is June 23rd. We are being recorded. The agenda has been posted in the chat. Uh this is Ethereum PM issue 1585 for those that don't have access to the chat and we have a number of different things on the agenda and I think we can just take it from the top and start working through them. So uh thanks everybody. big thing that we want to tackle at the top of the meeting is the Docosaurus versus Gatsby conversation.

Uh has anybody had uh a chance to form an opinion on the matter? Um just to kind of lay things out where we are right now, uh we have branches that do both. You can take a look at them. Uh the current recommendation from Open RPC is to go with Gatsby which is going to be a little bit more future compatible with where their road map is going. Um that may be an oversimplification but I think that's kind of the gist of it. Uh so uh let's open the discussion there. Anyone have any thoughts, opinions, concerns?

Well, I'll I'll take a stab since I'm as the one who wrote both the PRs um or the one who was anyway. I I think I'm down with either. It makes more I mean like I will say the docu one is much prettier to look at but I also I know that the spoken RPC team said that they were going to uh work towards an update to the visuals and that's not you know imperative to the functioning of the docs and if we can stay with the open art I mean if whatever is maintained because the docu one has some documented flaws and it's old and some of the some of the formatting has been broken. So, um I I' my personal vote would be to go back to the open go back to the Gatsby stuff. Um whether or not my PR is

exactly how we want to do it or not, there may be better ways, but um it at least gets if we were to take that one, it would get us up to date with their stuff and kind of it pulls I've also updated it so that it pulls in all the all the narrative documentation that we have and puts it in the sidebar. So, it kind of has all that stuff and it should pick it up automatically as we add new things along the way. So that would be my first opinion. Awesome. Thank you. Anyone else got a thumbs up from Zayn?

Okay, Mercy's got a thumbs up, too. All right. I will make one more comment that if we do decide we want to move forward with going back to the open art the Gatsby one, I would like appreciate some more feedback kind of on just the way it's set up and I'm happy to like talk through it with anybody who wants to like look in detail at it. Um, so I'll just like I have there are some some hacks. They're they're not bad, but just ways that I had to set it up because of the way we generate the Gatsby. um code.

So I'll have to delve into that now. That's just UI kind of stuff. Okay. So when you say when you say feedback on it, it sounds like kind of you know build process, how it gets deployed, how it gets built out, things like that. Oper operational and best practices advice is what you're looking for, right? And yeah, and just some opinions about like like I said, I'm I'm lazy, so I use I use AI to help write some of those m some of the scripts that migrate our our code into the builds. Anyway, there's Yeah, I mean, it's just it's just like stuff that I'm not I'm not a I'm not a front-end guy by trade.

I Yes, I do JavaScript, but I'm I worked on the back end for the last four years. So, it's just someone with a better nose for that. Like, I know how to do it and not make it look good given the tools we're working with, if that makes sense. And then also like any improvements to the build process because it's right now a little bit brittle. Um, and it as soon as we start moving this around, we're going to have to modify these build scripts that I put together to make it work. Right. Okay. All right. Uh, do we have any volunteers for that immediately?

Yeah. Yeah. Sorry, I didn't quite get a question. Uh, yeah. Go ahead, Mercy. And then Zane, I did not really understand what he was saying cuz background is kind of noisy. Sure. Yeah. Uh, essentially what he was saying is that the build process is a little bit brittle and he does not feel that he is, you know, a super advanced front-end engineer and so we could use some advice on the build process, how it gets folded into our development workflow, um, and how it gets deployed, things like that.

Okay. Yeah, I noticed that when I tried running um his spear. Um it's quite it's I think the other one was kind of like more straightforward than this, but I don't even have an idea. Think we need to figure out something. Okay. So, it sounds like you're seeing the same problem that acolyte was then. Yeah, it building it takes like extra step like you have to do run the build then generate the clients then build the docs run um mpm run build docs gatsby speed then copy the docs again and like it's there's several runs rather than just one command I don't know what I'm

saying makes sense yeah it does yep spend a ton of time on this call talking about that it's not specific to this if everyone's okay with the general eneral idea of going back to open RPC Gatsby build for now. I mean, we could build we can merge this as a first step and then keep working on it because it's not all the time that we're doing this kind of stuff, but it would be good to get it Okay, sounds like we have a decision. Gatsby, it is good progress, folks. Okay, uh let's see. Are we ready to move on to the next item on the agenda? Going once, going twice.

Okay. Three times is sold. So, uh, second, uh, go ahead, Mercy. Yeah, I wanted to point out that um, we have a CI that is failing. I think um, MA mentioned that on the chat. It would be nice if like clients can like take a look at it because we can't really do anything with the Gatsby migration unless that is being settled because the CI is failing. Got it. All right. I'll talk to him about that. Yeah, he's not available for this call right now.

Speaking of Matt, uh he and I had a little bit of a discussion in uh two weeks ago I think it was and uh we were talking about the idea of you know how do we actually validate um requests that uh need to be compliant with the spec. Right? So for instance right now our testing process and this is an oversimplification is basically write some requests by hand run them against GU and see that the response is is what you expect. There is a missing piece of the equation here specific to the requests. Right? So, if

you roll a request by hand and you introduce a bug and GU doesn't recognize it and it still answers back with a response, you've you've kind of missed some some some test coverage, right? Um, so I think the discussion that I'd like to have right now is like how are we actually validating that requests being made to the client are spec compliant?

Mercy, you got your hand up. Go ahead. Yeah. Um so currently I saw the I was working on um a kind of like um a CLI that validates the IO request arguments like against the derived schemas from the open RCB spec itself. So it kind of like raises errors when the structure doesn't match what the spec not we not like relying on get anymore. So it's kind of like something I'm working on. I kind of like I need to share the docs with you so that you can take a look at it. I started that last week. Yeah, that's exactly what I was discuss. It's more like a prevalidation layer. It doesn't like depend on any client. It checks the

spec on what the specs says, not on what get is saying. This is huge. All right. So, I'm going to make a little note here. Mercy is working on a pre-validation is what you called it. Yes. Um can you say a little bit more about where it lives and where it um gets run? Is this being run as part of generating the test like through the test fillers or is this being run on uh as part of the Hive RPC compat tests? Yeah. Okay. the I kind of like

I'm trying to make it a standalone tool for now and then we can gently m after I kind of like build out um um a small part of it we can then migrate to doing the compact or um into hive. Okay, cool. Um it looks like Zayn has a tool already in mind. Oh, posted it. he just posted in the chat here. Oh yeah, this one this one that Zayn linked is more like uh I'd say like an alternative to the hive testing where it's going to hit the like it's going to hit the actual endpoint.

Um, but I think one thing that I see as like a disconnect between the spec and the hive tests is that um, for example, this test coverage tool would use examples from the spec, right, as the requests instead of having to like I'm sure in some cases you would want to override those and I've done that in a couple projects where I override specific things when I run the test coverage. But yeah, I just want to point out that there is like a discrepancy there still between like we have examples in the spec, but uh we don't use a lot of them in the high hive

tests. like the spec itself has example requests and example responses and then we're kind of duplicating that again into hive in in some cases right so okay sorry I don't really understand like does this particular to like does it like passes the io test files from the execution API and then validates only the request portion like against the JSON schema are derived from the open RSC specification.

Like I said, this this is different from the Hive tooling and these io files, right? It uses the example requests and responses that are inside the open RPC spec itself. So yeah, I just wanted to point out that there's a discrepancy right now where we have examples in the execution APIs, right? There's tons of them in there and they're great, but we don't actually use those or test them or anything. We have this separate hive.io files that we may or may not, you know, generate from the spec, but Sorry, I've got a very clicky keyboard,

but I'm just making some notes here. That is a That is a That is kind of a disconnect that Yeah. Um I highlighted on the agenda, right? Like is this a feature or a bug when when you sit down to write a test? I would assume that you would you would want that to be validated structurally against the spec right off the bat. Does anyone have any arguments against that?

That makes sense to me. And that sounds like what Mercy's already built or working on, right? I mean it's the you know you produce requests and then whatever JSON you know that you would send to a client like you're validating those requests match the spec you know based on this you know whatever you it's the right number of parameters and they're hex strings prefix hex strings or booleans or whatever they are and that's the idea right yeah and I think it's as simple I think it's as simple as running the uh you know the first line of the IO files through a JSON schema or the spec validator, whatever, whatever this thing is that manifest to make sure that you're you're

in compliance, right? Yeah. And then one step further from that would be to generate well this is I guess this one step like you know kind of do like a fuzzing where like against an actual endpoint where you generate real and fake data and that maybe that's more what um the open RPC test coverage thing is where is that is that what it's doing? Is it just testing to verify that? So I I think well what the open RPC test coverage does is think of it as like instead of this hive thing right we already have requests and responses in the spec itself so it just runs over there makes a request does it get the same response and then there's things like uh you can make it a bit

like you said a bit more fuzzy where it's like okay it doesn't have to match exactly but what if it matches the schema that you get back right or maybe the request matches that or whatever Okay. Um, but I think the I think to it's fine if we keep the like Hive and io stuff. I think that stuff is good. But I I think I'm just pointing out that there is a little gap that I think we can close with a bit of tooling there which is um maybe this exists already. Maybe I missed it but uh would be like have something that just rips through looks at the example requests and responses that are in the spec already and then generate io files you know instead of writing them by

hand. I'm sure like will obviously want to write some by hand but I just Okay. Right. Sorry. Um the io files are not written by hand. They are like autos generated from the generator. Go file. Yeah. Okay. And file they're not written by hand. You generate it from the RPC test gener. And then you kind of like the two repo talk to I think they kind of like have a communication link. They talk to each other cuz whatever test you're writing on the generator go from the rpc test gener you kind of like generates a files. You don't you don't impute it by

hand. It's automatically generated. It uses this command. Um let me get the com. Okay. So is it is it generated now from does that use the spec to generate it like it does use the examples today or I thought you were saying you had to I thought at the beginning we were saying we had to write these um IO files, right? No, we don't like write it like the way we normally write. You don't manually do it. It's autogenerated from the code you've written. Yeah. Okay. So, can you link to like some example test in that's

in Go? Yeah. It's in it's in the execution APIs thing. This is a this is a step of the process that we call test filling, right? And essentially what it means is that you you set up a client like GE, you import a blockchain and then you run some tests, some Go code like what Mercy has linked to here. And that code generates the requests and executes them against the client and then saves the response and that's your IO file. Did I did I describe that accurately, Mercy?

Yes. Yes. Okay. Okay. Um, so yeah, I think like I said, we could do something that, you know, similar to this where we could also look through the existing examples that we have, right? And generate IO stuff from that, right? so that we could we can close the gap on whatever examples we're seeing. Or if if we don't want that particular example, then at least we can kind of like document that.

Yeah, I think that makes sense. I mean, you could take uh the Go code right there has the request baked into it somehow, right? like it knows what you what parameters you need to provide to the call being tested in order to get a response. Um, and so maybe we get those from the examples instead I guess what's what's the argument for changing that? I'm not saying change anything. I'm just saying in addition to all of our existing IO files, it would be great to like make use out of the stuff that we have in the execution APIs specs already, right? Which is we have some examples in there. If those are useful,

we should we should try and use them. That's all I'm saying. Yeah, I I think that's that's kind of what we're trying to figure out is how are they useful? And today they're not necessarily useful in our um our testing pipeline. So we would have to change that testing pipeline to make them useful. Right. Okay. Uh so maybe yeah maybe we can work on the testing pipeline like for example like we could do the same thing with IO and not have to write like this execution APIs tests ETH

estimate gas, right? Like we know how to call ETH estimate gas. we have a whole thing on and we know every method that we should be calling, right? Like there's like obviously some tooling improvements we can do here where we don't have to write like if you add a new method to the spec, you shouldn't have to add a new test, right? Like we know how to call that's why we speced it out. Right. Right. Right. So I don't I don't know how we get there from here. I'm just saying that the that that there's lots of improvements uh to made there. Maybe not just the examples,

right? And just to recap just to make sure that I have everything like clear myself. Um so currently RPC test gen is used to then generate the io files that then get merged into the execution APIs and then that becomes the way that you go about testing the spec and the step that you're suggesting that is missing is that um maybe sometimes the request that comes from RPC test gen doesn't actually validate against the uh spec itself. So like RPC test gen sometimes may not be calling the might not be in adherence to

the spec itself. That's okay. Let me just um I think there's kind of like a mision or misunderstanding on what the problem is. So the issue we have here is that the test contributors currently depend on running their io files against get. So to discover any form of malformed request. So this like introduces a kind of like everything has to be on get if says like we need to wait on get in order to run any test. You can't like do it stand as a standalone um run. So like we we

want to like reconnect test generation to the spec itself not to clients like not to make it based on a particular specific client by validating the request structure directly using schema derived from open RSC YML. I don't what I'm saying is making sense. It it does it does and that's that's kind of a known issue. I think we can keep things a little bit more narrower and and just focus on making sure that the requests actually are covered by the spec because I think that's that's the one thing that's clearly a miss right now, right?

Because you could still make an argument that like well GU is the reference implementation and so you know whether or not it is a requirement for creating new uh RPC calls and validating them and testing them is is still potentially up for debate. I think I I agree. I personally think that it it shouldn't be. Um but there's there's arguments either way. Okay, so this is good. So we have some action items here. Um, we're going to take a look at the RPC test gen. We're going to figure out, okay, where does

the requests come from? How are they generated? Is it would it make more sense to draw them from the actual examples in the spec? and then also execute you know spec validation against what is generated. Yeah, just just looking at any like I said I think the IO stuff we have in there is okay. I think we could maybe close some gaps with how we're like generating these on the RPC test gen side.

I need to look into that repo a little bit more on on yeah the Golang side of how they're generated. But um yeah, I think I think this is actually like a good uh pipeline of like ending up with the the io files because in if we were just doing let's say like using a test coverage tool, it it would basically just give you like whether or not it was valid when you're like calling GU, which is great, but uh this like pipeline where we have the IO profiles after uh it's just like obviously a lot more flexible,

right? Um because you can run it in like two stages. So I think that's pretty cool. And then yeah, it would be great to see how we can leverage more of what we have in the spec to to help the tooling along. That's okay. That's my summary. Awesome. Awesome. Awesome. Awesome. Mercy, does this align with what you were talking about earlier? um what you were what you were working on. Yeah. Yes. Okay. Okay. I like the sounds of this. So what we could do then is would would would it make sense for us to open an issue against the execution API repo collect these thoughts, right?

and then maybe just put a couple of, you know, put an outline in an issue that says, "Hey, here's where we think we want to adjust this pipeline to incorporate validation of the um Open RPC specs for it." I think that would give us a very clear, it's almost like an engineering notebook that says, "Hey, here's the problem that we're going to solve. Here's where in the code we think we need to update it, and here's what it's going to buy us." And then that could be a thing that we discuss more broadly in the community. Does that make sense?

Yeah, it does. Would Mercy and Shane, would you two mind, you know, maybe pairing on something like that and then opening that against the repo and then I can run it by Matt and the rest of the community? Okay. Yeah, I'm gonna dive into this RPC test gen repo and see um yeah, just see where we can we can make some Yeah, because I'm looking I'm looking at that generators go file. So, I think I think we can come up with something that helps us ma manage that over time. I don't know if you saw it was like it's a crazy file. Yeah. Yeah. And it's the co

the code is crazy also. Yeah. Yeah. So, yeah, I think yeah, I'm going to look a lot more into this, but yeah, I'm going to think about this and we got to be able to come up with something to to help us cut down on on some of that. Huge. This is huge. Thank you. Thank you so much. Cool. All right. So, we're at the halfway point here. We do have some other things on the agenda here. Um, I want to move on to uh our style guide.

I like to have a regular conversation about what goes into a style guide for new developers and um what what is the guidance that we can give them and how do we express that guidance in the spec itself. one of the problems that we have you know I think there there's a little bit of inconsistency throughout the RPC itself as to how you handle some things. We've talked about error reporting in the past. Um folks have opened up suggestions for grouping the errors. Um we have talked a lot about being agnostic on the messaging for errors etc etc. Um those are aspects of API design

that we need to put a narrative around and include in the documentation for developers to use. Uh one thing that I have discovered is the way that we handle search results. Okay, sometimes you return a 200 um specifically empty search results. I'm sorry, I should clarify that. So, if you make an API call that's essentially a search and nothing is found, um, is it a 200 with a null response? Is it a 200 with an empty array response? Or is it a, uh, open RPC minus 3200 not found? Okay, these are all different ways to do that. And I

think that there is probably some editorial advice we can give people as to why you would use one or another. Uh my question to the group though is what is the best way to find these inconsistencies across the spec and then try to align them? Simpson, I see you piped in in the um in the chat. Would you like to say more? Um no, whatever you said is exactly right. We've noticed uh different clients different chain uh returning all sorts of uh uh formats for these search results and uh the clients or or the downstreaming apps have to do multiple validations logic to get around that. So

yeah, it would be great to get that also standardized. It's just agreeing with your point. Okay, cool. Thank you. Does anyone have any suggestions on how we can find all of these places where this is an issue? Is it possible to like um extend Hive to write a script that loads the result adjusted then from the test output matches return format against um known good expectation actually and like we all of our tests right now

are successes right we don't have any error tests or did you add some on on the do we add that in your PR for error codes yet or um not the test yet uh but I've been meaning to Yeah, I think that's something we should look at is like seeing how we can adapt RPC test gen and Hive to to deal with errors. Maybe Hive already does, but it doesn't seem like we do much in our current RPC test gen for that right now.

So, what's what's curious though is that an empty search is not necessarily an error. Like in some cases it may be handled as an error. Um the question is is that correct? Right? Um and how do we find these these discrepancies? Because I think what we want to do is we want to get to a world where we say here's the guidance on how to you know respond to a search and in some cases a null is appropriate in other cases an empty list is appropriate and in other cases it is in fact an error state because the thing that you were looking for should be there and that's a problem like if I'm looking for you know a block that I know has been

finalized right um that could that could be a that maybe that should be more extreme of a response than an empty array or null. Yeah. Do we have like um an something that is like a lint um tool? That would be nice cuz it's if we have something that works as an RPC response l to that when we run the tool we kind of like have um when we run the um IO test cases for example then we pass the results flag methods that return

inconsistency result for empty states eg I don't know just thinking out loud though yeah okay so a llinter got it I I guess well I guess conceptually like I guess the the real question is uh at what point does the client decide to like draw the line and at what point does the like producer like communicate that like you said like given the state of the data you should be getting back um not an empty array. A and so um and in terms of like the final

state block that we were talking about as an example um and the request itself is valid but the data itself is invalid. It's kind of that like tension point that you're talking about. And the question is is how proactive should the the execution APIs or the execution engines be about um telling the user that there's like a potential problem. But I think maybe the thing to do there is unless it's like something that is explicitly an error, it's kind of hard to uh code for consuming application like sort of state issues. So, it's kind of

like maybe internally the client has a bug, but when you like maybe the response is to just always return back the empty array. And then if it's like, hey, look, I thought this should be finalized, but I I'm getting back an empty array, then that's something more on the the dev side that you would consume potentially versus like uh expect that the the client returns back some additional logic about the the internal state that it should be in that has more semantic knowledge.

Yeah. Yeah, and I think that's why we're discussing this in the context of a style guide as opposed to, you know, a spec or a test that actually is going to validate it. I think this this is always going to be a subjective thing and we kind of just need to come to a collective consensus as to how we advise people to to pursue that. Um, I would love to get the automation as close as possible, but there's always going to be some gray area like you're saying, Zayn. Um, Simpson, go ahead. You have your hand up. Um, yeah. Uh maybe my two sense is uh it's a mix of both uh both suggestive and uh and absolute um uh validation for for some of which we already have right uh provision uh for

example let's just take the three scenarios you've mentioned in the uh in the discussion which is null um an error or an empty object sorry empty array or an empty object. Let's consider these four cases for we can we can absolutely say no one should return a null uh because the the downstream client could be anything and um it uh you know it's it's easier to process a value or an object rather than a null or a null or an undefined. Um so we can straight out say the value should never be null or it could either be an object or an array.

there we can probably standardize but um the distinction between or the validation of the array or an object is easy to do because we already have the spec and the spec already expects the response to you know match a type of an array or an object sort of we can already implement that. So like we we take like 70% uncertaintity out of question. Now the the actual style guide will come in where we have to say hey when do you want to return an error response? When do you want to return an object in an array or sticking to the bad examples response object or bad output response object. Uh I think

that's where our style guide would come in rather than you know um just generically writing style guide for everything which will still lead to possible confusions. Uh but I do definitely agree that we have to standardize the for the error code maybe we can still think about it. Um when we write the uh standardization for error codes probably that would be the base. If we expect uh an error for a particular method that should always return an error instead of an empty object, they can or they can combine both. Um now we have an um extra description object that can be a state a stag or a string or an object whatever

it could be they can return um the return format there on top of the error. uh but I don't want to complicate that there now but at least this way we can solve 75% of the issue by standardizing against the spec and just leaving um when to return an error when to return an object up to the clients to decide by using the style guide. Okay, that's well said. I think I think llinter is an awesome idea. Like I've wanted I've wanted one for like for specs for like a long time. There's a great one in Golang already called

vacuum we can maybe I don't know if use or like take inspiration from but that would be a good place to to start if we wanted to at that. Sorry, you drifted away from the mic there at the end. Shane, you suggested vacuum. There's a Golang project called vacuum that is like a it's an open API winter, but you can use it for other things as well. Uh, so that might be a good place to start if we want to do something relatively quickly.

Um, or maybe take it as inspiration depending on how how deep anyone wants to go on a winter. Cool. Thank you. Okay. Um, got 15 minutes left. I do want to leave some um, Tanwin, are you the person that commented on the issue asking to discuss a new EIP? Oh, yes. Uh, that's me. Great. All right. Thank you for joining. I want to make sure you have some time to um talk about what you want to talk about. So, um

let me just I think I think there are so there's still a few bullet points in the style guide in the PR section of the agenda. Why don't we pause here and we can discuss those things next week if we don't get enough time after we talk about uh what do we got here? ETH send raw transaction sync method. Uh you want to take it away? Yeah, thank you. Yeah. And thank you for like letting me talk on this card like um so uh uh we are like proposing like a new RPC called like if central transaction sync a like an OPC method that combines of like combines the the traditional

central transaction and like pulling receipt uh into a single one to like effectively eliminate uh the need to pull for transactions. So uh in instead of like sending a transaction and then like repeatedly like checking if uh it is executed and there is reced available like uh this obviously enables uh you to get the full result one once you submit the transactions and um we uh like uh we tested this and consistently saw like like uh like 50% like lat uh uh 50% latency like reduction across like different locations.

So u that is a a a a quick summary of the new RPC. So uh may I like share my screen to like getting more into the detail? Yes, you may. Okay. So Oh, why is You know thing is displayed here.

Oh, okay. I need to quick and quit and reopen those. Can I let back in 30 seconds? Yeah. Yeah. Sorry. Just uh like system settings from Mac. Hey. Hi. Okay,

so Yeah, I think uh it is. Yep, we can see your desktop. So, now can can you see the screen? Yep. Yeah. So, so this uh new EIP is called EIP 7 uh 7966 uh like uh to uh introduce a a new like synchronous transaction submission instead of like uh uh the the current traditional synchronous uh like uh flow.

So uh as we develop and uh like uh a quick uh summary about me. So I'm Tang. I'm uh currently a research at rise chain. So this uh uh EIP is like uh newly like recently published and and PR to to to the EIP report by Sam Hai and me and we are we are both like from from Russian. So as we like tested uh uh develop rise and like uh we optimize for for high throughput and and low latency, we see that uh the current like u the the current transaction submission flow

is is not really uh like beneficial to to users because like it requires at least like two round trips uh for to to submit a transaction and and retrieve a a receipt. Uh this could work for like like blockchains with like high block time like Ethereum with 12 second or or maybe other AVM chains with like four or maybe 5 seconds but like modern chains like B me or like base flash blocks like have really low block time and low execution time. So, so uh RBC uh RBC routers become a new botnet and um

becomes uh like the dominant latency factor from end to end uh uh like dominating the end to end time from transaction submission to to rece like instant feedbacks on on on these modern chains once they submit transactions. Um as here we can see like the the traditional like transaction submission and like resist pooling. Uh this inefficiencies like uh may uh is like or like can completely be like eliminatable

uh in in like modern like rise. So we came up with we not actually came up but uh we uh implemented a solution to this uh with like uh like the solution is is pretty simple with like less than 20 lines of code that combines both the the the sand the tradition no like sand draw transaction and the booing receipts into the the RPC handler on on on the note side and and it has like huge impact uh on the like uh the times uh that uh we can save uh for the users on like waiting for for

for the rece. So as we can see that the client or users have have to make like at least two RPC core but uh like after the the transaction is sent it like mostly executed and the result is like nearly or instantly um available after it is received from the sequencer or like producer side. This is because like modern chains like like riseometers that have really high throughput and and their sequencer of producers are optimized for for for processing high uh like throughput and high load of transactions. So this is the wasted time

if we use the traditional async uh like method. So if uh we switch to the the the newly introduced live method, it can be uh like this time is is can be saved and user can can can receive uh feedback from their their transaction almost like uh uh immediately after like one zero trip. Um we also like uh have this uh running around test nest uh like for a few months and we uh we performed a a simple benchmark uh with like four different

like geographic locations that has like different like basic opt to to the the node. So this is measured by uh taking the median of like 200 sequential eth get uh block number uh RPC core to to measure the median time and uh we measure the total time uh it takes to send it submit a transaction and and when the client can retrieve the receipt. So uh the the the new the the newly introduced method like provides a consistent like uh performance with with uh latency is as low as a single uh RBC time. So

this is at uh like this is expected because like we only made one one RPC core and the the processing power at the no side is very small. um compare it against the like the async or the traditional flow it uh the the async uh flow has like almost like two times more latency than than the the the sync method. So we we we can see like over like 50% improvement in latency here. We can uh get this uh implemented.

Um so the the the the EIP is um created and API is open in GitHub. Right here we are like asking for commands and suggestions. We also have like in includes a sample implementation to the uh to to the EIP and the discussion link on on on Ethereum magicians is also included. Uh the the reason why we polished this into an ARP is that because like uh whenever we we introduce a new RPC and this is RPC iss like can benefit like most of user and developers uh but but for user

to like fully utilize this we also need to like implement some sort of like uh wallet uh a new wallet or or something like that. But if it gets like implemented into like different like clients uh implementations or wireless libraries then it it is like much easier for for like other chains I like I heard that like other chains they like don't don't have the this like type of RPC but uh they thought of it but haven't like like had time to implement it. So, so if we can like standardize this kind of RPC and uh and make it like uh fully upstream to to the client

implementations like growth or rollups or like uh like latency optimized chains can like huge uh can hugely benefited from from this and uh yeah I think that's it from my side. Thank you. Uh would you mind posting um a link or a PDF or something for these slides? I'd love to run these by uh people at Infura uh to get their opinions on it if if that's something you'd be okay with. Yeah, that would be like really cool. I I will send their slides in the Discord. Great. Yeah.

Cool. And would love to have like more commands from like node implementers or or like wallet or like library maintainers or something like that. I think would be very cool for us. Yeah, Zane, go ahead. Yeah, cool. Thanks for the presentation. I was kind of curious um what uh this kind of looks like um just even say on like rise network. So if you had like one second block times and you have RPC requests that are like we say in the speed of 240 milliseconds then the total roundtrip time is going

to be still dominated by that one second block time. Is that correct or Yeah. Yeah. That's correct. So, so like when I analyze the total like latency, there are like actually like uh three or four like main factors. So, the first one is like like the time it takes to propagate a transaction from uh the client to the full node and to the block producers. Uh but like for like in general like rollups they are like often advertised um they are like maybe sequencer not the sequencer endpoint but like the sequencers replica endpoint. So it is basically like very close to to the

block producers at that point. But uh we can see that this number is like there there's nothing we can do about this number because like um uh we like the the things we can do about this is like to have our clients like physically like uh like be close to the block research. So that's why we set that number to be the baseline for our like benchmark regarding the block term. So uh uh yeah you you uh you're right that uh the dominating factor is still the block time but uh uh as like many chains are optimized for latency they they have like some sort of like sort sub block

sublock. So like uh like right in rise we have like straps and mega they have like mini blocks or the base they have base they have like flash blocks. So uh they are all like subsecond uh like block times. So they they all like have like subsecond block time. So so as long as we can like reduce the block time into like maybe like uh this obviously is like uh recommended for like like chains that have like less than one 100 millisecond time or something like that and they can all like benefit from this RPC.

And then the proposal would be that like for like G or mainet that the RPC call implementation would be optional. Um because like otherwise if uh users were to hit the synchronous client it seems like a lot of like lingering connection load. Yeah. Yeah. Sure. like yeah sure like for Ethereum like for example like it is like fully optional for for for Ethereum and other chains. So, so this is like if uh you enable this and you like your your network has like really low time.

So, user can really benefit from this. But uh yeah, it is fully uh like optional for for for for nodes to whether like whether they should enable this or not. Well, cool. Thanks, All right, and that brings us to time. Thank you everyone. Uh, very productive meeting. Uh, stay tuned in the Discord.

See you again in two weeks. I'll post a new agenda where we can resume with some of the points that we didn't have a time to get to uh, this week. Uh, as well as there should be an AI summary that comes out and maybe some action items. So, have fun everybody.