RPC Standards #29

Transcript

Mercy Boma Naps-Nkari: Hello? Hello! So we can just wait for the like. The next 2 min, then we'll begin.

Ahmad Bitar: Hey, can you guys hear me?

Mercy Boma Naps-Nkari: Yeah, sure. Good day.

Ahmad Bitar: Okay. Okay, cool, cool. Yeah, I was gonna know that I had, I have to step away. From my computer, I'll still have access, I can still hear, but, I doubt anybody would, would, direct anything my way anyway, because I'm, I'm pretty new. But, just in case, if I don't respond, then feel free to, like, leave a message or so. and I'll I'll respond as soon as I get back. Cool. Thanks.

Mercy Boma Naps-Nkari: Okay, thank you.

Chase Wright: Hello.

Mercy Boma Naps-Nkari: Hello. Okay, let me just share the agenda. I don't know if Felix will be joining. And…

Chase Wright: How do you join her, Father.

Mercy Boma Naps-Nkari: Huh?

Chase Wright: He said he'll join in five.

Mercy Boma Naps-Nkari: Oh, okay. Should we wait for him or we can? Okay, sorry, I'm just in the message. Well, I shared the agenda on on on the chat here. I don't know if you have anything to say while we wait for. I'm not sure if I know how to share Can you see my screen?

Chase Wright: Yep.

Mercy Boma Naps-Nkari: Okay. I'm not sure how this is going to go, but, like, I don't know if you have any comments on these PRs. While we wait for Felix on. ready to something.

Chase Wright: Carrie's not here either, so… I mean, if we just start at the top, so… As far as I know, that one's mine. That one is fine. The only failure was a spell check, but that was from upstream, so that was fixed. this is mergeable. The only client that is not working is, ethrex, and they have an open PR, and they approved it, but they haven't merged it, so… Unless anyone has objections to this, which doesn't seem like it because everyone merged the PRs, this can be… this can be merged. but I need… Someone with merge rights to actually review it, approve it.

Mercy Boma Naps-Nkari: Yeah, Felix. But I have, is it this? Does this clear the… Yeah, this one.

Manuel Arto: Yeah, it's from me, this one.

Mercy Boma Naps-Nkari: Oh, okay. So the… the… one of the YAML files, is it, like… Hold on. Yeah, this.

Manuel Arto: Yeah, what it does, basically, is just adding the missing ATH get-through transactions, which are free, and they mirror the same other ATH get transaction. The only difference is that they return the one off with not found and bytes instead of the one off or not found and transaction info. So they are completely mirrored and they were missing from the specs. So it just An addition, and all the clients already implemented this. The only missing things is that, right now, GAF, was returning 0x for not found instead of null. In fact, I linked a Agua Ethereum PR in the same PR for execution API, so we should wait for them to merge, update the the test, the I/O test here, and then I think that this can go through.

Chase Wright: Felix joined.

Mercy Boma Naps-Nkari: But… Sorry I didn't get that.

Chase Wright: Oh, I said Felix jo.

Mercy Boma Naps-Nkari: Okay. Oh, sorry. Thank God. Yeah, so I have a… this, I wanted to ask, is this, like, an example, or it's… an actual value.

Manuel Arto: No, it's an example, yeah.

Mercy Boma Naps-Nkari: Okay, okay. So yeah, let's think we can start properly now. So… I'm not exactly sure how to share my screen and then send this message to this chat. Sorry about that. I'm trying to, like, rescind the, the… Agenda link for Phillips.

Felix Lange: Yes. Second.

Mercy Boma Naps-Nkari: Oh, yeah. So we have this. Pr. 8, 1. 4.

Chase Wright: Yeah. Just to catch you up on this one, Felix, all the clients have merged the PRs necessary for this except ethrex. They already approved it. They just haven't merged it. This one is… The CI failure is just spell check, and that was because of upstream issues, so… Someone just kicks off the CI again, it'll be green, but

Felix Lange: Okay, I I will. I will just. I will just do that.

Chase Wright: Yes.

Felix Lange: Oh, I think I can actually… let me see if this is… Once again, how do I? Oh, yeah, here I am just running, rerunning it.

