RPC Standards #27

Transcript

Keri Clowes: Hello, everyone. Welcome to the RPC Standards Call Number 27. I guess I made the agenda so I can kick us off. Let's see, I wanted to get started with, Dane works for, OpenRPC, and has a bunch of PRs up, Zane, I don't know if you want to walk through them? Or if you, I can…

Zane Starr: Sure, I can, like, walk through them at a high level. I think, I can share screen if that's useful.

Keri Clowes: Sure.

Zane Starr: Okay… Give me a second to pull up the PRs.

Keri Clowes: Sounds good. Yeah, so the context here, is that, OpenRPC is wrapping up a grant, to help us with execution APIs, and so this is kind of the final milestone here. So we're hoping to get this merged, after the meeting today.

Zane Starr: Share, and… desktop tube… Think… here we go. Let's go here. Okay, can everyone see my screen?

Keri Clowes: Yep.

Zane Starr: Okay, cool. So, actually, there are two, sort of, pull requests, so one is… For a linter? Which, like, maybe that's the easiest to start with. So, traditionally, OpenRPC documents have been kind of hard to reason about, like, what's good or sort of bad, with construction of a document. And so, basically, we, within the past couple of months, implemented a end-to-end linter that will tell you whether or not the OpenRPC document, or in this case, it's kind of like the YAML that you generate, has any problems, with it, so… We have a sort of set of recommended rules, and that tells you, sort of, like, how your document should look. So, like, historically, I think there haven't been enough guidelines on, like, what people should do, and, like, how that should look. Actually, I'm gonna just share more of my screen. Let's see…

I'll just go all the way in. Why not? Okay, so we've kind of had this, like, historical issue. So, really. Let's go here… And… let's have a look at the linter. Okay, so this is, like, where the linter… the bulk of the linter code lives. Everything kind of lives here. Within the README, you basically define a basic document that has, like, an extend and says that you want to implement the recommended. There's a list of recommended rules in this default, and then you get an example output that looks kind of like this, but in color. So, basically what this says is, like, what is the method or, in some place, schema components or content descriptions that are within, like, air, so you can locate it.

Then it says, what exactly is the problem? So, in this case, it's this method, which happens to be the first method that we're looking at, and then it says, like. The field is description, and we're just missing a description field. So, within execution APIs, like, summary is, like, overloaded. It should really be description, and that changes the way that different, like, people that view OpenRPC documents, either through, like, our documentation, through DocuSource plugins, or the Markdown generator that we wrote. It just kind of plays with how that works. And so right now, summary within Execution APIs is, like. 4,000, 5,000 characters. It should really be, like, 120. And then description should be where you put your 5,000, character, tone.

So that's just, like, one of those things. Other things are about uniqueness. So… There's this ability to say whether or not a field is missing. So, for error codes or something like that, it could be something like every method should have an error. That could be a thing that you want to define, or every method should have examples, which I think is one of our default rules, which will throw a warning. And so that gives you that kind of functionality, and probably the thing that we wanted to do is, like, enable you as spec maintainers to be able to define how you want your own spec to evolve. So, we have this ability to define, schema.

So you can define your own rules to add, to the, Rulebook, so you could have a method name schema, so to prevent people from putting in, non-snake-cased or non-camel-cased, method names, you could do that. You could do things like, oh, we want method names to be less than 50 characters, you want, like, a parameter count limit. And so you can do all of these things with, a schema rule, and then there's kind of this third rule, which is kind of uniqueness. And so these are just, like, backing technologies to sort of… or backing, like, primitives, through specifying, like. what primitive you want to use to enable you to validate or lynch your document. So… for instance, Ethereum doesn't quite use this, prop… well, within the JSON RPC APIs, but there is ability to have key-value pairs for parameter names versus arrays.

And so, you can do this, where you say, like, the name of the method should be unique. per every param. So, you have this scale of being able to do something that's locally unique, or globally unique. So this is, like, global uniqueness, and this is, like, per method uniqueness. And so this scope allows you to say whether or not a thing should be, unique. So… Jumping back… we can go into rules, and defaults, and recommended. So, here's a list of, I think, 25 or 28, recommended rules that we put together. And then these, like, so, method names, examples, area codes, etc. I'll spare you the details, and we'll look at the PR. So, essentially, the changes that go into the repo are to actually just use the linter. So, we have this nice little make command for lint, so you would call make lint, and this would help you lint the OpenRPC document.

