RPC Standards #26

Transcript

Mercy Boma Naps-Nkari: Hello?

Sina Mahmoodi: Bye.

Mercy Boma Naps-Nkari: Good evening. I guess we can wait for the next, like… Too many tootsu.

Sina Mahmoodi: Yep, sure.

Stavros Vlachakis: No, I know.

Mercy Boma Naps-Nkari: Hello, so I think, okay. Yep, we can start now. Good afternoon. Welcome to ROPC Core, and I think I can share my screen. What's this agenda? Chuck, is my screen visible?

Felix Lange: Yes.

Mercy Boma Naps-Nkari: Okay, thank you. We sort of have, like, a lot of things, and then… but we can go in this order. on this EIGM PRO791. Oh, that's by me. Although, it's… it's not like, any, major changes. I think, Sinai has already approved this, but I'm not sure if, there's some other comments on it. Or something else should be done.

Felix Lange: Senior, can you make a comment?

Mercy Boma Naps-Nkari: He already approved it.

Sina Mahmoodi: I mean, this, this error, I believe is, jason, RPC-wide. Standard. But I know that some methods I believe it simulates, for one. specifies it explicitly, and I guess it doesn't really harm to do so.

Felix Lange: Yeah, I think we should somehow… I mean, it's just weird that it doesn't. Allow this, because it's a standard error, so this error can anyways happen in any method. So, is there… how is this exactly… Checked. So, I mean, why did this PR even happen? Is it just because there was some…

Mercy Boma Naps-Nkari: It was due to a comment on, on Discord. I think that's what led to this.

Sina Mahmoodi: Look, I don't think this is necessarily a fix, it's more of a clarification. like.

Felix Lange: Yeah.

Stavros Vlachakis: would it be maybe easier to go through… I'll never mind, issue that created with drugs. Everything that I discussed on Discord, maybe it would be easier to discuss over there.

Felix Lange: Hmm.

Stavros Vlachakis: It should be this link. RPC spec and high testing scrapes.

Felix Lange: Yeah, yeah, but we should, we should follow the agenda also a little bit. So, I mean, I can merge this PR if you guys want, but I do feel that it should just always allow the standard codes, because any method can raise these codes, and we don't have to specify it, I mean, otherwise we're just gonna go crazy. If we have to put it on every single method that these errors are allowed.

Stavros Vlachakis: No, no, on our side, it makes sense. Our only thought, let's say, is that For example, for this simulate V1, we have 5 tests, and basically. all the five tests are failing on the same place, which is a generic, the generic error, the invalid input params, I think, or something like that, indeed. So… At least on my mind, either we should keep only one test, since all of them are failing in the same place, or if we want to exercise different scenarios, we need to make the test Fail on different scenarios, and for those different scenarios, we should have different, maybe, error codes and messages, right?

Felix Lange: Yeah, wait, so I'm also a bit confused. This PR has a different title than what it is, say, doing.

Mercy Boma Naps-Nkari: eat. Yes, I received a comment from… about, this two cop…

Felix Lange: Yeah.

Mercy Boma Naps-Nkari: Think… So, a lot of things got changed, right? Because the, how would I say? The contest sort of got changed a little bit, so… That's why.

Felix Lange: Okay, basically, I will merge this PR, but I will just call it, like, a little bit different, like…

Mercy Boma Naps-Nkari: But what's, like, the, because I was thinking about the, 32C02, it's what's for, kind of, like, invalid params, so… So, for non-go clients to have, like, something to return, in a sense.

Felix Lange: I'm sorry, can you repeat? I didn't understand what you meant.

Mercy Boma Naps-Nkari: Okay, let me show you. I mean, this… I was thinking this could help clients, like, non-good clients, to have something to return, because the whole thing is that, the spec leaves, like, malformed hash imputes undefined. That's where all this is coming from.

Felix Lange: Yeah. I understand, but this error code is defined in the JSON RPC specification itself, like, not this specification, but the specification of the JSON RPC protocol. It says that this error code is to be returned when the parameters of the method are invalid. So I feel like we don't have to explicitly say it for every method, that if the parameters are invalid, this code should be returned, because this is already something that JSON RPC has. It's just… there, like, always. So if you… it goes for… you… we could add this error code to every single method in the whole spec, but… because it could technically happen. So that's mostly what we are saying, is not… but I can merge this, and we can later clean it up, like…

It's fine, I just think it's a bit strange to only add it here, because, yeah, like I said, this is an error that can happen for every method.

Sina Mahmoodi: Oh, I mean, just for demonstration, I posted a link in the chat, Marci, if you can open that. And it's… Makes it clear.

Stavros Vlachakis: To me, what Felix is saying makes sense. I mean, it doesn't make too much sense to me to merge this PR, which is just adding the generic error there. I think the problem is… is on the root, issue which came from us, and it's basically what I described before, different cases that need different codes, and not all of them firing up this generic, issue, let's say, on 5 different test cases. That's the issue. It's not about mentioning the generic error code. On the spec, at least for my… for my view.

Felix Lange: Yeah, I understand. It's different. What you are raising in this other issue is different. Okay, let's not get hung up on this too much. I am happy to just, you know, merge this now to, to, like… be done with it, and then let's just go to the next PR, because we have kind of a lot of items in the agenda, and… So, yeah.

Mercy Boma Naps-Nkari: Okay, the last row 7, 8, it's… on the… Oh, still funny. So this was actually one of the stealth periods we were trying to, like, clear off, and then the original author was, like, clients, so… I guess most clients already agreed on this. from… This one… should I share the link?