Chase Wright: So anyway, all the client teams merged their PRs, so I assume that means general.

Felix Lange: Yeah, this should be good to go. If all clients agree on this, then it's good to go. We also merge Ethereum, so.

Chase Wright: Yep.

Felix Lange: Yeah, thanks for handing it off so cleanly. Like, this is really good. Like, this process is really working now, I feel.

Mercy Boma Naps-Nkari: Okay. Then the next one is this second pier.

Chase Wright: So I saw this one, but I don't actually know. what it…

Mercy Boma Naps-Nkari: Yeah, same here. I don't know why it's.

Chase Wright: It's adding it to the schema, but, like, do the clients return it? I I have no idea. Like, it's isn't there's no test, so I don't know.

Felix Lange: And it's for the next fork. It's anyway for the next fork. So we have to see. This is not something that we return right now. This is just maybe part of the, as a part of the Amsterdam fork.

Chase Wright: Okay, that makes sense.

Felix Lange: No.

Mercy Boma Naps-Nkari: Okay, that means we don't need to, like, have, like, It doesn't need to be approved right now.

Felix Lange: No, it doesn't. This is always the thing is like when new features are added to the block header, they eventually will somehow be I mean, this is actually not in the block header, so I'm also wondering how exactly this can be implemented. I think… so we do receive… the… Slot number… Or is it added to the block header? Let me actually just check. Oh, yeah, it is. Okay, so in that case, yeah, definitely, we should… we should add this in, but it does also require implementation in the clients. like, they might not… just because it's in the block header doesn't mean they will automatically return it. As you can go, Ethereum, we always have to add a code path that actually returns this, but…

It is, since we expose all components of the block header, and it is important for the RPC clients to be able to recompute the block hash if they so want, it means we have to add this, so it's not, like, optional.

Mercy Boma Naps-Nkari: Okay.

Felix Lange: How about we just create… the Amsterdam label. So, by the way, on the previous PR, the spell checker is still failing.

Chase Wright: All right, hold on.

Felix Lange: But in general, it's good to go, but we have to resolve the failure first. When it comes to the API, we can just… go to the So I'm just gonna mark… mark this Pr. For the slot number as I'm Sadd.

Mercy Boma Naps-Nkari: Okay.

Felix Lange: Okay. And then we have to just, at some point later, I mean, we have to add tests, and so this means we have to regenerate the test chain with Amsterdam enabled, which is always a bit annoying, because the Amsterdam spec is not final. So if we regenerate new chain now with Amsterdam rules. it does mean that the clients might not be able to import it, so this is kind of the current blocker for this. I prefer to… in this case, I would say, yeah, we can add it to the schema and then add the test later, but we actually do have to remember to do that. But this is kind of always how we do this, because up until the point where the fork is really finalized.

If we regenerate the test chain, it means we have to keep regenerating it whenever there are.

Mercy Boma Naps-Nkari: Changes.

Felix Lange: changes. So, yeah. Yeah, I would prefer not to do this. Yeah, because it just adds so much overhead to the process.

Mercy Boma Naps-Nkari: Yeah, because even, block, level access lists, the one, The PR was merged. There was no test case for it yet.

Felix Lange: Yeah, and this is honestly the correct behavior. Like, if once we get to a point where the tests, where the Amsterdam spec is finalized, we can just backfill those tests. But we have to make, like, maybe we should create a tracking issue. that will document all of the spec changes that we made without adding tests, because they they are for the next fork. Or the alternative would be to just keep an Amsterdam branch around, and then whenever we want to add something to it, and we put it all in the branch, and then we would know, like, what's the total spective. Maybe this is also something preferable. But we already added the block level access list, so I guess

that ship has already sailed for Amsterdam, but for the next fork, for a Bogota fork, we could do it like this, just keep a long-running branch that just has all the PRs that will be activated as part of the fork.

Mercy Boma Naps-Nkari: Okay. Makes sense. And then this. Sorry, my network is a bit delugging. Okay, we also need to kickstart the CI for this.