And then here are the rules that are added, and this is what linting looks like. You go here, you add this to the GoTools, And then you call lint. This is the OpenRPC document that, Linting works on reference documents as well as dereference documents, it doesn't really matter, so you don't have to use the assembled spec for this, you can just use the refs. And then here you specify the lint rule. Here are the lint rules that we have. So, method errors, we changed these severity to warn, so you can override any of the rules that are annoying you, so… In this case, there are a lot of issues where there aren't example descriptions, or error descriptions, or in schema descriptions, but we didn't want this to be disruptive to your current workflow, so we kind of minimized the amount of, like, warnings that you see, so I think…

With all of these warnings turned to ignore or turned off, you end up with something like 34 warnings that you can then, like, pick and choose and slowly kind of go through the methods and… make things better. So, that's the entirety of the OpenRPC lent. ARC, does anyone have any sort of questions about that, or, things that they would like clarified? Okay. So, that's, like, the linting PR, and then sort of the bigger PR, that we're doing. Is the, tag-driven release pipeline for version docs and spec. So, Felix, a while back.

Came to us about a sort of problem within, execution APIs, and I think Carrie has been working on, a versioning spec, so… Basically, it would always be super great if the execution APIs had versions, right? And this would allow downstream consumers to reliably know what is within what version of the OpenRPC document? And it's just, like, a generally nice thing to have, so if you're doing tests, and say that, like, you know that there's gonna be A hard fork coming up, and then you can tie that hard fork to whatever version, that you have. So, essentially what we did… Was to come up with a way to… track the, sort of, GAF release process, which is a manual release, so Felix or Carrie or someone can

Create a release through the GitHub Pages release, then… Go about, sort of. describing all the changes that are going to be in the release, and then tag it, and then have that release show up in documents. So, it's a little bit difficult to view from this PR, but I can give you a quick sample by going to one of the pages that we did. So, if you'll look at, this, sort of setup. You'll see here, you have the execution APIs, you have the docs, and you have this thing called releases, and these are just gonna be the release notes for every release that you had, in the past. And then you now have this other sort of feature, which is to be able to switch between the different versions of the release.

So this will go back 10 different versions of the pass. So when, say, you cut a new release, and you're in version, like, V8, you can then drill into these methods, and then say, oh, actually, I want to know what's, like. currently the latest release, and then you can switch, and this actually switches the version that you're in. There's a little affordance to let you know where you are in space. And then sort of the other final sort of thing is to think about, like, what's in, like, main, right? Or what's in the next upcoming release, because often as developers, we're kind of looking forward as, like, features get merged in and changes, even though they're not tagged in the release.

So… Basically, what we needed to do was create a way for changes that got merged into main to then update the docs, and kind of land in this next version. So, this is somewhat more complicated, because, as you know, right now, let me just duplicate this… You have this ability to, keep track of different versions. So, we have this page here called Assembled Spec, and maybe some of you aren't totally familiar with this, but Assembled Spec is how downstream consumers tend to actually consume the OpenRPC, like, API docs. So, Flashbots is using this, I think MetaMask uses this, I think, Infura uses this. And so, the assembled OpenRPC.json Is, like, sort of a canonical reference of whatever is…

And all those YAML files. And this makes it, like, easily downloadable or consumable from, like, sort of third parties. So they'll go, and they'll download refs openrpc.json. So, one of the things that, like, happens right now, if we go here… Do… Info. Alright. So, this right here is what we're talking about changing versions. So, the change that we've put in is actually going to overwrite the version that gets produced here. within the execution APIs. Version is actually not set in any of the YAMLs, it's generated by the Go tools within, I think SpecCheck or SpecGen. With the recent, sort of, refactoring that happened within the repo. So… For, changes going forward.