Felix Lange: It's okay for me. I mean, I don't necessarily need… so yeah, removing… this about removing the uncle methods, or…

Mercy Boma Naps-Nkari: Yeah.

Felix Lange: Hmm… Yeah, there was some previous discussions. Some people don't like it because they want to keep, this information. Is… I mean… So, Chase, you came around to it and said we should probably just remove it, or…

Chase Wright: Yeah, so, like, you know, it's not part of the spec, per se, to be like, all the clients need to keep the uncles, right? And, like, you can't even get uncles from historical archive nodes. Like, it's just not a thing that you can do. So, I see…

Felix Lange: Definitely.

Chase Wright: Yeah, yeah, exactly. I see some utility in, like… being able to look at an uncle from, like, you know, 5 minutes ago, but, like… but beyond that, like, none of the nodes are gonna have the data anyway, so, like…

Felix Lange: Correct.

Chase Wright: Calling in systems does nothing.

Felix Lange: we don't actually have this. Yeah, you are kind of right. This is… this information is not even stored. Yeah, you, you are correct. So, yeah, this also means, for me, we have to remove it, because I'm pretty sure, like, even current archive nodes do not keep this.

Chase Wright: Yeah, they don't… they don't.

Felix Lange: Yeah, and I mean, it is kind of… I mean, it is necessary for proof of work, yes, but the thing is that it's like… Yeah. It is required for proof of work to access, but… I think none of the Ethereum maintenance clients support this anymore.

Chase Wright: Yeah, and like, even… but even if… even if you're on a proof-of-work network, like. just because an uncle exists doesn't mean that your node saw it anyway, right? So you may not even have the uncle, even if it was a real uncle, and it happened.

Felix Lange: Yeah, yeah, I know.

Chase Wright: block.

Felix Lange: Yeah, I mean, I'm in favor of merging, it's because we… I have no way, also, of testing it. That's, like, the other thing, there's just, like, no test set up for this, and, like, with the current tools that we have, it is not possible to create a test that would exercise this, because we would have to create a chain, with uncles, which, I mean, I guess that's still possible somehow, but they're not even gonna be stored, like. It's just not gonna work. Hmm.

Mercy Boma Naps-Nkari: So, we can move a lot to the next one.

Felix Lange: Yeah, I mean, I can merge this PR as well.

Mercy Boma Naps-Nkari: Okay, thank you.

Felix Lange: Okay. But then, there was also one, from, LightClient, so that we should close, yeah? The fourth.

Mercy Boma Naps-Nkari: Yeah, yeah.

Felix Lange: 445? Yeah.

Mercy Boma Naps-Nkari: Yes.

Felix Lange: Okay.

Mercy Boma Naps-Nkari: So… The next one is, from Sina. I think I can let him to talk about it. 797.

Felix Lange: Yup.

Sina Mahmoodi: Yeah, I mean, just to give a short note about this. I've tried a few years ago to specify this method, and didn't really succeed because of OpenRPC standard not… Allowing… this… In its most ideal form. So this is a relaxation of that. Dude. It is not very strict, in the sense that you can have Like, the spec allows for… Adding the parameters of one event type, for… on an unrelevant event. So in that sense, it is not strict, it's incorrect. But at least it lets us… Specify… it's anyway, like, in some way, and then in future, when OpenRPC

add support for this kind of bundling of parameters, then we can change this and improve the situation. So right now, how I do it is that the event type is an enum. And Param is, like, one of several parameter options. So they are not, like, bundled together in this sense.

Zane Starr: I guess, what was the issue you were hitting with, like, OpenRPC, like, bundling parameters?

Sina Mahmoodi: Basically, it's… I needed to be able to express The fact that If the first parameter… like, basically, the second parameter should be conditional on the first I made an issue on OpenRPC GitHub a while ago. But I couldn't get hold of the maintainer so far.

Zane Starr: Yeah, I'm one of the maintainers of OpenRBC, so, like, if you file the issue, can you, just, like, drop the link to the issue?

Sina Mahmoodi: Yeah, sure. Let me just find it real quick.

Mercy Boma Naps-Nkari: Okay, so I have a question about this, because, this one. How do we go around this particular… Issue.

Zane Starr: Yeah, OpenRBC 1.3.x, like, supports notifications, like, notifications have been supported in 1.4 as well. The difference between 1.4 and 1.3 is that we changed the meta schema. So that way we could have proper versioning for, the library and package, so… What that means is, like, going forward, if we wanted to make changes to the spec, we could make those changes way more easily than we could in the past. But otherwise, all things are, like, backwards and forwards compatible, so you're not gonna, like, really get issues. 1.4 would be the preferred, like, version. To go, and 1.4 does have Go binding, it's just that we moved all the packages around. So let me just pull that up. It's no longer in the meta schema, it's in spec types.

So you can pull this down. I'll drafted here. Boom. So spec types has, like, the Go production as well, and then it has, like, Python and Rust. But we're working out some transpiler issues with the typing, there.

Mercy Boma Naps-Nkari: Okay, so, which means we don't have, like, a blocker around it, because I was thinking, If we are going to go with the 1.4, the go-Biden issue would suffice at some point.

Zane Starr: 1.4 has… yeah, it has all the packages and things that you want. So you'll see that it's, like, versioned, so if you wanted to, like, slowly move to 1.4 for some reason, you could do that as well. So that's, like, the Go package tree, branch. You'll see V underscore 1, 3, and V underscore 14. So the new layout has, like, proper versioning for all the things, and then they're properly tagged as well, so… I don't think you should hit any issues pulling whatever version you want to use. So, if it's like, I want to slow roll to 1.4, or if we come out with a 1.5, you should be able to do that. At your leisure.