Felix Lange: Yeah, this is correct. This change is correct. I have launched the Ci. I will also approve the Pr. So this one we could actually add a test as well. So it's just so the null basically just means like. Wildcard match.

Mercy Boma Naps-Nkari: As in, are you saying that we need to, like, have, something added to the generator.school file.

Felix Lange: I mean, yeah, we would need to create a request that actually contains this value. But it is… the change itself is correct. Like, when you are making a filter query, this is one… this is an allowable input, and the clients do support this.

Mercy Boma Naps-Nkari: Okay, so I'll have to, like, Put that also so we can check. Then this. I think, she's already left the Okay.

Manuel Arto: Yeah, this is blocked by the… Go Ethereum PR, that I linked in the description. And just to update Felix, this just adds the. Three missing endpoints, which are the ATH, GET, ROAD, and SUCT And they are added mirroring the counterpart for ATH get transaction by. And also, I…

Felix Lange: I mean, it's good change, for sure, I think. It's just the the question is, so do we have some broad agreement that we want this. I mean, it is good. It's good.

Manuel Arto: Yeah, all the execution layers already implemented these free endpoints, so… It's just a spec edition. And the only structural change is that the debug gets through transaction. which was… Indicators, Yammer. If you, if you. Do I need… He didn't cover the exactly the not-found possibility, which the counterparts did, so I just added those.

Mercy Boma Naps-Nkari: I haven't.

Manuel Arto: Okay, so…

Mercy Boma Naps-Nkari: Oh, sorry about that. Hello?

Manuel Arto: What? Sorry.

Mercy Boma Naps-Nkari: Yeah, so I wanted to ask Felix a question about the value. Should it be a real value or just this example?

Felix Lange: What do you mean a real value?

Mercy Boma Naps-Nkari: Like this, this is like an example. It's not like,

Felix Lange: I mean, this could be a real transaction. I mean, the thing is, it doesn't really matter much. It… It's… it's like, yeah, if we want to have the example correct, then we have to We can just query any transaction from the chain and insert it. It's probably what the author did. No. Manuel, are you the author?

Manuel Arto: Yeah, yeah, but no, that's an example value, just that. It's conformant with the bytes format, but if that's required, I could add a real mainnet transaction hash.

Felix Lange: I mean, it really doesn't matter. It doesn't have to be a maintenance transaction, for sure. Like, as long as it's, like.

Manuel Arto: Yeah, that's what I resume.

Mercy Boma Naps-Nkari: Okay, so, do we need to… this is good to go, in…

Manuel Arto: See, for you, Felix It's blocked by the Golden GPR. You can see in the description, there is a link to our Great Ethereum PR. A book, yeah. Yeah, that one, the 35227.

Felix Lange: Yeah, we basically have to have to…

Manuel Arto: Yeah, this is me for the test. So, these need to be merged, and we need to put in a new release. on the execution API's PR, regenerate tests, and you are good to go.

Mercy Boma Naps-Nkari: Okay, thank you. So I guess it's left for to go to to get to. Yeah. PR81415, brother. I'm not sure what this is.

Felix Lange: And this is fixing some issues from the linting tool. So I guess the linting tool will complain if there's no example, and if the errors are non empty. If the errors are undefined.

Mercy Boma Naps-Nkari: It's about… I.

Felix Lange: We were discussing this last time. I think it doesn't make sense to require us to list empty errors for every method, so we would just update our spec generator to emit an empty list when there are no errors in the YAML. And, yup. I probably should be assigned on this, and then just… I have to… Yeah, basically just go through it one time. Whatever.

Mercy Boma Naps-Nkari: Yeah, I think this is mine. Oh. it's been approved by, sorry, I can't pronounce this. He's from Nethermind. The last discussion we had was to get approval from Nethermind team. I think he's also on the call.

Felix Lange: Yeah, I'm quite happy to merge this if it's… if it's finally done. Like, I mean, definitely from Get's side, we want this in. I think, field transaction is a pretty important endpoint for the user to be able to query all of the transaction defaults. And so, yeah, I mean, this… The simplification, I guess, makes sense. So, yeah.

Mercy Boma Naps-Nkari: Okay. I'm not exactly sure what this is for, but yeah. It's Shiratsu. Sorry, am I… did I… hello?