we have multiple branches that are going to be created. So one is the assembled spec branch, which is going to now have versioning here. So this will be version 0.1.0, or whatever the version is that you tagged the release. And so we went with this sort of Golang prefix of V, X.x.x as the tag release, and then the release within the refsopenRPC.json, with major-minor, patch. Just gets the V stripped off, and you are left with the three semantic sort of digits, which is kind of in line with the ecosystem of OpenRPC. Okay, so, we said that we had this assembled spec. But this presents a sort of problem. Because, we have this next release, right? And so developers also need access to the assembled spec that's just in main, and so we've created an additional branch called assembled spec-main. And so, if you look…

I'll go back to this, sort of… Place where we've been playing a lot with how the release works and testing that, like. Things do seem, behaviors, You can go here, and you'll look at this, branch. assembled spec, and assembled spec main. And assembled spec main is just, the same sort of, main branch that you saw from, Back in the day, where it's just, like, no version, it's just 0.0.0. And then if you look at assembled spec, cool. And… Draw… You'll see that there's this version. Right there. And so that means that, you know, versioning flows as you would expect, which is also tagged before release.

So I'm trying to show you all of the artifacts first, so that way things make a lot more sense as we, like, look at the PR quickly. So… Here is, like, an example of a release. So this is, like, the first minor release. You can do this however you want to fill it out. You can do the generate spec notes, and that will fill these things in. And you'll see that there are 3 different assets here. So… or 5 different assets. So you've got your code. And then you've got the OpenRPC.json document, the refsopenRPC.json, that's also associated with the release, and then you'll see this doc snapshot. So… One of the kind of challenges, with documentation is that

if you can recall, the way that things work in the current release is, you have this DOTS API, and this has a bunch of, API documentation, things that are kind of generated. Initially, we put these in the build because we were thinking, we'll only have one. It's good for non-technical folks to be able to see what the markdown looks like that's generated. So if they want to be able to. Do some technical writing, or some improvements on the style, and something that's not fully out of reach to talk with developers and everyone and coordinate and make happen. But, because now we have multiple versions, what we've done is actually evict the API from… the generation, so all of this generation is hidden, and we need to be able to track multiple versions so we don't have to build, so this becomes cached. So we have a cache of all of the different API versions, and the way the cache works is that we use releases as the cache.

So, that's what the docs snapshot is. It's a snapshot of the docs, so that way, within the GitHub Actions, or within CI, we can just download the released version, and then we go on about our business. And we copy it into the right canonical docuseries, like, format. So, underneath the hood, this is all just vanilla DocuSaurus. There's nothing funny or, crazy about it. It does all of the DocuSaurus things, and essentially what we've done in between is make a little bit of tooling… To make the process, like, seamless from being able to get a release, and being able to, tag it, and then have that appear in the build. One sort of side effect of being able to have,

Let's go back to the website… yeah, one side effect of being able to have Next and this. is that… Let's say that you tag a release. You tag the release, and, you do the deploy. that tagged release is going to still have the same SHA as what was deployed with Next, and unfortunately, the GitHub cache will, like, not invalidate, and there's no way to force a CDN cache invalidation on the same SHA 1. So, one of the things that is also kind of a side effect of doing manual releases versus something like Nope. Is that you need to find a way of getting these release notes, let's go… Here… You need to find a way to get the release notes, into… yeah, getting these release notes into the repo. So, if you were gonna go to…

Execution, APIs… And then… yeah. So, like, all of this is not in the repo, but what we do… is after you tag a release, is that there is a GitHub Actions bot that will ask to make a pull request into the repo to add it into the releases space. So, if you go here to… The releases space… docs releases… all of the releases and release notes are going to be live on whatever version of the API that you're looking at. It's out-of-band, and this out-of-band pull request also serves to help invalidate the cache. Because the cache invalidation could happen a week, or 3 weeks from whenever GitHub updates it. And so you're not really in control of the cache validation, except through commits. So, essentially, this is an automated commit.

That then, basically takes the markdown that was in your physically written release notes, slugs it properly, puts it in the correct sidebar position because you want to order your releases by version, and then, Like, does the right thing. And then I think if you look at the PR request, you'll see, like, the notes that it makes within it, Might have a bunch of auto-closed ones, but this is an example of the automated notes, so… GitHub Actions Bot tells you the source, and then after this PR is merged, it'll talk about no need to republish the GitHub release, and then it says why it does it. Right. Well, not why it does it, but… what happens by merging this. So if you can't… you were to tag a release, and you didn't see an update, but you hadn't merged this PR, it's like an affordance to kind of tell you, like, merge this PR. Which you should be doing anyways, because release notes should exist on the site.