Mercy Boma Naps-Nkari: Okay, so, Sina, I think this applies to this PR, 797.

Zane Starr: Yeah, I mean, like, as long as you're using, like, version 1.3, or 1.4, you're good to go, so you really shouldn't be hitting any issues. A lot of the issue was, internally. For validation tools, etc, that were built in the ecosystem. That wasn't properly translated to support notifications, but if you were to just, like, go into the repo and delete the return value, that would work across the board, I'm trying to think if the playground requires 1.4, but I think we made that backwards compatible for 1.3 as well. So, like, yeah, you should be okay. We also changed the validation on the OpenRBC document versions, so patch is, like, mostly irrelevant, so if you're at 1.4.x, you're guaranteed to be compatible with the rest of the ecosystem.

If you're at 1.3.x, you'll be completely compatible with any of the patch versions as well. Alright, cool.

Mercy Boma Naps-Nkari: Okay, so, Felix, I don't know what's… What sounds we have on this?

Felix Lange: I mean, wasn't there any way this plan to upgrade the specification version? that we are using, I mean, this has to happen, so I think we should just do that, and then come back to this PR. I mean, it is… It's just kind of better now to do it like this.

Mercy Boma Naps-Nkari: Okay, I think I can make a PR for it.

Felix Lange: Okay, well, if that's… if it's as easy as that, then yeah.

Mercy Boma Naps-Nkari: Okay. That means after that, we come back, we'll have to, like, come back to this after the PR has been met.

Felix Lange: Yeah, I think that's the best resolution now.

Mercy Boma Naps-Nkari: The nests… PRH762. Yeah. I think mostly this PR has had, like, had, like, a lot of comments, and then…

Chase Wright: Yeah, I mean…

Mercy Boma Naps-Nkari: Michelle…

Chase Wright: I think everyone is… more or less done reviewing it, and it's now merged in Geth, and all the other clients have made a bunch of updates. I think Besu is also done. I don't… I don't know if… I don't think anything is blocking merging. When… when we merge, there might be some hive failures that we'll need to go back and look at. maybe make some additional PRs, but… I don't know, it seems good to me.

Felix Lange: I mean, this is crazy.

Chase Wright: I'm still the author, so…

Felix Lange: I mean, this is… this is… this is a pretty amazing result, I have to say, like, seeing that it comes together with the tracer standardization, I mean, this is… This is a complicated thing.

Chase Wright: Yeah, I mean, there's more work to do in standardizing the debug namespace, you know, like, move on to call tracer and things like that, but I think… Think this is good. For now.

Felix Lange: Yup.

Sina Mahmoodi: Wasn't one of the outstanding items the wrong memory?

Felix Lange: But there are… so there are some pending… I mean, honestly, this PR is huge, so there are some items… Or…

Chase Wright: So, so the, the… The basic holdup or argument that is still being made is whether or not we should truncate the zeros in the memory and or storage. And if we do that, then we're gonna have to go back and update it again, and then update the clients again, and make make everyone have, like, one version of Geth, where… where we added the zeros, and then we removed them again, and I think the… Like, the argument is made that, like, yeah, some blocks produce, like, 600GB outputs, and if we truncate the zeros, it becomes, like… 400GB output instead of 600GB output. And I… and this is an issue… this is a problem that's existed for, like, 10 years, so I don't… I don't think we should…

necessarily block The progress, and go back and… Change it again.

Felix Lange: Yeah, I mean, honestly, yeah, I don't think that this method is practical for very large traces. This has always been the issue with this particular interface, that it is very limited, and it can produce a lot of output. And, yeah, basically this is… Kind of known issue. We thought about it in the past to potentially later define another kind of interface where we would stream the traces, for example, but we never did it, so… Yeah, it is kind of what it is now.

Chase Wright: Yeah, and as far as streaming goes, like, Nethermind, Besu, and Erigon do have streaming, but I think implementation of streaming is, you know, separate from the spec, and so…

Felix Lange: No, that's not what I meant with streaming, I just also mean it's… with the streaming, It's… it's generally annoying if if… in order to properly work with a method, you have to implement, like, streaming parsing in your client all the way through. Like, this… some clients have it, some clients don't. And so it is, like… maybe better to just, like, not have APIs that can return such large outputs, because it will always be a challenge to deal with them. I mean, also, you basically have to implement custom logic in your client to then stream the result directly to a file or something, because unless you have a very large machine, you might never be able to actually fit the entire response into your memory. So I think it has some… it has some… some issues with the… with, like, relying on streaming to capture such outputs.

This is… but as you say, this is unrelated to the PR. This is an existing API which works the way it is specified here, and it was also, it can now be standardized, which is great. I do think in the long term, we have to figure out this, like, how we want the streaming to work. But… is… Not related with, Not really related with this PR. I mean, I personally didn't have time to review this PR, I just… So I feel like I would like to actually give it a read before I… just merge it. It is kind of a large thing. But I do… Trust you guys that, I mean, there has been so much feedback on this, like…

I don't know, like, 40 comments, and from lots of people, and also people who work in clients have approved, so I think this is… honestly, good thing, but I would still like to… review it myself one more time, just to see, like, where it's at, if you don't mind. But I'm really happy that this has come together, and also now the fixes are in place, and clients. I think this is very good.