Felix Lange: Sorry. Did you talk to me? I am here.

Mercy Boma Naps-Nkari: Yeah, I was, okay, I'm talking about this PR or this H02 changes. I'm not sure what exactly.

Felix Lange: Basically, this says… I don't know. Hmm, no, that's actually a good point, yeah, so, This, it changes the regular expression for decimal numbers that we very rarely use to allow a single zero. So I think this is important. So the second change in the diff is definitely correct. And then, on the first… On the first one, it… I have to see, so somehow it disallows addresses with uppercase hex. Or what… no, this is just byte. Okay, interesting. I have to review that first part, if that's really true, but I think, like, intuitively, the first part of the diff is wrong.

Mercy Boma Naps-Nkari: Okay.

Felix Lange: So I have to… I have to… this has to be investigated. So the… but I also don't know when is the byte… actually used. Let me, let me see, how to… So this is in the schemas base types.

Mercy Boma Naps-Nkari: Yes.

Felix Lange: I mean, where is this actually used? This, like, single byte. It does… the change does match this, like, bytes pattern that's there. where so single byte in the spec right now on the master branch the single byte allows uppercase and lowercase hex while the bytes and bytes max 32 and bytes 4 and all of the other types they only allow lowercase so it is a bit of a weird thing oddity that the byte Is… kind of… allows uppercase. I think this To be honest, I think this this change is good.

Mercy Boma Naps-Nkari: Meaning we can merge it now or later.

Felix Lange: Yep.

Mercy Boma Naps-Nkari: So the next PR is 797, which is, this was formerly blocked by, the, the version dump we merged before. But yeah. I think it's… I don't know. Do you have any comments on this? Oh, does anyone have any comment on this?

Felix Lange: I mean, the last time we talked about it, it was about… that we have a dependency on some spec update, like spec version update. I am currently unaware if this really happened, but I think we merged the spec update at some point. So…

Mercy Boma Naps-Nkari: Yes.

Felix Lange: should be possible now to add this but I have to I it to be very honest it's been a while since I really looked into the whole linting setup so I think the main problem last time was that if we had merged this then it would be invalid with the spec version of OpenRPC that we are using but since we now updated it I just have to recheck it again like You know.

Mercy Boma Naps-Nkari: Yeah, yes, okay. Yeah, this is still chase. Hmm. I think we've done this. Okay, we will not. Chase, do you have anything to say on…

Chase Wright: It's true.

Mercy Boma Naps-Nkari: one.

Chase Wright: It's been a minute since I looked at this one. But yes, all the tests are passing, and the Prs were merged. yeah, no, I… as far as I can tell, this one is… It's good. Gathered another of mine. Agree, 100%. Another mine fixed their bug. Yeah, I don't… I don't… I'm not aware of a reason why this cannot be merged, it Is it? Is it ready to be merged? The spec is good. Geth and Nethermind agree. Not 100% sure on the other… the other clients. Okay.

Mercy Boma Naps-Nkari: Felix, I don't know if you have any.

Felix Lange: Yeah, I mean, as far as I know, this was merged in GoEthereum, so it is definitely, like, a… Yeah, I guess we can just put this in.

Mercy Boma Naps-Nkari: Okay, thank you. Then the last one, I think I opened this this morning. Okay. you. I'm not really sure about this, but it needs to be reviewed. Then, I have, like, I think there was this… Yeah, this comment here.

Chase Wright: I mean, I think it's fine. I'm not entirely sure. Maybe. Maybe they should be marked spec only? Just… But…

Felix Lange: Yeah, I mean, in the test setup, it was going to return is, I mean, net listening is just the most useless method ever. This will just always return true.

Mercy Boma Naps-Nkari: There is no…

Felix Lange: So this method is not… I don't know, this… this… It has returned true ever since we added it. I don't know why this method exists in the first place. I don't think anyone ever calls this.

Chase Wright: So, yeah, I guess in theory, like, if a client were to completely disable peering for some odd reason, that could be no, but or false, but I don't yeah, it's pretty useless method, but I it also doesn't hurt to have it documented.