Okay, so I think that is, like, the high-level overview of changes. One of the other changes, that… also exists, in this is the change to tags. So, there was a request that there's an ability to kind of do a bit of a grouping for how the APIs work. And so, basically, what we wanted to do, was add the ability to have, tags. So here, you'll see that you can add a tag to a method, and then if you scroll from the main methods, you'll be able to access tags, and if you're on the method itself, you can see other tags. And the release that we have, this goes away. It's just, like, an artifact of this example.

But you'll see that we have these two that are with the execute tag, and then you can say EF estimateGas. And you'll see that, oh, I want to see what else is in this same category of functions. So, I believe there's been a lot of talk about grouping the different methods by functionality, and so tags is, like, a convenient way to, like, sort of do that. Other things… yeah. So, I think now that's, like, all the context you need to be able to understand, like, why everything is what it is, and then, like, what is this, like, sort of PR. Workflows are introduced to GitHub Actions, we talked about the SHA-1. There's no way to automate that, we talked about that. And then, basically, a lot of this are, GitHub Action workflows. So, the easiest way to, like, sort of go over what happens with the workflows is to see them.

So we have a deep amount of, sort of, documentation on it? If I go back… One more here. Closer tools… I think this one's just as good. So… no. It's the wrong one. Our main… I think… Different branch… Oopsie Winter… Maybe this… Alright. I'll go here. There's been a couple of different, sort of, like, branches, because we have a couple of changes going on, so it's a little bit difficult to, sort of, organize. But here's, like, sort of the way that the release pipeline works. It's just hard to see it because it's split in between so many different YAMLs. So we have, the release YAML, which is kind of like, oh, I tagged a release.

Full release is, like, the build, there's the version snapshot, a pages deploy, a GitHub release, and timestamp, so… Here, essentially, you push this tag. It goes to this build release YAML, which goes through deploy pages, and to GitHub Pages, which calls this GitHub release, which also does, a few of the artifacts. So this is, like, take a snapshot of the documents. with our new version, do this GitHub release process, which is, GitHub release. And this is just showing, like, if you were to do the next, you hadn't done a tag, then it goes through here. But here you have this build release, which is the GitHub release, and then, the published spec. Which is going to do the push to the assembled spec branch with the proper version. This has got the GitHub release for doing the

Release notes, so this takes, the release. from the GitHub page… from the GitHub releaser, and then converts that into Markdown, and then makes the PR to put this into the docs release. And then… This is essentially the whole flow of everything and how it works. And then you also have the ability to do some manual dispatch if for some reason you need to, like. not go through a tag push, but you have your own tag you want to release. I don't know. Up to you. So, you can also see it just going from left to right, which is a little bit easier. So, push tag, release YAML, assembled spec gets released. Here's the GitHub release. We actually have to download all the previous releases.

Then we have to assemble the versions, and so assembling the versions. basically does a bunch of the GitHub stuff, that you saw around the ordering, so, like, next sits at the top, then it's semantic release versioning on, and that produces the API versions, and then you get to deploy YAML, and this is how you do GitHub pages releases, and then… After that, you also have this, push to assembled spec main, which is to take all of the stuff that you were just releasing, and then also release that into the, like, next branch. For consumers to just download, whatever is the latest in the repo as an assembled spec. And then you can see here is the deploy next landing. So… and then this is the flow for just pushing into main. So anytime you move into main, it goes here, to the deploy YAML, to the pages to the assembled spec.

And then there's a little bit of a runbook for how you go about, like, doing all of the stuff. Or if something fails. Yep.

Keri Clowes: I'm gonna make sure that we get to the rest of the agenda, too.

Zane Starr: Yeah.

Keri Clowes: I think this stuff is mostly just for, maintainers. Is there anything else that, That you want to make sure that we go over?

Zane Starr: No! That's just the general flow. If you wanted to look deeply at the code, it's here. I think you have enough information to orient yourself as to what is actually happening. If anyone has any questions, just let me know. I'm happy to answer them. Yeah.