Chase Wright: Yeah, yeah, I don't… I don't care. I mean, it's been open a long time, so another couple weeks isn't gonna hurt anything. And, yeah, and, like, we've had discussions in Discord, too, as well, in the ETH R&D, so, like… Yeah, like I said, I think the only thing that, you know, people have open questions about was, like, the leading zeros, and should we remove it, and… you know, I don't… I don't think it makes that big of a meaningful difference, and… as I said, like, this has been an issue for, like, a very long time, and it only came up again because I created the standard, and then more people were trying to implement it and looking at it, and so, you know, it's not a new problem, it's just new feedback.

Sina Mahmoodi: If I may stealman the other side, because… In this thread, a lot of people participated. So I do want to take it seriously. Basically, the thing is… That, when it comes to memory. Well, we all know that it's… it can… Bloat the trace, but a lot of it's enabled. And… The ideas that have come up are… This was… the first idea was brought up by Besu. And it says that we can… Avoid emitting the full memory dump. Unless the upcode actually touches touches the memory. So, this is what was brought up by Abu Besu at first. But there are various… Various modifications you can have to this, like… You can… Only amidst the…

And we're a diff. And… I think… Maybe just one small thing that we can do, but… Like, so, in my head, we can do it in a backwards-compatible way, in which We just add a new config memory. And when this, or, like, config variable, and when this variable is set, Then we ignore The enable memory flag. And so we could do this in a backwards-compatible way, and then, like, fix it later on. But just wanted to bring it up because it's something that was… Discussed by… Multiple people.

Chase Wright: Yeah, I mean, I don't really have a counter-argument to that, other than, like, if it can be done in a backwards-compatible way, then does it impact the spec? Or can we just… make… Make a, you know… an addition. After the fact.

Sina Mahmoodi: Yeah, so basically, my thinking is that we can add it after the fact.

Chase Wright: Yeah, I mean… My only… my only concern is if we keep If we keep changing, and we keep… going, then… This is gonna… the same thing that happened to the previous efforts to standardize will happen here, and we'll just all never agree. But yeah, okay, let's let… let's let Felix review it when he has time, and then we can move on.

Mercy Boma Naps-Nkari: Okay, I think the next one should be 790, okay? Yeah, this… The original auto, we had some, this was the original, PR, but I had to, like, open a new one altogether. So… I don't know if I can get a review on it, although Chase has already approved this, but…

Felix Lange: Oh, ETHConfig. Yeah… I have not, had time.

Mercy Boma Naps-Nkari: P.

Felix Lange: Look into it, yo.

Mercy Boma Naps-Nkari: So, about this PR, do we also let other clients aware of it, in case they don't have it? I mean…

Felix Lange: This is… this method was added by an EAP, and the EAP is… live, as far as I understand, so there should not be any input from clients on this, because it's already… everything is already defined.

Mercy Boma Naps-Nkari: Okay. I guess we'll have to, like, wait for a review, then we cannot afford. So this is what it looks like.

Felix Lange: replacement for the old PR, that's the thing. So there was a previous PR, yeah, 6, 7, 8.

Mercy Boma Naps-Nkari: Yes, that was a previous PR, so the thing was, the .io files wasn't properly generated.

Felix Lange: No doubt.

Mercy Boma Naps-Nkari: the auto… he didn't have a chance to properly generate and then update the PR itself, so I asked him, and then he agreed, so I had to open a new PR in order to.

Felix Lange: Yeah, I mean, I can merge this, it's fine. This is… this is okay to merge.

Mercy Boma Naps-Nkari: Then, the next one would be this hackMD. There's so many methods that are missing from the spec, and there's so many methods that some clients have, others don't have. So, I'm not sure, although, Sina had a comment on it, on how we can easily… Put them back in place, which… this, the, this AIP was also part of it, the itConfig AIP was also part of it. So… I'm not really sure how else or what else to do about the method, but I would like us to take a look and then give feedback on it. I'm not sure if I said it, okay, yeah.

I think our most, it's cool, Minnie.

Chase Wright: I mean, for this call, I think we should focus on methods missing from spec, but implemented in 3-4 clients. That's probably…

Mercy Boma Naps-Nkari: Yup.

Chase Wright: Spend most of our time.

Mercy Boma Naps-Nkari: The first approach was its config. That's… I think, yes, which is this. So I need to, like, take this out now. Although, RET doesn't… I don't think they have it, or if they have already included, but the last I checked, they don't have it. Then we can move to… I'm trying to understand, in what order are we going to do this?

Sina Mahmoodi: Yeah, I just wanted to say that I think it's really cool to have this overview. And I was surprised to see so many methods here.

Chase Wright: So, I think it's important that we remember that the execution specs repo is… Like, it even says, like, in it that… This is for methods that all clients You know, must implement, and should be standardized, and that… clients are welcome to implement methods outside of the execution spec, like, Individually, you know? So the question becomes, then, Which of the methods… Are… that are… that are missing, or most clients have implemented, that we should spec, and we should standardize. not… I don't know that we need to… Document every single method supported by every single client.

Felix Lange: Yeah, you are right.

Mercy Boma Naps-Nkari: I understand. Okay, sorry. Go on, please.

Felix Lange: No, you speak, sorry.

Mercy Boma Naps-Nkari: No, no, no, I just wanted to concur to what he was saying, not the mom.