Felix Lange: I mean, we could literally make the schema say it has to return true.

Chase Wright: Yeah, and.

Felix Lange: Okay. Okay.

Mercy Boma Naps-Nkari: Yeah, because I was trying to, like, look over the, the list we had, and then make some PRs for some of the methods. Then, on the next, method, this is, like, the only one that I feel, like, felt like has itself, not, like, value, but, like, the rest, the other part of the, the method kind of, like, exposes, the notes, which I think clients wouldn't want that. So…

Chase Wright: Like, like, I can see a scenario where the the generator talks to a node that does have a peer, and then that function that says, got Not zero, want zero, like, that could be… annoying, but, like, as long as it's only ran in Hive, it's… Fine.

Felix Lange: Yeah, I don't know, like… Just, like…

Mercy Boma Naps-Nkari: I can close it up. If it doesn't add it, you probably, it's fine.

Chase Wright: We could also just remove the tests. Not test it, and just leave the spec, like, it's fine.

Mercy Boma Naps-Nkari: Okay.

Chase Wright: But I don't, I don't really care. It's fine.

Mercy Boma Naps-Nkari: I think that's all for today. I don't know if… hold on. Then there is this, random, spam… okay, they are gone. Awesome.

Stavros Vlachakis: Somebody's with a.

Mercy Boma Naps-Nkari: For this. Sorry, go on.

Stavros Vlachakis: Yeah, sorry, sorry. So what about the, get re-transaction by start? Are we gonna merge it?

Mercy Boma Naps-Nkari: Sorry, what was the PR number? I didn.

Stavros Vlachakis: Number?

Chase Wright: That needs Geth, right? Geth needs to merge their PR?

Stavros Vlachakis: Yeah.

Chase Wright: Well, I guess that's up to Felix then.

Felix Lange: Sorry, can you say again?

Chase Wright: The ETH get raw transaction by has a go Ethereum PR that needs to be reviewed and merged.

Felix Lange: Yes, yes, yes, yes, I understand that. Yeah, yeah, yeah, we have to schedule it. So we were kind of busy, like, last couple… Weeks or this stupid exceptional situation over at.

Chase Wright: I mean, it's directionally correct, I think, and it seems fine, but…

Felix Lange: Yeah, yeah, yeah, I mean, this is not, like, a hard PR or something, it's just more like, all… you know how it is, all the changes in GoEthereum require, like, review, so someone has to actually sit and be like, okay, what is going on here, and so on. So this… I mean, even though… even though the PR is totally fine, it's just still, like, someone actually has to sit with it for, like. half hour or something, I don't know. So, it's… You will get it.

Mercy Boma Naps-Nkari: Okay, so… hopefully soon, I guess.

Chase Wright: My PR for the state method is green in the CI now.

Felix Lange: Okay, cool. So what was the, what was the problem?

Chase Wright: I have no idea. I just force pushed. I don't know. Gary.

Felix Lange: Maybe there was some kind of cash or something, yeah, okay, so I'm gonna merge it. I'm gonna shorten the title a little bit.

Mercy Boma Naps-Nkari: Oh, this is CL thingy. Yes. Then I wanted to ask some of these old prs. Do we need to like? It's close them up. For example, this… I think Sina had a PR for this already, although it's not yet merged. Close this one also. This has been messed, like, And yeah. Here.

That's literally all for today, but if we can get, like, 2 PRs closed, so that… Who would know what's pending and what's,

Felix Lange: Wait, so what has to be closed.

Mercy Boma Naps-Nkari: 3, 5, 3, and then 3, 3, 1, for example.

Felix Lange: Oh, I see. Yeah, yeah, yeah. Sorry. Sorry. Sorry. This is a bit. I know this is a bit ridiculous, and I have to Yeah, okay. So what?

Mercy Boma Naps-Nkari: There was a PR you left to comment on, I think is this. No, it's not this.

Felix Lange: Yeah, we discussed this, yeah.

Mercy Boma Naps-Nkari: So I wanted to ask, do you still stand on this? No, I can't. I don't think it's.