Keri Clowes: Awesome, thank you so much, it looks great. Does anyone have any questions or clarifications? on this stuff.

Zane Starr: Okay, yeah, thanks.

Keri Clowes: Cool, thank you so much. I wanted to also take this moment to hijack, conversation around, versioning, too. I think, the Execution APIs repo has a version… I think it's, like, 1… or 0. 1, let me just pull it up real fast. It's 1.0 Beta 4. I'd like to, I think, tag it soon, and I'm sort of inclined to do a Beta 5. The last release was April 19th, 2024. And then we can also… I can update Hive to run, like, the tagged version, and we can see how that goes for a little bit. I think it makes sense to, maybe once Glamsterdam is released, to do the V1.0. release. I'm not sure how much sense it makes to do it, like, to do major versions in lockstep with,

the… Hard forks? But open to opinions on that, if anyone has any opinions.

Zane Starr: Here's a thought that, like, floated a while back, is that… Actually, for methods that you introduce per hard fork, you could also tag those methods with a hard fork tag, in tags, and then that gives you the ability to know what methods were introduced and what release, That's… that's just, like, one… A little affordance that can be given.

Keri Clowes: Yeah, that'll be awesome. To have, that's a great idea. Okay, so I'll plan, I guess, to release 1.0 Beta 5 sometime this week, and make the appropriate updates, unless there's any Any objections? Cool, let's move on to the next agenda item. Manuel, that's you, I think?

Manuel Arto: Yeah, yes, it's me. I don't know if I will need to share my screen, but maybe… I'll do it. Okay, I think you can all see it. Okay, so my topic was… is about the block param requirements for all ATH methods, specifically about state methods, and during some… some functional tests we had on Nethermind, we found out that right now, all state methods on specs require the… the block param. And right now, in the five different execution layers, we have Nethermind and also ARF, which have this default to latest behavior, so whenever a block is submitted, they…

They lend it to latest, while the other execution clients rejected correctly matching the current spec. So we did an internal review, and some of us evaluated this… the full-to-latist behavior more as a feature than a bug. And also, I found out that right now we have a little inconsistency in specs, because, for example, for other ETH metals, like coal, or estimate gas, or also simulate V1, we have a specifically required false behavior, and also a description to too latest. So my proposal is… about, changing this… this behavior in all the five stat… state APH methods to relax these requirements block… about block patterns, and… and enforce this latest… default to latest behavior. I also chatted a little bit with Chase on the… on the Discord channel, and of course, this is,

This is only the first approach, because we would need to add also some IV tests to specifically verify that all clients are accordingly behave with this default to latest behavior. But this is, of course, will be on a second, second round. So… Just rapidly go to the changes. we… we replaced all the requirement true to false, adding this description, and I also found out that they are all referring to the same… to the same schema. So, I think that for… for consistency, it would be better to have this default to latest behavior also on the state methods, because we already all agreed On this behavior for other ATH metals. And I just wanted to know what… what do you think about this?

Chase Wright: So… I think you already know where I stand. I think it's fine. I probably lean on the encourage Side of, this is probably a good change. But I'd like to hear from the other client devs, and a lot of them are not on this call. I know, like, Tulio, you're here from Erigon, Would this be a change that you guys would support?

Tullio Canepa: Yeah, I need to take a deeper look, but… Yeah, I mean, in terms of implications, but, Generally speaking, I'm in favor of it. It seems reasonable.

Chase Wright: Yeah. I just… so, like, from the standards perspective, like, I think the PR is okay, but I wouldn't want to merge it until… the other clients give a thumbs up, right? So, like… If Erigon's willing to give a thumbs up to the… to the PR, and, like, reference an issue that says they're gonna fix it, and then I can talk to, like, Cena and Felix and the Geth team, and see if they'll give it a thumbs up, then… then I don't have a problem moving forward with it. I just… I don't want to make that unilateral decision, though, right?

Tullio Canepa: Yeah, sounds good.

Manuel Arto: Yeah, for me, for me too. That sounds good.

Keri Clowes: Awesome. Thanks, Al. Okay, Mercy, I think you're…