Felix Lange: Hmm. Yeah, there are some strange methods. There are also things like ETHR resend and things like that. These are just really old. Yeah, all this, like, ETH sign. remain… ETHubmitWork. Like, some of these methods Will not be added to the spec, ever. Like, we removed a bunch of proof-of-work-related methods from the spec. Now, for example, even today, from the spec, we removed this getUngleCount by block hash, but it's still implemented in some clients. So we have to filter this list more to see the really useful ones, and then I think that not too much will be… remaining. One of them is this ETH Get Raw transaction by hash. This is a very recent addition. Yeah, field transaction is another good example. It's, like, one that we want to push, but then…

Some clients, like, we always wanted to get some feedback from other clients, and we got a little bit of feedback, but ultimately, it was not to the level that people really got excited about implementing it, so we still don't have it. And, so I think that actually most methods here are just… Fine, I guess.

Stavros Vlachakis: Also, on, in-field transaction, we had a comment from Nethermind side about its security. I don't know if it's mentioned in the…

Felix Lange: Something that was recently discussed, yeah, you're right. So recently, there was this discussion that fill transaction is somehow insecure, because it returns both the encoded payload as well as the decoded payload. So, we can maybe talk about this a little bit here, because this topic will anyway come up at some point again. So, one thing about it is that the point of fill transaction was to… Make it so that… most software doesn't have to know how to encode transactions. So… We can reduce the scope of it to be only about… To only be about this question of filling in the defaults, but then you still have to actually encode it as a binary payload for signing.

And, I don't know too much about how these things work, but I think that is… would be… I mean, since this method is not supported now, I'm not really sure how… how the integrations work. Inside of wallets, but the intention of fill transaction was just that if you would implement, like, a simple wallet inside of your application or something, then you would be able to take advantage of the default setting behavior of fill transaction, just to So you don't have to make so many queries to fill out all your transaction details. Like, it just does all at once, like, it gives you the… current, base fee, and, some kind of estimate on how you should set your fees, and it can also estimate the gas for you, and it can set your norms, like, it does all these things in one step.

So if…

Stavros Vlachakis: Yeah, it makes…

Felix Lange: point of fill transaction, then yeah, you're kind of right, we can just keep only this part. And then this other part of returning the unsigned binary payload it's just a convenience thing. It basically gives you the input to the hash that you then have to sign.

Stavros Vlachakis: Yeah. Yeah. I see the… yeah, I see. Makes sense. The only caveat is what we described, I mean… the user has to blindly trust whatever data was returned by the RPC provider, and sign it, and if he signs the wrong data, it can mean anything.

Felix Lange: Yeah, exactly. But, I mean, this… in some ways, this also always exists, because if you submit your transaction, and then you return… get a JSON object back, you would still have to validate the JSON object somehow. So there will always be some additional validation required. But you are kind of right. Like, I don't have a problem, personally, removing this encoded output. it's okay for me, so if this is your comment and this makes you accept it, we would be happy with it. For us, the point of fill transaction is is that it's an off-ramp for people who are using ETH sign transaction with the notebook, or ETH send transaction, because we want to stop supporting this.

And we've been wanting to stop supporting it for a long time, so we always thought, like, fill transaction is kind of a good replacement, because it gives you most of the functionality, but it just externalizes the signing.

Stavros Vlachakis: Yeah, I think… yeah, I think it's better. To drop this part. I don't know what the… obviously, the thing is like.

Felix Lange: Yeah, alright. I mean, let's… we can make an update to the proposal, there is a PR open about fill transaction, we can update that to remove this signed output. And, yeah. I mean, it's okay for us. We have to check.

Mercy Boma Naps-Nkari: Yeah, because…

Felix Lange: This method has been supported in GoEthereum for many years, so I feel like if we change it now in an incompatible way, there might be some fallout from this, but who knows? We can just see. Yup.

Mercy Boma Naps-Nkari: Should we also involve other clients? Like, the ones that are not here yet?

Felix Lange: Yeah, yeah, yeah. I mean, this is just specifically to get the feedback from NetherMind, and then we can just… I mean, we can discuss it further, it's… this is not the final decision about ETH fill transaction, it was just because it recently came up as a topic, so I felt like we couldn't discuss it now here in the call.

Mercy Boma Naps-Nkari: Okay, so, Ches, this… said on the chart that for method missing from spec, but implemented in 3 to 4 clients. I guess that would be the order, but, if we could also, like, leave a comment on the, this is so that I can easily take note of it. And then probably make a PR if there is no PR yet.

Chase Wright: I was just pointing out, that's a header in your document, if you scroll down.

Mercy Boma Naps-Nkari: Oh, sorry.

Chase Wright: It's, like, 3 quarters of the way. Yeah, there, there you go.

Mercy Boma Naps-Nkari: Mmm… I guess the points should be, Okay, we can start with the fuel transaction, and then… make good progress from it, and then we can progress further. I don't know.

Sina Mahmoodi: I'm surprised debug execution witness is not specified. I thought there was… Maybe there was an issue somewhere, but not the spec. This one should be straightforward, because it is implemented in all clients.

Mercy Boma Naps-Nkari: EF. Okay, I can make a PR for this. But then again, how do we, like, truly… map out, methods that we don't need to, like, specify in… In the repo. Hello?

Chase Wright: Yeah, I don't… I don't really know the answer to that question. I mean, it's… all… it's basically rough consensus. I mean… We can make… PRs to try to standardize, but then it's the same as just, like, adding a new method to some of the clients, right?

Felix Lange: I also just think that, like, some of these things… so, for example, there are things like debug standard trace block to file, which is kind of a bad, like, this… we should never add it to the spec, even though it's implemented by 4 clients, this method is kind of bad. Like, it just shouldn't… this shouldn't exist in this namespace. So it's… it's kind of like, I mean, this list is interesting, but I think some of these things we just… just… Really wouldn't want to add.