Felix Lange: Yeah, but all of these PRs are, like, very similar, so we discussed it last time. There has to be this index, if we make it a part of the spec, then everyone has to implement it, so everyone has to implement the index. It is possible to create this index, for sure, but it's, like, a kind of a bigger project, and not everyone would not everyone might want to. And especially this index has a challenge that it cannot really be synced, so it's like, if you're an Archive node, you can fill this, but if you're not, then you can't, and so then it's like… It would have to come with. We were also discussing this method that can give you the availability of data.

Right? So, it's like, there was… a while ago, Sina proposed this method that would say, what are the available history ranges for various types of objects, so then it would be this, like, it would have to come with some kind of entry there, where it says that you can get the value… you can get the locations of the… of an address for this block range, and then for implementations that don't support the index, they would have to return basically an empty range always, or something like that. I don't know. I just… feel like… I don't really know what's the real… I think we have to bring this up, like, in a… in a wider forum with more clients to really decide if we want to add this to the spec.

Like, it's… and this feature, like I said, it is kind of only really possible for Archive Notes, so that's the other thing, it's like… Some clients would just never implement this. And also, if the index is incomplete, then it's the question, what's the real value of it? Like, I mean.

Mercy Boma Naps-Nkari: Sorry, I don't know if I lost you on my next Okay, I guess that's all for today. Thank you all for joining. Do anyone has any other things to talk about? Chase.

Chase Wright: No.

Mercy Boma Naps-Nkari: Oh, someone raised their hand, sorry.

Simson: Hey guys, it's Simpson.

Mercy Boma Naps-Nkari: Oh, yeah.

Simson: If no one else, yeah, I wanted to discuss the error codes grouping. I know it's been blocking a couple of years. Not sure if everyone is here. Just, yeah, two cents, Yeah, the ETH simulator was unfortunate. I, in my opinion, I think we should just leave it alone and deal with, V2. Mainly because the grouping that we've done, is kind of peculiar because it's a generalized approach. If you change the grouping numbers and… as well as the categories, for example, someone… I saw someone proposing mempool, or, like, execution, like, three different grouping instead of, whatever we have now. Gas, you know, let's say… execution errors. If we change that, maybe in GET, it is those 3 layers, but we cannot guarantee the same error is being

is being handled by a different client at the same level. Maybe nonce too low is handled at a mempool level for some clients, maybe it's handled at a execution level for some other clients. So it'll cause chaos. That's why I specifically went with the generalized approach of gas errors, or, like, non-servers, or transaction pool errors. Yeah, it's just my opinion that we should leave the simulator alone and just clean up the error code a little bit. I know there are a couple of them that are just useless and a couple of them can be added. We can clean those up, but if anyone else has any other… inputs here.

Mercy Boma Naps-Nkari: like, I don't really have, like, a say into this, because we've, like, been dragging this error code for, like, the longest now. And it's… Be nice to have like a concrete pathway and then sort of like get it, get it in. I don't know, felix Chase, I think. It's up to you guys.

Chase Wright: I mean, I'm gonna be honest in that… I don't… I I legitimately don't know what to do.

Felix Lange: Sina is working on a proposal for this. Sorry, I should have mentioned this. Sina was actually, I'm not sure if he has posted it yet, but she is working on some kind of a comprehensive proposal. And we also arrived at a very good conclusion last week when we discussed this in person. So the thing about this is that We basically have to make a choice. we have…

Mercy Boma Naps-Nkari: Is this the proposal you're talking about?

Felix Lange: I think so, yeah. Yeah. Not 100% sure, but I think so. So, one, I just really quickly wanted to relay this discussion point, so… Yeah. The one thing there is that… so there is a balance between. trying to support the existing error codes, and just defining all new ones. And one of the insights that we had is. if we define all new error codes to be strictly positive, like positive numbers, then the advantage is that if the user sees a positive error code, they know it is reliable, whereas if they see a negative error code, they know that the error might not be basically, it's like a legacy error returned by a legacy client, and so, because of this, they have to, apply, for example, error message matching and whatever to, like, figure out what it really means. And I think this is a really good insight, because it means