Mercy Boma Naps-Nkari: Yeah, so the thing is, it's about the, the two PRs I pointed out. One has to do with the bumping the version, and then the other one has to do it… The other one, I think it's not ready, because I have a question for Sina, and he hasn't, like, replied yet. And then I have another question on, debug execution witness, so I tried… speaking from the, the metrics we did, review, the HACMD, about some method that is not yet specified, and that is not yet expect. So, on debug execution Witness, I saw that, like, across clients, we have, like, no agreements on what the wire shape should look like. For example, in GET, GET uses an adjacent header, and then it leaves the key empty. Y Red, on the other hand, RET's never mind, and I think Erigon also.

defaults use, the RLP bytes, and then They, populates the keys, sort of. And also, get and read still, like, exposes, like, a separate, by hash method, if I could remember correctly. So, I'm trying to understand which of these should be specced, like, how do we go about this? And then, on a smaller call, do we want to mandate sort and do… State code, and then a standard error code for when the state isn't available to generate the witness. And also, to adopt, RET, optional… mode and param, or we should drop it. So, that's, like, my question on, the Borg Execution Witness. Then, the other PR, I was… It's about the versioning, and then the, then that was an issue for Nethermind. I think… Yeah, he's here.

We were discussing this last week. We were unable to, like, properly look through it last week, so I think, he can take over and walk through us.

Stavros Vlachakis: Otherwise we…

Tullio Canepa: Okay, sorry.

Stavros Vlachakis: Sorry, sorry. I don't know if you have any updates concerning the issue, never mind about the discrepancy we have found concerning messages and codes?

Mercy Boma Naps-Nkari: Sorry, is that your question? I didn't get it.

Stavros Vlachakis: Yeah, yeah. Basically, I asked if you have any updates concerning the issue that you have posted there from Nethermind, which is carrying over from the previous call, concerning discrepancies and messages and codes, error messages and error codes.

Mercy Boma Naps-Nkari: Not really from Besu.

Stavros Vlachakis: Okay, so it carries over to the next call, or what?

Mercy Boma Naps-Nkari: So I'm not really sure how we're going to move forward, so that's why I brought it back. do we… do we take this to ACDE, or we can, like, put it on the channel? the execution Dev Channel on Discord.

Stavros Vlachakis: I would say par nous… as you… Preferred, but in any case, we need to… fix the issues, I mean, agree on some guidelines concerning Codes and concerning messages, and cases that hit them, and… Have them documented so those… all the clients will tell the same thing.

Mercy Boma Naps-Nkari: So, like, is it just Besu that is the problem? Because I'm trying to, like, really…

Stavros Vlachakis: Sorry, didn't blab you?

Mercy Boma Naps-Nkari: So I was asking… you specifically asked for Besu, like, I was asking, is it Besu that is just the client that is not in line with all this?

Stavros Vlachakis: Yeah, basically, I think guess, in some cases, is very generic. And the question is, do we want to remain as generic, or we want to have the real codes that you have in guest prop, populating properly, because it looks like in this issue, which has, I don't remember how many, 18 cases. Some cases were meant to throw another code, but because GET is behaving generically, It's just returning, you know. The generic error code, which has the same on 5 tests. So, we need the coordination. If we decide generic, okay, fine, generic, but let's… Make it clear. On the spec.

Mercy Boma Naps-Nkari: Okay, on then, on this note, I think it's not really something we can make a decision on in this call, because most of the client teams are not here. that we can take this to the Discord channel, and… or maybe the ACD call. a CDE call. I don't know when the next one will be. If that's okay, then I can do that.

Stavros Vlachakis: It's fine for me, the only thing is that I don't know how much important this is for… to discuss on ECD, but whatever you think, it's better.

Mercy Boma Naps-Nkari: The reason why I said we should defy it to ACDE is that the clients that can make this decision on whether we want it generic or not, they barely attend this call, so… or I can make a post, or you can make a post on Discord, on… on the execution Dev channel. That would kind of, like, be the quickest, way around it.

Stavros Vlachakis: Yeah, maybe that's more reasonable before taking it to the call, I guess.

Mercy Boma Naps-Nkari: Okay, alright then. So I, I should leave it to that. Thank you. So, another PRI I wanted a review on is this one. Because I think this is also blocking one of Sina's PR.