Stavros Vlachakis: I think, in general, this list is very useful, you know, for people working in clients to check what is implemented where, and implement more things, but I think we should focus more, as you guys said before, on what is in spec, and what we can add to the spec. And maybe also for the other methods that are not specced, maybe we can have some kind of, I don't know, suggested spec or whatever.

Chase Wright: Yeah, I also feel like, you know, if people aren't… Participating and asking for it, then… Maybe not enough people care, right?

Felix Lange: Yeah, that's the thing. It's like, if… the idea with the API spec is also that it should be driven by what people want to see in it. It's not about, like, specifying everything that exists, because some things that exist, existed because of some historic reason, or because people wanted in the past, or… Yo.

Stavros Vlachakis: Right, the question then goes to whether we want to… Let's say, keep it as is, or we want to standardize and improve it across clients and have more consistent results overall.

Chase Wright: I don't think we're gonna answer that on this call, I think… and… to… to previous points, like, we're gonna have to go through it, like, method by method, and I don't think anyone wants to take on that… that burden right at this minute.

Stavros Vlachakis: That's also true.

Mercy Boma Naps-Nkari: So, I have a suggestion. What if we kind of, like, present it to ACDE, and then get, people to look at it. If it's a method they want to see, then we can make a PR for it. If it's something they don't care about, then… We can't enjoy it.

Stavros Vlachakis: I would say if something that people don't care about, it's even… even better to drop it completely. From the spec and from our codes.

Mercy Boma Naps-Nkari: Because we can't really make, We… in this call, we can't, like, say, okay, they want it or they don't want it, but we just have to, like, extend the courtesy of letting them know, then if they care much about it, then we can make a PR for it. But if it's something that they don't find that useful, then we can, okay, say, okay, this is… This was crapped out, and then we have it somewhere. So I will know in case of future references and documentation purpose. I'm not sure, but that's just my thoughts. So, any more comments, or we can move over to the next thing? So I guess I can bring it up to SCDE, and then… Move on from there.

Wow. Then SPR should be 795. I'm not sure what's happening. Although this… I think Geth already mentioned this PR, if I'm not mistaken.

Sina Mahmoodi: It's not merged yet.

Mercy Boma Naps-Nkari: Oh, it's open, sorry.

Sina Mahmoodi: Yeah, it's often, those… is there any… Yeah, I, I think it can be merged from our side.

Mercy Boma Naps-Nkari: Because it needs to get merged from Geth first before we can… Undrafted.

Sina Mahmoodi: Right, so the only, the only open question for me was whether we should return nil or zero for pre-London blocks, but I… it seems like nil is… It has more consensus on it. And that would be my preference as well. So as long as everybody here agrees on that, then I go ahead and merge. In Gus.

Stavros Vlachakis: Nethermind side, we are fine. We have also draft implementation.

Mercy Boma Naps-Nkari: I think Besu has, like, an open PR. Oh, yeah. So, what's our consensus on this?

Felix Lange: Yeah, I mean… We basically have to merge it in Geth, and then we can… Get this PR in if everyone agrees that this method is necessary to add.

Mercy Boma Naps-Nkari: But I have an additional comment, is there also a way to make the spec not to, like, really depend on Geth?

Felix Lange: Yeah, I mean, certainly. It's just more that, like, for the current testing pipeline, we require the implementation in Geth to generate the test using the generator, so that's why. But, I mean, this is not… the spec itself doesn't depend on Geth, just the tests do. But I also think…

Mercy Boma Naps-Nkari: That's what I'm asking.

Felix Lange: Yeah, I mean, certainly another spec generator could be implemented in another language, and we could use that then. But the current one is in Go, so it's kind of easier. I mean, we can make… support launching Nethermind, and then generate the test with that, if you want, but then we will still have to figure out Which one to actually use. for each method and so on, so I felt like in the name of simplicity, this is, like, the easiest setup right now. Like, yeah, we have to implement in Geth, but we anyway have to implement it in Geth, like, it's not like…

Chase Wright: And even if we… even if we did switch to using Nethermind, then it just moves the goal to, this needs to be implemented in Nethermind first.

Mercy Boma Naps-Nkari: Yes, that's the… that's the thing, I was trying to, like, for it not to be, how will I say it? Client dependent. If there is a way you can easily switch to the next available client without having to…

Chase Wright: I mean, you can merge a spec without the test… files. That is a thing that we can technically do.

Felix Lange: Yeah, that's true. So if you want to… if you don't want to wait, you can also remove the test, and we can do the test later. So that's, like, the other option. So there is… there is this option, and then there's the option of implementing Geth, so we can do the test and the… and the spec in one.

Mercy Boma Naps-Nkari: I kind of like the test.

Felix Lange: Yeah, yeah, I mean… It's… it's alright. So, I think, like, with this dependency on Geth, one of the things is that for certain scenarios, Geth has a specific behavior, and we hit this sometimes also in For example, testing error codes and things like that. So yeah, for that, it would be useful if we could somehow capture another client, but anyways, if all clients are according to the spec, and they return the same thing for the same method, then it shouldn't even matter which client we use. It only matters during this implementation phase of the method.

Mercy Boma Naps-Nkari: Okay, so I guess we can come back to this once it's been mentioned. And then… I think the nesting should be this. She not left a comment, she has left a comment, but.

Sina Mahmoodi: Yeah, I mean, my final comment was that it looks good to me. So…