that I think this PR is actually kind of doing the opposite, so I think Sina is reworking it or something, because here he has all the negative codes still, but the idea was that ultimately, with the error calls, we want to get to a situation where, if the client, if the client to the Rpc. Api observes. an error. with a defined error code, they know what the error means, and they don't have to check the error message or anything else, they will literally be able to decide just based on the code alone. But for this to work, they have to be able to distinguish the… old, like, legacy errors that are, like, fuzzy and undefined from the new ones. So I think we should just make a new proposal that makes… has all positive codes, and then

We have to go through this one-time transition, so then the client… in GoEthereum, we were thinking maybe adding some kind of mapper that can be activated by the user, where they are, like, if they don't want to use the new codes, they can kind of disable it. So then they can be, like, yeah, I don't know, like, legacy mode. And this is possible because If we define… Good errors now, with… all new codes, we can always map them back to the old codes just in the generic RPC server. We don't actually have to add complicated logic in every API implementation that returns the old or the new error, we can just have a table that maps them.

And I think this… It's something we could just have as a transition period, and then once, you know, a year or so has passed, we can just remove that mapper. So that's how we… how we think about it now.

Mercy Boma Naps-Nkari: Okay, I don't know if anyone from Nethermind or any other clients in the ITA has something else to say about this because I think it also needs a broader audience.

Stavros Vlachakis: I don't think we have… Very strong opinion. Maybe I need to get more context on it, to be honest.

Mercy Boma Naps-Nkari: Okay. Thank you.

Simson: To answer Felix, Felix, So I'm trying to understand, what is different from what we've already implemented, and what's being, rewritten. We already did have the positive numbers, just for the same reason, right? And,

Felix Lange: Yeah, yeah, yeah.

Simson: It just works.

Felix Lange: I just wanted to update you guys because Chase and I had this had this interaction there actually not just Chase and me but like all the multiple people were in this discussion and we were a bit unsure like where to go should we preserve the old error the error codes which are used by ETH simulate or should we make totally new ones and Also, there are some questions about these, like, groups, how they should exactly be laid out. So, mostly what I want to say is this is still being worked on. And we will come to some kind of resolution later with an updated proposal.

Simson: Okay, okay, got it. The only thing I also wanted to say here is, in this PR, which Sina is working on. Currently it groups by execution result errors, simulation, and transaction validation. I did take similar approach initially, but scrapped that and, went with the… you know, user-friendly groups. For example, let's take a typical user who would interact with the MetaMask, and if… if the client is not good at throwing, giving back the proper error message. they should be able to know what is wrong with it. So if they say, let's say, 800 category, they'll assume something wrong with the gas. So it should be as simple as that, is why we… We grouped like really, with basic, intentions rather than grouping like a client specific ones. For example, the simulation error may not happen the same way for all the clients, right? Maybe it's possible, get on get based, but if you take like an EVM specific change.

Such weird ones like Hedera or ZK Sync or someone else. It may not happen at the same level as a simulation space, so it will cause chaos when it comes to, like, really varied clients. So I think we should still keep it at like really elemental level or like a really simple grouping. So users are able to, you know, easily understand what, what impacts that has on them and how they can react. Rather than doing it at, like, a developer level or a client level.

Felix Lange: Sorry, I didn't understand your point. I have to admit.

Simson: Okay, you know, quickly, for example, right now, this PR does, removed all the existing grouping, one of which is a gas errors, which had, let's say, 8, 8, 000 or 800 to some number. it… it removed that and added execution result errors, simulation errors, transaction validation errors. But when a user sees this, sees a group. And if they are able to associate that with, let's say, simulation errors, it doesn't make sense for them. They don't know how to react to this user in the sense like a typical user who would interact with the blockchain. They won't know what a simulation error means or what a transaction validation error means. But if you have that, like a gas error or something that's more elemental and generic that, that an end user would understand, they can easily relate, eight, 800 grouping to a certain, reaction zones, for.

Felix Lange: I understand.

Simson: Into how we do the… yeah, yeah, yeah.