Zane Starr: It's the, OpenRPC version bump, is that the one? Oh, okay, cool. Yeah, so, I took a look at it, it overall looks good. There is, like, a difference, so, like. In your PR, you remove the external refs. And I wouldn't recommend doing that, because that will… stop any sort of validation for JSON schema itself. And so the way to go about that is, like, many years ago, JSONSchema.org was not 100% stable that it was gonna, like, last. That's kind of changed, and so we've had a lot of internal talks about whether or not we should at OpenRPC, do an internal bump. But regardless of that, the fix is I made a PR to your PR.

Which basically, instead of removes external refs, just replaces it with the canonical, version ref, and so this does, like, a couple different things. So, in this case, the scope is just going to be limited to the validation of the documents, but, Pretty much so. Most JSON schema libraries will then reference the draft URL path to then have an internal cache. So, with, the JSON Takuma, like, library, it does that. So, you'll see that I replaced the paths that were problematic, where we had, like. meta. Schema…json dash schema.tools. as the path for the spec reference resolving, to be just replaced with, draft. And so.

If that change looks good to you, then, like, to merge that in. The other thing I noticed about the PR was that there's, like, Webpack, override for 5.0.61. I couldn't see why that would be necessary. So I removed that, everything seemed to work. But, if for some reason you need the webpack, add it back. And then otherwise, I think everything looks good, and then I did another audit over the production of the new, sort of, library to use, which is not metaschema.go anymore, it's now SpecTypes. And the Go package looks right to me now, and, like, does the right things. Alright, so, does that clarify things?

Mercy Boma Naps-Nkari: Yeah, thank you. So, moving on to the next one is, this… I think this PR is sort of, like, long overdue, and then I feel it's good to go in. So, Chase, I don't know if you have anything to say in regards to this.

Chase Wright: This is, ETH Capabilities?

Mercy Boma Naps-Nkari: Yes.

Chase Wright: yeah, I don't know if… I don't think Felix ever kicked off the… CICD pipeline, though, so… There's no, like, green CI on it, I think we just need to get… That, as a double check.

Keri Clowes: I think I can kick it up.

Chase Wright: Alright. As long as the CICD passes, I don't have a problem merging it. It looks like the other clients are, Doing it.

Mercy Boma Naps-Nkari: Yeah, the CI is running now, so that's… I think that's all from me. then the… I don't know about the questions I asked about, the debug witness. Method.

Tullio Canepa: Yeah, I have something to say about that. Thanks for raising the question, because, currently in, in Erigon. I'm working, also on Silcore, which is our approver implementation, and so I'm exactly seeing the issue from both parts of debug execution witness, let's say, on the serving side and the consuming side of the API, and I've exactly experimented what you have pointed out, which there are differences between… among gas. Reth, Erigon, they have different implementations, JSONs versus, RLP for some fields, then other fields are, not the same, or Geth doesn't, By, by default, doesn't return

keys or pre-images, so there are different things definitely to discuss for this API. And so, yeah, I would say… I think we… We should try to, Okay, first of all, discuss… a good direction, but I think, Chase, sorry for pointing you out, but I think you could be the right person to discuss with Kev, because there is a dedicated working group on this thing, on the ZKEVM group side, so I think… There is some discussion to be done regarding which direction is… should be taken. In order to… Let's see, fix. these discrepancies.

Chase Wright: Is there, like, a meeting I can join or something?

Tullio Canepa: Oh, bruh. Okay, I…

Chase Wright: I don't know.

Tullio Canepa: I think there are some working groups. I'm… I'm not personally attending them, because it's Somnath who goes to that for Erigon. But, yeah, what I wanted to say is that there is a dedicated effort within the EF regarding the ZK EVM and the provers and all that stuff, and as it is in the case. for the engine API, also this debug execution witness, it's not just an API that, Ethereum clients serve to customers, but it's used by another, piece, another component of the base layer, let's say, at least in the near future, so I think it deserves a more broader… broader discussion. That's not related only to the RPC standard, but must involve also

ZK EVM group, CAV, and other groups within DF.

Keri Clowes: Alright. Sounds good. Does anyone have anything else that they want to talk about? In the last 5 minutes, floor math. Alright, I think we can call it. Thanks, everyone.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.