Chase Wright: Oh yeah, I wanted the CI test to run, though, so I did ping you, Felix, if I don't…

Felix Lange: Sorry, I have to… you mean I have to click the button here, or…

Chase Wright: Yeah, probably.

Felix Lange: Okay.

Chase Wright: I don't… I don't know how to kick off the… it just says they're waiting approval.

Felix Lange: Okay, yeah. One second. Let me see… Wait, which one was that? 755, yeah. Sweet. Hmm. Yeah, I mean, so in general, is there now some agreement on this method, or…

Chase Wright: Yeah, I think everyone's more or less on board, but because the CI wasn't running, I wasn't sure if all the test fixtures were correct or not.

Felix Lange: Yo.

Mercy Boma Naps-Nkari: Yeah, I think most people are on board, because we have Erigon, Geth, Reth, also.

Chase Wright: So I… so, like, from my standpoint, if CI turns green, then I… I'm okay with it, but…

Sina Mahmoodi: I probably will not… green. We haven't merged in guests right now. I just asked, for… I just asked the author to make some changes based on the recent spec commit. But I do want a confirmation from other clients that it's okay in this current form, before merging the PR. So I don't know if maybe, Nethermind has looked into this, and they think it's okay?

Mercy Boma Naps-Nkari: I was thinking we had someone from Nethermind on the call, so I'm not sure.

Stavros Vlachakis: Yeah, we are from Nethermind. What's the concern? We have a draft implementation of this one also. We are good with endpoints.

Mercy Boma Naps-Nkari: What about Besu?

Chase Wright: I mean, it sounds like we should take it offline, go to Discord, and maybe go to ACD.

Mercy Boma Naps-Nkari: Okay.

Keri Clowes: It looks like Phase 2 has an implementation.

Mercy Boma Naps-Nkari: Okay, thank you. Yeah, but we can still, like, Take it to ACDA, in case. But probably for most clients are involved, because there was, like, a lot of, Comments on this, regardless. This is a CMPF, sorry. I think that's okay. So I will let Zen take this on, because this is more about the fashioning we've been working on.

Zane Starr: Yeah, did you want to just open the, website, or for me to screen share? Okay. So, this was about, documentation versioning. So, we're pretty close to putting up the PR, but I did want to show off some of the features and decisions. So, basically, you'll see that, there's this fake version 0.0.9, and there's a dropdown for all the versions going down, back into time. It's capped at, like, 10 versions, just because that's what it is for right now. It can always go back further, it can be adjusted. But, you'll see this other thing called Next, so if you go to Next, that's basically whatever's in Maine, because it kind of sucks to not be able to see dogs for what's in Maine.

And then, it works as advertised, so if you were to go to, like, any of the methods. Let's say go to Eve Call is, is a good one. But if you go to any of the methods and switch between versions, it'll take you to that version of the dots. So, yeah, sure. Yeah. And you can see the version number is changing and all of that. Then there's releases for where release notes go. So if you just click on releases… At the navbar at the top. Sorry, my audio might be a little wonky. Let's go. This is probably a little bit better. Yeah, so that shows you all the different releases that are there. If you go back, actually, to the site.

Yeah. The release notes are on the left as the sidebar, so if you wanted to see a release for version 0.9, This way. And then the releases are done manually, because I think, Felix, we were saying that you wanted to create, the releases from the release notes. So if you were in execution APIs and you wanted to cut a new release, you would do that. I used the Golang-style version with a V prefix. for the, numbers, and then this gets updated into, the OpenRBC document. So now, assembled spec, branch that different downstream clients use will have, like, versioning that is parallel to the version that you cut in the release. And then this, release notes can be done in two ways. So, after you cut a release, a PR for merging in the release notes is then added,

to the GitHub that you can then merge in when you feel like putting in those release notes. It's done that way because if there's, like, a typo or something you wanted to add extra, you don't have to republish the release in order to get that data back in. It's just additional metadata and a convenience function. Other things to note… I think that's pretty much so it. The holdup on a PR is just me cleaning up all of the, kind of, fake releases and tags that I did, and just making it so the PR into the repo is, is, like, clean. Were there… There's one other thing, so if you go to Execution APIs. just, like, yeah. And then, Chick, I guess, I did, like, a kind of example of this. If you go to Eve Cole.

Yeah. I think… And scroll down… Yeah, you'll see that there's tags, so let's say just click on an execute tag for the sake of example. And that will tell you, like, all the different things for the execute. And this page can look slightly different, or you can view all tags, and if you go to the API reference, just the main, for that, if you go… or click view all tags, that works as well. Essentially, these are the different methods that will allow you to group all of the methods together, so if you wanted to quickly go through EV call, EV estimate, CAS, or… whatever you wanted to group, or all the engine methods, you could do that. And, yeah, if you just go to the main, I think, API reference.

like what you would normally see. And you scroll down to the bottom. Yeah, you'll see all the different tags, so this is just, like, a way of grouping methods together. All right, and that's, that's pretty much so, the document update that we've been, sort of working out. Yeah. The other thing is, like, linting, but it's not on the agenda for today. Yeah, any questions or anything like that?

Felix Lange: No, thank you, this was great. I think it looks pretty good. One thing is that maybe it's interesting, it's called Next, for the… yeah, I guess, yeah, we can call it that. You can.

Zane Starr: If you have another name that you like, I'm happy to throw that down.