Felix Lange: Yeah, I guess we mostly just see the groups as more like an implementation detail. We actually don't think that, like, this idea of somehow reacting to the category of the error, I've heard that thrown around a bunch of times, but… it doesn't… I mean. I think, for example, transaction validation error is pretty good. It's, like, just basically means your transaction was invalid. You have to know that, basically. I think that makes sense. But, like, gas error, I' I mean, we can split the groups as small as we want, but ultimately it's not…

Simson: In the transaction validation error, this is where I'm confused. Let's say you put the nonce too low in a transaction validation error. I'm saying it may not happen for all the clients the same way. Some clients might only come to a conclusion of what a nonce too low is. is at the consensus level. So when you have the transaction, nonce too low at the transaction validation level, it might be different for a different chain, EVM chain, or a different EVM client. If you know what I mean. So that's why we didn't want to categorize this as a layer where it gets reverted. That's honestly, to be really honest, that's how I also did. Initially, when I looked at GET, I wanted to do the categorization based on the layer where it gets reverted.

The more I delve deep, I noticed different chains, you know, errored out in a different situations for the same error. So if you put the nonce to low as a transaction validation error, it might be an actual execution error for, for a different EVM chain.

Felix Lange: No. I don't know. I kind of understand your point, but also I don't really. Sorry, I don't know.

Simson: Yeah, we could… we could have another discussion again, but I feel like the grouping Maybe we can leave the grouping similar, same as it is, and keep the positive numbers as you guys discussed. But definitely we can change the groupings and add or remove, you know, unwanted errors, And then maybe we can even take it to ACD and maybe even get a broader. Input. But yeah, we can discuss this. I just wanted to give my opinion, because, sorry, I wasn't present on the previous one, and I know people were waiting on opinions and locked PRs. Oh yeah, all good from my side. Thanks. Thanks a lot.

Mercy Boma Naps-Nkari: Okay. Thank you. I think that's, like, the last thing we have. Although I have, like, a follow up question for Chase on the last 3 to 4 calls. I think we I brought up, on the bug execution witness issue that. I think someone else, encouraged that you reach out to, K… K… I don't know if I'm pronouncing his about it. So I wanted to know if there is any updates on that, or…

Chase Wright: I'm sorry, I, I don't, I'm not following. What's the.

Mercy Boma Naps-Nkari: On our last two to three to four calls, I think we I had asked a question about how the bug execution witness should.

Chase Wright: I don't, I didn't hear that. Oh, debug execution witness. Okay. What about it?

Mercy Boma Naps-Nkari: Yes. So across clients, we have like no agreement on what the wireship is. For example, in GET, if I remember vividly, GET uses a JSON header and leaves the key empty, while RET, Nethermind, and… Erigon, yeah, they default to RLP bytes and then populate the key. So… There was a second thing also, get and write still exposes the separate by hash method. So I'm not sure which of. what the spec should look like.

Chase Wright: But this is all part of the, like, ZK stuff, right?

Mercy Boma Naps-Nkari: Yeah, it's part of it. On the last call, I can't recall his name, he… He said he also had a question about it, then encouraged that you reach out to Kev on how this should be in the spec. Because each clients have like a different thing they're doing.

Chase Wright: Yeah, I don't, I mean, I don't, I don't know, cause I'm not part of the ZK EVM stuff. Bye bye.

Mercy Boma Naps-Nkari: Yeah, I was asking if you did reach out to him, or should I reach out to him, because I wanted to ask about… there was a follow-up question also on… Smaller calls, if we want to, like, mandate, The state code, also, and then the standard error, which… we'll still come back to standard error code.

Chase Wright: Is there an open issue in the repo or in one of the repos? And then we could tag the relevant people who need to respond?

Mercy Boma Naps-Nkari: Okay, I think I can open an issue, but it's part of the list of method we we listed out that there is not yet spec'd in this. We don't have it in this pack yet. I can open an issue and tag it to it.

Chase Wright: Okay.

Mercy Boma Naps-Nkari: Okay, that's all from my end, I think. We are good to go. Bye.

Chase Wright: Bye-bye!

Mercy Boma Naps-Nkari: Thank you all for joining.

Stavros Vlachakis: May I help you?

Manuel Arto: Bye.

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