Felix Lange: We can call it main or something, because that's what the branch is called, but yeah. It doesn't really… I mean, to be honest, next is probably cleaner, because it is, like, the next after the released version, so let's just keep it as next. And, yo. Yeah, I think this looks really good, so I'm excited to see the PR.

Zane Starr: Cool, cool.

Mercy Boma Naps-Nkari: Thank you.

Zane Starr: Probably by the end of the week.

Mercy Boma Naps-Nkari: That's nice. the PR looks nice, actually.

Stavros Vlachakis: I guess since we are out of time, maybe… Sorry, Mr.

Mercy Boma Naps-Nkari: Sorry.

Stavros Vlachakis: Yeah, maybe, since we're out of time, let's discuss, The issues that we have found on Nethermind side on the next, call.

Mercy Boma Naps-Nkari: Sorry, I didn't get to that.

Stavros Vlachakis: I'm not sure what it was. It's this one, basically, but let's discuss it on the next call, because now we are already over 10 minutes.

Mercy Boma Naps-Nkari: Can you also… So that we can… we can… have it in the agenda, because I totally… Oh. All right, thank you. We can put this async, or we can have it on the next call.

Sina Mahmoodi: I mean, I'm happy to stay on if, Do you want to discuss this? Star Wars.

Stavros Vlachakis: Yeah, basically I have to drop, but real quickly, the points from 2 to 5… It goes to what I said before, I think. I mean, if Geth fails early in all test cases, either we keep only one test case, or we make a test case that Geth fails as it should, and we adjust the codes. For points from 6 to… 13… I guess we need to make high tests to… I don't know if test, by the way, cuts his error message, but… In any case, maybe we need to align their message with what the spec says. Or if it… or if it doesn't go into alignment. Or if we don't care about their message at all, we just drop it.

And we're jailing about the code. For 14, Sambaf had the point, I don't know, yeah, he's in the call, so Sambaf, if you can take…

Sambhav: Yeah.

Stavros Vlachakis: Cool. So I'm…

Sambhav: Yeah, like, my point was, like, I get the comment, but Reth and Erigon both implement, like, both like, throw an error that sender is not an EOA. But, like, Geth does it, both ways, like, if validation is both on and off, Geth does it. Like, I get that comment, but, like, Erigon and Reth both behave like, never mind, just the error code is different. So, yeah, it was my point.

Sina Mahmoodi: Yeah, I think when it comes to 14, it should be discussed separately, because In the spec document, it says… This is how clients should behave, so it is specified as such, and it would be a spec change. Regarding the other one, like, with the error messages, a PRR was merged to Hive that should drop error messages, so they should not be checked anymore. It would be good to get a confirmation if it's working now. And I believe in a few of the other cases. When it comes to codes, so, yeah, going also to this comment in the chat, the codes are standardized. The issue is that Each client does… the… validation, like the EVM validations, in a different order, and this causes them to fail at

different points, thus returning a different error code, so… And I don't really think that we should be specifying the order of operations for each client. This is not the job of the… execution API to do. What I think we can do is basically change the test case? So that they accept multiple error codes. So, if a test is to fail. In different scenario, or, like, both, in terms of nons and gas price, then… The test case should accept all of those different error codes. it's a bit of a… so… The issue with this is that… like, the test cases are generated with Geth, and it returns a single response. So either we'd have to change the I.O. format, or…

Add another file, like, an additional file that says. For this particular test, these error codes are acceptable. And then have Hive parse that. But I, like, I think this would solve… Like, half of these… These cases here.

Stavros Vlachakis: Yeah, makes sense. Maybe let's discuss it, more extensively, one by one, on the next call. A lot of them are duplicated. In total, let's say, out of 17 items, it's like, I don't know… Five, six cases.

Mercy Boma Naps-Nkari: Okay, I also have a question. I think we had, like, error code standardization going on. Does this, somehow overlap with this?

Simsonraj Easvarasakthi: Yeah, I think it would, because during the initial decision-making of the validation of the error codes, we chose to ignore the messages. Just for this exact reason, because a different client returns different kind of messages, so it would be very hard to validate them, or… Stick to the standard. So, we are currently only… We will be actually implementing tests, only to test certain error codes, not all of them. Yeah, but I think this needs to be discussed a little bit more.

Stavros Vlachakis: Yeah, on Nethermind perspective, we agree, and we don't care if we should have, let's say, same codes, same messages, nothing the same. It's okay, whatever we decide, but let's decide on something across the whole board.

Simsonraj Easvarasakthi: Yeah, yeah, I agree. We can… we can have a little bit more discussion next week. That's exactly why current error code standardization actually has very limited error codes, because we want to be able to replicate those and test those, and keep adding on to it. If we can, you know, consistently replicate across all the clients. But yeah, we can extend and discuss this a little bit more. But I think currently we don't have tests that Validates this properly.

Sina Mahmoodi: So, in the case of It Simulates, it specifies the error codes, And… There's quite a lot of tests that also explicitly test those error codes, and that's why we have these high failures. What are you up?

Simsonraj Easvarasakthi: So, yeah, I believe, yeah, Simulate might have been the one that had it. But it's not done in a conventional way of how the other tests are behaving. I'll take a look at this so we can discuss, more next week, yeah.

Sina Mahmoodi: Sure. Yeah, let's, let's take it for next session. I just wanted to bring up this idea of… Having tests accept multiple error codes.

Mercy Boma Naps-Nkari: Hey, I think we can look into this further, and then… sorry for the overtime, I totally got lost. Thank you all for joining today's call, see you guys next two weeks. Thank you.

Simsonraj Easvarasakthi: Thank you.

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