RPC Standards #22

Transcript

Mercy Boma Naps-Nkari: Hello?

Chase Wright: Hello.

Mercy Boma Naps-Nkari: Oh, sorry. Good evening. I thought my mic had an issue. Good evening.

Chase Wright: Alright, number.

Mercy Boma Naps-Nkari: I guess we can start, I'm not sure if Alex will be joining us today, and IOC, can we start, Chase?

Chase Wright: Yeah, I guess so. We do have LightClient here. He's able to merge stuff.

Mercy Boma Naps-Nkari: Okay, alright then. Good evening, everyone. Welcome to our PC call standard, our PC Standard Call, and we have a lot of things on our agenda today, but I just wanted to give a quick update on the things I said I was going to do last two weeks. So, the two PRs I, How to get, the EL and the CEOs to take a look at, I've had, like, positive feedback. Although SCDC was postponed last week, so I'm still trying to figure out how to get more client devs to look into it. That's all from my end. I guess… Okay, sorry about that. But I would also like to give a quick… I have a question about the error codes. I don't know if SIMS,

can make a quick, update on that before I ask my question.

Simsonraj Easvarasakthi: Hey, yay, EMOC, So, based on the previous reviews, we decided to go, Go inspection route, and, I did modify the PR. Now, it just uses the new Go tooling, and, does not use the extensions anymore. I think… Yeah, the functionality remains the same. I validated it. I also wrote tests to make sure everything is sticking to our expectations. I did speak to Zane. Zane mentioned he is in talk with LightClient. I'm not sure. I'm not sure, what's the direction here. Would appreciate if Felix, reviewed it. But, yeah, but the changes are done, in short.

Mercy Boma Naps-Nkari: So, I just had, like, because I was trying to look at it, and although I don't have, like, strong opinions on what should be, in the error codes or not. So, my first question is, is it okay for two groups to define the same code? Like. What if, a method, reference both groups. Which era wins? I don't know what I'm pronounce.

Simsonraj Easvarasakthi: Right, yeah, I just saw the message, I did not get a chance to respond, but it is… ultimately transformed into an array, so there is no collision. Both of them will be present in the method. But we do, or we can actually have a validation that checks based on the ranges, and the ranges don't overlap, but inherently, it'll apply the validation to the error codes. There should be a small change, I can actually update it. That was a good catch. I'll do that, thank you, Marci.

Mercy Boma Naps-Nkari: Okay, the last thing is… I… let me just finish typing. We are using… is it not… I'm not a GoDef, so I don't really know much, but from the last thing, this thing, should it be this… shouldn't it be this, format? I posted something on the chat.

Simsonraj Easvarasakthi: It's just, it's just error. Sorry, I don't catch what exactly you're saying.

Mercy Boma Naps-Nkari: I'm talking about the error wrapping.

Simsonraj Easvarasakthi: Oh, yeah, yeah, yeah, that's a standard one, yes.

Mercy Boma Naps-Nkari: So…

Simsonraj Easvarasakthi: If you want to return a custom error, we usually wrap it with the header if.

Mercy Boma Naps-Nkari: Yeah, my question is… shouldn't we use the one I posted on the chat? Like, for consistent… like, for error wrapping to preserve, like, error change?

Simsonraj Easvarasakthi: I see what you mean. Give me a sec.

Mercy Boma Naps-Nkari: Because the old style we are using is, hold on.

Simsonraj Easvarasakthi: I have to… Okay, I can chat with you async on this, I need to get a little bit more context. Sure, I can address, these, these are minor, for sure.

Mercy Boma Naps-Nkari: Okay, so, I don't know if anyone has something else to say in regards to the error codes, Pierre. If someone else had, the opportunity to look at it. Okay, in case we didn't, I can drop the PR link so that To be easier for us to review, why not call? And…

Simsonraj Easvarasakthi: Thank you.

Mercy Boma Naps-Nkari: That's the… So… apart from these two things, I don't really have any much thing else to say, so… and, the… okay, I think I'll ping, Felix. If he's available, so that he can also take a look at it. Chase, I don't know if you have the time to also take a look at it.

Chase Wright: I mean, it generally looks good to me, but Felix usually has a lot of input in that I overlook, so we should get him to look at it.

Mercy Boma Naps-Nkari: Okay, thank you. So, back to the agenda for today. We… last week, we talked about versioning and then the spec and the docs. Although, I can't see, zane and Nicole. I think we can skip that, and we have, like, a lot of, open issues and PR we need to talk to… we need to look into. And I'm not sure how we're going to go about that now, since Felix isn't on the call. Chase, can you please help me out? Because I'm not really sure how to handle it right now.

Chase Wright: I mean, I don't… I can't force Felix to join the call.

Mercy Boma Naps-Nkari: I'm saying, do you have, like, another alternative? We can, like, take a look at this, and then make a decision, or… something else we can do, because I think we are just trying to, like, declutter, the issues and the stealth barriers we had so far.

Chase Wright: I mean, we can go through them and discuss them and give, like, a summary. Or… If there are PRs that are ready, we could ask, like, clients to Provide input, but .

Mercy Boma Naps-Nkari: Okay, can I share this link? I think this is ready, the first one we have on the list. PR761.

Chase Wright: Yeah, I mean, that one's mine, and… It's already… technically has an approval, his name's… If that gets merged, though, there's a PR in Hive that also needs to get merged. I don't know if flight clients can do that. Probably not.

Mercy Boma Naps-Nkari: Okay, so the… I think the whole point of this is to kind of, like, have to hold on a little bit, since… Felix is not here, and I'm not sure if… Like clients would be willing to.

I'm not sure if LightClient is with us, or… I don't know. Apart from these PRs, I don't really have any much things on the agendas, so, unless someone else has something else to bring up, which is not yet on the agenda that has to do with these open issues of, pay hours.

Chase Wright: So, I don't really have anything, but Tulio, I know that you previously had an opinion on the, the debugs? I have a new… I have a new PR. If you wanna… say anything on it, that would be nice. I… I went into the ETH Musicians, and I pinged everyone. There, about, EIP3155. I asked Marius for… For input as well, but he's very busy with all the, devNet stuff? So, I'm basically just waiting for feedback and opinions. on that one.

Tullio Canepa: Okay, Chase, I'll… I'll take a look and let you know. Yeah.

Chase Wright: No, no pressure. I assume it's gonna be an uphill battle, no matter what, so… all good.

Tullio Canepa: Oh, okay, I will… I will take a look and… reply there. If anything.

Ahmad Bitar: Hey, guys, so, relatively new here, at least to this meeting. I came last week. Or, sorry, the week before, since this is bi-weekly. So with respect to, PRs and code reviews and, soliciting feedback or calls for feedback. Is there a… Is there, like, a general sentiment, or, like, an idea, or some sort of… like, process in terms of how, like, AI agents, whether or not it's Curse or Claude, I've probably… I've done more with, like, ETH PandaOps, just because I work in infrastructure. And I know, like, that, for example, they use, I think it's Claude, skills, or Claude Commands, or Claude Rules. So that, you know, you could just, like, comment at, Claude or cursor or whatever on the PR and say, hey, review this, and then according to some set of standards, whether or not it's, like, you know, Felix's,

general, like, sort of, like, thoughts and ideas or insights into how he thinks about, code reviewing, or anyone else, Chase, Mercy, like, anyone else. Also incorporating… so it's… it's all kind of, like, version controlled. So yeah, it's a lot of words to say. Is there… is there any, like, has there been any thought, to applying AI or incorporating more, like, AI agents, just so you can get that first level? Of feedback, and then… and then, like, others can, you know, kind of come in, and provide, like, maybe the… the more finer, insights and corrections, or… Or, or, feedback.

Chase Wright: I mean, it hasn't come up on any of the calls, and no one has… put any effort, as far as I'm aware, into, like. doing GitHub actions for, like, automated Poll request reviews and things like that. I'm not against it. I find them very useful, but… Others may have other opinions. I don't know.

Mercy Boma Naps-Nkari: Okay, I have something to say, I don't know if it's of any importance, but I feel like if we are going to, like, incorporate that, we should at least, section out, the repo a little bit. For example, the versioning we are trying to get into place, and then the error codes. I think these are, like, the kind of things we need to properly figure out before we can, set up, an AI agent or skills.mdes, stuff like that, so that we'll be able to, like, say, okay. properly map it out, per se. But I'm not sure how it totally works, because I've not, like, used them before. But… I think the next, because we just recently merged the RFP citation to the section, report, so…

There are some things we still need to figure out first before we can then introduce the agent. Into the report itself.

Chase Wright: Yeah, I mean, as far as versioning goes, like, I noticed no one's really said anything on the ETH R&D, or the ETH Magicians, even though you opened a thing. I think it's gonna be very hard. Oh, Felix is pinging me. I think it's gonna be really hard to do the endpoint versioning. Like, I think we should focus on getting a GitHub release of the spec out. First, I think that should be our first priority, honestly. But… how many more… things do we need to fix before we can release, like, a V1? I don't… I don't really know. Or we can release, like, an alpha or something, like, doesn't matter.

Mercy Boma Naps-Nkari: Yeah, during last week's call, we had this, because on the website, we wanted to have, like, A toggle button that you can, like, toggle between the various versions that was previously released. I don't know if you understand what I'm saying. Hey, Felix, good afternoon.

Felix Lange: Oh, sorry for being late to this. Chase, notified me, fortunately.

Chase Wright: Welcome.

Mercy Boma Naps-Nkari: Yeah. It so happens that you're the one driving this car, so we have, like, a lot of, issues and PRs we need to, like, go through together, so that I will know the ones I need to bring up to ACDE or ACDA, as the case may be. Can I… let me share the, the link… I share the agenda link, so the list of the peers are… The ones we… we are unable to look at. From last week. Do you want me to share my screen?

Felix Lange: No, I got it, I got it.

Mercy Boma Naps-Nkari: Perfect.

Felix Lange: I have to… I just have to, like, frantically set up everything here. I was, like, really not prepared for this. Okay, yeah, okay, the screen share is up now, so this… oh my god, that's a lot. Yup. So… I guess there… you guys already heard the update on the error codes? Or is that the next item, or what are we…

Mercy Boma Naps-Nkari: Yeah, we've heard the updates from Sims, although we still want your input on, What we have so far.

Felix Lange: Yeah. I mean, definitely it… request some review, but what I saw, just from the notification, I mean, I got a GitHub notification about it, and I looked a little bit into… into it, so I'm… basically, I mean, I saw that it was integrated, and I took, like, a short look, so it seems like the tool is now extended to… Use these files, which is… kind of good. I think this is… this is good for us, and it applies some checks on it, so what is the input that is needed from me, basically, if it's ready, or…

Simsonraj Easvarasakthi: Yeah, I got, two comments from Mercy. I'll be… it's a quick fix, I can fix that. But if you think everything else is, okay, I can post the update later today or tomorrow. So we can merge this.

Felix Lange: I mean, it seems to be okay. I would like to take a look at the output, which I cannot do just right now, but I will do it after this call.

Simsonraj Easvarasakthi: Sure, yeah, yeah, yeah.

Felix Lange: output really looks like, but I think this integration now looks very clean to me. So we have these files, and I mean… Yeah, it's… they are… they are nice. It's also, I mean, it's kind of done in the same way that the generator also operates. Now, with, like, having… basically these… yeah, I mean, it's a bit… I kind of wonder what's the point of having, like, these multiple files now when… I mean, basically every file just has one group, so we could also just have, like, a single file that has all of the error groups. But yeah, I guess that's just like a… like a…

Simsonraj Easvarasakthi: Yeah, I mean, I specifically left it like that so it's easy to navigate, and when a lot of error codes are added or determined, it'll be easier. But yeah, I mean, I think that works too.

Felix Lange: For me, it doesn't really matter, it's just more like the… I mean, the tool doesn't care either, because it just reads all of the files into the same namespace.

Simsonraj Easvarasakthi: Yeah, exactly.

Felix Lange: I think it's okay. Yeah. Okay. I mean, I think I'm… looks very good now. I mean, this is definitely a lot simpler than what we had before. In terms of the logic, and… Yeah, I mean, I will… I will… I will check out the output after the call, so that's my update, too.

Simsonraj Easvarasakthi: Sounds good, yeah, yeah, no worries, thank you.

Felix Lange: Okay, so now we are supposed to check the… the PRs, or… yeah. Should we maybe first go through the… These ones here?

Mercy Boma Naps-Nkari: Yeah.

Felix Lange: like, listed on the agenda. So we have this one, which is from… Chase, and it…

Chase Wright: So, yeah, I can speak to it if you want me to, but, like, someone made a PR to GoEthereum, that's the ref, to fix it… to fix GoEthereum, because GoEthereum was failing the Hive tests. Marius reviewed the PR, and said. this is dumb, I think the spec is wrong. So I looked at it, and I think that I agree that the spec is wrong. But then, LightClients now is asking, can clients just delete it? And, like, I honestly don't know the answer to that question.

Felix Lange: Yeah, this is not something that is, like, it's not such an easy decision to make, as is, like, changing it. I think that the… is kind of… I mean, I agree, especially if Mikhail also made a comment here, I mean, he approved it, and he is the author of these specs, so I think it's fine, we can just merge this.

Chase Wright: I mean, I did ask in, in the steel testing for all the Consensus Layer clients to look. I asked for everyone to look at it. I don't… I didn't really get any feedback.

Felix Lange: It shouldn't make too much difference for them.

Chase Wright: It's just an error code, right?

Felix Lange: So, yeah. I mean, it's okay. Let's just see how it… what it does to the test. I mean, for now, I think we can just… I mean, we can purchase. Mika gave the okay, so I think that's enough. We don't have to raise it all the way to the top with this one. There's the, this one. This is kind of hard to make a decision on, I feel. I mean, basically nobody has commented on this, so… Basically, from a workflow perspective, this pull request or this issue is… Asking us to consider adding a method. But… this… there are no further comments on this issue, so it's a bit like, what are we supposed to do here? We can consider it.

But… that doesn't… Have any action.

Chase Wright: Yeah, I think we can just leave this one for now.

Felix Lange: Yeah, this is not, like, an actionable issue for us now. This one… Yes, this is good, Juan. I actually put the triage label, but I put that last year, so I guess we can remove that now. it, is that… The problem is that the delegations… I mean, the authorizations, sorry, require a signature, and there have been some attempts from users to raise this to us, that they would like to Specify authorizations when, for example, estimating the gas, which are not signed, so that they do not have to pre-sign an authorization when it could fail, or something like that. So it has a… But the problem is that the EIP7702 does not specify a schema for these

basically unsigned authorization, so we would have to invent something. Basically. just to refresh everyone's memory here a little bit, I'm not sure if everyone is super aware of what this looks like, but basically for EIP7702, We have these… Yeah. I'm not sure. It doesn't have, like, a clear place that I can point to right now, so… I guess we can also look here into our own spec. And, So, yeah, the 7702 transaction has the authorization list, and each authorization here has a chain ID, nonce, and address, and then it has these values, which are the signature values, and these values are required. So, the authorization list… It's also… an input parameter to, a call, because for the… for these ETH call operations and, ETH estimate gas, we…

basically, The input is… Basically, a… what's called a generic transaction. And I'm not 100% sure where this is defined, but yeah, so it's defined here, and the generic transaction contains an authorization list. So now the problem is. this would be a case where the input to ETHC call and the input to send transaction presumably differ In the sense that For when sending a transaction, you want them to submit a signed authorization, whereas when they are performing a call, you want them to submit this other type of authorization that Basically, not signed, but it specifies who is the signer? Because, unfortunately, for the 7702 authorizations, the signer address is determined from the signature itself. So basically, we would need another version of the authorization list, which contains, instead of these fields, contains something like the,

sender address, or something, and then this would be the input to the ETH call, so it would be kind of a larger spec change. yeah, anyway, that's what this is about. I can also… I mean, to be honest, I didn't elaborate on it too much in the issue, I just made it more like a note, because this came up a bunch of times also in Geth development, that people were asking about this feature, and… I was just thinking, yeah, at some point we will get to this, so that's why I made the note. Anyway… I don't know how big the need is for this to be there. I mean, we don't get a lot of questions about it, definitely. Just recently, I think we got one. Someone asked about it again, so…

Does anyone have an input on this, or…

Chase Wright: I mean, so it just… it sounds like basically what you're saying is we need to extend the schema to have a… a sudo authorization list that accepts a sender address.

Felix Lange: Yes, and then we need to make sure that, basically, in general, it could be an opportunity to clean up a little bit the schema for the call input data to distinguish it from the transactions.

Chase Wright: Because…

Felix Lange: The input to a call is subtly different from a real transaction, also in other ways. For example, this is something that is, I think, also a little bit confusing. So, for example, here in this… in the schema… on the schema side, we have this generic transaction. That is supposed to contain the fields which are… generic to all types. So this is sort of, if you will, it's the base type of all transactions. And then… here you have it, like, the way we define transactions, generally, I always found that a bit obtuse in some ways, but I mean, I mean, some other people might consider it elegant, but basically it has… We have this huge alternation here that basically has these complex objects, like one for each transaction type, and then the types each define

Some of their own fields, but then they also have They also include… So, for example, here we have the signed transaction, and that has the signature values, the V, R, and S, and also includes, via the all of construction, the fields of the… Unsigned legacy transaction, which… let's see where that is… Not super sure. Yeah. So, and then that one… So, interestingly, here we repeat it, so we actually don't use this generic transaction too much. It's a bit like… Yeah, so if we… if we see the… the generic transaction, Is… Hmm. Yeah, so that's the… this is kind of the problem. So the problem is that…

We have multiple methods. We have, for example, the method ETHSignTransaction. Technically, that's, like, a whole other can of worms, why we even have that, but this one takes the generic transaction right now, and it's the same for the… ETH send transaction, which also takes a generic transaction, but also ETHC call and ETH estimate guess, they also use generic transaction. So basically, we would have to come up with another schema that is not called generic transaction, but something like call input or something. But it would be almost the same as generic transaction, just it has some differences, including the authorization list, and then possibly in the future, more differences will come up. We actually had, in the past, some more questions like this, like, can certain things be supported in the call, which are not supported in transaction? Like, it just sometimes comes up in anyways.

Yeah, I don't want to dwell on this too much, I mean… we don't have that much time on the call, and also I was late, so I'm just curious if… if… Anyone has some input here, like, maybe from Erigon, or I don't know.

Tullio Canepa: Yeah, I think this could be a good chance to define, I don't know, something like a generic call type, which applies to the If coal, if, estimate, gas. And… probably others, I don't know, cold bundles, if… all things like that. I think it depends… A lot on… how much… how many requests we have for this, I think, if it's a… And…

Felix Lange: Yeah, I mean, you could search it in your own issue tracker, so this is maybe something… how I would like to end this discussion now, it's like, I'm not sure if also your man's on the call, but for sure, you guys sometimes will get some requests like this also. So, we can just take a… take a note here test.

So, yeah, and I mean, I would just request that you guys could somehow maybe make a comment here on the issue or something, if you… if you find it useful, or if you want to… if you want this, and I mean, we can certainly make this change, but… I mean, the need is not very pressing, let me say it like that. It's just a nitpicky kind of thing, where it would be nice, but yeah.

Mercy Boma Naps-Nkari: We can also drop a like on the, channel, the Zocuson channel.

Felix Lange: No, I mean, possibly. I'm just wondering if, really, there are that many people who really deeply care about specifying authorizations in ETHCall. One of the things that we noted is that, at least in Goy theorem, we also have a feature in ETHCALL which allows overriding the state, which means it… which makes this redundant in some ways, because you can just install the delegations to the state directly via the overrides, or if you use ETH Simulatev1, you can also just overwrite. the state to have the delegations as if the authorizations have succeeded. So, in some ways, this is also redundant with this. this is maybe the other thing we should consider, is that if there is some kind of override facility for ETHCall, which I'm actually not sure how common that is, like, that would be good to have a survey on at some point, like, which clients support this, or if this is now fully made redundant by ETH Simulate, or…

We just have to… If you can use ETH Simulate, then you don't need this. Because you can just… You can just pretend that these authorizations happened by changing the state. Okay, I think we discussed it enough, let's just continue, because we need to get through this. All of these things. Getstoragevalues method, this was added in getth. Now, CINA has regenerated the tests. Is there any other client who was agreed to adding this?

Tullio Canepa: Yeah, we added it in Erigon as well.

Chase Wright: I think Reth added it, too, so…

Felix Lange: Oh, yeah?

Chase Wright: I think so. Was that in one of their release notes?

Felix Lange: Yeah, I mean, it says here, Reth has it, there's some… yeah, it was added in Erigon. Yeah, here Chase is giving the statement that he doesn't like the batching. Well, okay. Anyway, yeah.

Chase Wright: I said, I like the method because it removes the requirement to use a JSON RPC batch call.

Felix Lange: Yeah, but I mean, the batch color would be the same, no?

Chase Wright: N-no.

Felix Lange: Can you? Okay. I mean, it's… conceptually, it's the same.

Chase Wright: It is… so, I mean, I can go over all the reasons why I hate bash calls if you… if you want me to, but I did… I did lay out… Some of the benefits.

Felix Lange: I mean, yeah, I… Definitely, it gives… it's more efficient, yeah. If anyone has the need to read many storage values. That would be, like, the question, how common that is, but I guess it is common enough that we are considering to add this method now. So, yeah, I mean…

Chase Wright: So the funny thing is, shortly after this came out, someone in one of the RETH telegrams was like, hey, I need to make these thousands of git storage act calls. And I was like, here, try this method.

Felix Lange: Yeah, so it's nice, I mean, if it was already added. Like, I'm okay with it, like I said, Yeah, so what should I do now here? Like, this should be merged, or this… Is this, like, good now, or does it require further consensus from anyone, or…

Chase Wright: I mean, as far as I can tell, it's been implemented in most clients. I don't know if it's 100% of the clients, but it's most of them, and… Everyone seems on board, so I don't have a problem with it, but…

Felix Lange: Yeah, I mean, definitely, okay, so basically it has here the storage requests, which is an array of… the keys? And… Wait, is this schema actually correct? Because… Oh, I see. Yeah, it's okay, I, you're right. It has the additional properties, because each key in the object is… oh yeah, this is kind of fancy, we, yeah, okay, that makes sense. The example is definitely required for this one, though, like, to really understand it. And then the return value is also like that, yeah? Just, it gives the values, okay. Yeah, well, that's nice. Oh, and empty request is not allowed?

Is that, like, a… Is that an expected…

Chase Wright: I mean, it is… those are generated from RPC TestGen.

Felix Lange: I know, I know, I know, I'm just curious if this is… I mean, I guess Sina should now comment on this.

Sina Mahmoodi: Yeah, I mean, it's… it's not useful, for sure.

Felix Lange: No, it's just more like the question, like, should it be an air war, or…

Sina Mahmoodi: I don't have a strong opinion on this, I… I figured that… I mean, I don't think anybody would want to do this, and if they did, it's a mistake, and they should kind of realize it, but…

Felix Lange: Mmm, yeah, okay. I can get by with this, but then anyway, we have to, at some point, document… I mean, one problem is that this is not a documented behavior in the spec. And, I mean, yeah, there's a test for it, which is great, but it's.

Sina Mahmoodi: It is required, so the field is, I believe, marked as required. Doesn't that make it… And then the request…

Felix Lange: That means that… that's a bit strange, like, you… you can't really, like, require… it to be noted. Yeah, okay. Yeah, okay, I know.

Sina Mahmoodi: I don't know how I can express these semantics.

Felix Lange: And you just have to put.

Sina Mahmoodi: in this… Gorgeous.

Felix Lange: like, in the comment, it just has to say, like, this has… should not be empty, just so we have a reference of it in the spec. Because, I mean, yeah, we have the test, so that's good. The test kind of clarifies the semantics of it, but then we get into these kinds of debates again, like, oh yeah, Geth has it like this, so that's why we have to do it like this. I don't… I don't like this. That's… that's the thing, we have to… it has to be more, like… specified. Or maybe there is actually even a way in JSON schema to express this constraint. Although, I don't know how to do that myself. And seems the JSON schema experts are not on the call today.

So, yeah.

Sina Mahmoodi: I… I… I… yeah. I didn't give it too much thought, but I also didn't think of a better way to express this.

Felix Lange: Yeah, somehow it would be nice to at least have some… some… something…

Sina Mahmoodi: Do you want me to add a comment?

Felix Lange: I mean, as in, like, a comment, as in, like, text to the spec. Yeah, yeah, yeah. Yeah. I'm not sure… I think it will require some… I mean, I will merge this. it looks okay to me, and it's, like, one of these things where we basically just have everything in one PR, which is pretty nice. We have the test generator, we have the test, we have the spec update, like, all in one PR. That's really nice, like, that's kind of how it's supposed to go now, but… So I like this, but definitely we should be more precise in spec here. Okay, let's go to the next one. We have allow zero safe… block hash and finalized block. Oh yeah, this is…

I think kind of an important one. The engine API people are still discussing this. I would weakly prefer not to mess with the engine API semantics on this call, because the engine API is kind of a sensitive thing. Like, with the earlier PR, I agree, it was more like a deepfix and some old method, like… I'm okay with that, but when it comes to these things, they need to figure it out on the consensus layer side first. We cannot… we cannot preclude this decision here. And either way, Mikhail is able to also merge it. So they are able to just make this change if they require it. This may be also a general thing for the future, that, like, when it comes to these engine API decisions, they are kind of more strictly bound to the ACD consensus than…

just RPC API changes. ETH capabilities discovery, I think it's too big to just make a quick decision on this. there is… some discussion has happened. Chase says he doesn't like it. Senor says… Tina seems to, at least… Like, it somehow… The author is giving some… Compromises… Maybe…

Sina Mahmoodi: I may.

Felix Lange: You can take it away and just talk a bit about it.

Chase Wright: So, I didn't like it originally because of the way that it exposed configurations of the nodes, and he's since broken it out into, two separate ideas. One is, like, hey, an admin namespace that might do that, and I said, okay, but good luck. This PR, as it stands right now, is focused almost entirely on the node responding with its pruning settings, basically. And so… I… I don't really have a problem with that. I think it's interesting, I think it could be useful for a lot of use cases, and this particular use case DRPC has is, like, a valid use case, but making a decision on whether or not it's good or not, I think like, Felix, you're a core dev for Geth, so, like, I would love to have your opinion on whether or not you think this is viable and doable. And then, Sina, I know you have comments as well, so go ahead.

Felix Lange: I mean, it comes down to what I… we have discussed a couple times before, that it's… I originally also had an idea to add an endpoint that would respond with the current… the node's current, sort of, like… tasks. which are a bit beyond just the syncing, because we have ETH syncing right now, which has a sort of unspecified response. Basically, it's just supposed to tell if the node is syncing at all, and then while it is syncing, it is supposed to report on the progress of that. But how this progress is actually reported, like, what goes into the progress and what constitutes syncing is very hard to capture. So I was, at some point, hoping that we could add an endpoint that would

give information about what the node is currently doing, like, for example, if it's indexing the transactions. the… some tool should be aware of that, like, it should know that, yeah, the currently transactions are not available from this node, because it is still, like. doing something related to the transactions, sort of. But then. we don't really have a good way of capturing this in the current API. I mean, another thing would be to make certain API methods unavailable until The respective index is built, or things like that. kind of goes back to these, like, for example, in HTTP, we have this, like, resource unavailable type of status codes, where it's… You know, it might actually come back online later, for example.

Whereas it's not, like, it's different from not found. Like, if you now, for example, query a get node with getTransactionByHash. and it returns null, you don't know, was this transaction pruned, or is it still, like, figuring out where this transaction is, or is it just, like, legitimately not existing in the world? You just cannot know these distinctions from this return value. And… I think this method is a step in the right direction, but I think it warrants further discussion also among the clients, because when I proposed my method, everyone was saying, yeah, this is just way too deep, and, like, every client is totally different anyway, so… how can we ever find any common ground on, like, how this can be documented? I do think that now that this approach is kind of better, because it gives

it kind of reports it from the API point of view. So, and this is… would be my input in this. It basically has to… whatever is reported through this method has to be relatable to other methods in the API, so it somehow should say that, like, this node can currently serve ETH get transaction by hash in this range, for example. And then that's useful from the API perspective, because you can know exactly, yeah, okay, I cannot call ETH getTransactionByHash right now on this endpoint, because it is not available. And I think that's what they want, also. It's just that they encoded it here in this… So we have to basically come to some kind of abstract model of the node here that works for everyone. And… I don't think we can just do that right now. But, so this is something that would have to be discussed in a wider call with other people. Here, they are… they have some kind of…

they are also talking about the deletion strategies and things like that. I think that's not… Maybe not the right way to do it.

Chase Wright: Okay, but what they're trying to achieve is not what you were envisioning, and all the ETH syncing stuff that you just went into, is not their objective with this particular method. What their objective with this particular method is to determine the oldest data available on the node and its pruning strategy. That is their objective for this method.

Felix Lange: Yeah, I understand it. My point is just that this kind of changes over time. Like, this is a… this… it… it… even, like, whatever they come up with isn't… probably isn't gonna capture all the nuances of, like, the data being available or not available. It's not as simple in the notes as saying, like, yeah, we have it up to this block. Like, sometimes it is, but, like, sometimes it… also, it's not, so… then it's, like, we have to find a model that really captures it, or we have to figure out, like, how we can relate it back to the… like, for example, what does it mean when it says TX? Like, for example, here they have TX disabled, for example. What does that mean, for example?

Does that…

Sina Mahmoodi: And at least that means that it cannot serve getTransactionByHash.

Felix Lange: So that's what this means, but we have to document that somehow, like, that is something that we have to talk about, like, what is the meaning of this, which operations are affected by this, when it comes… I mean, we are the definer of these API methods, so we have to make sure that there is some kind of… I mean, in our heads, I mean, it's perfectly clear that, yeah. get transaction by hash requires an index, so you have to have that index, and if you don't have that index, then this method is somehow not operational. But this… knowledge has to be surfaced somehow into the specification, and it's the same with the logs, for example. Like, the log indexing, it has more things than just, like, are the logs there or not? You can also have, like, the index goes only back that far, but you can still actually query it further in other methods and things like that. So, I would say that…

Sina Mahmoodi: I… can you… can you perhaps give a concrete example of Of how this model would not be sufficient.

Felix Lange: I'm mostly the same.

Sina Mahmoodi: My understanding of it is that basically it defines these resources that are common between all the nodes, or all the different clients, and that you can get or access through the API, and because all the clients are… Moving towards partially keeping them, then it becomes kind of crucial for the users to find out what the node they're interacting with is storing in their database. And this is what we came to with regards to the list of all such resources. I couldn't think of anything any… any other resource here. And then, like, yeah, you have to cover different strategies, because, sometimes the notes the note is storing the full history. Sometimes they have it, let's say, till

Like, let's say they have pre-merge data, in case of block and receipt. Or they have this window, Strategy, that they keep only the latest 90,000 blocks. But yeah, I think, like, one of the things that… I guess one of the assumptions here is that the node has to be synced, and any… any of this Any of these, these assumptions are kind of false if the node is still Doing the sync. But other than that…

Felix Lange: I mean, I like the model where it's about the resources, but what I'm trying to say is that this requires then more… anyway… I mean, first of all, we have to document it way more. Obviously, it could also happen after merging the PR, but knowing ourselves, this is kind of a big effort that is, like. coming up here. We would basically… there would have to be at least a document that explains why these resources are there, like, you know, we can add, like, a README or something. Nowadays, we actually have a capability of… putting more text in the documentation site for these kinds of things. So there is actually the way now to, Have here these dogs.

like, either here, or in the API, we have the methods, and inside of each method, we actually have this Markdown file that would explain more about the method, for example. So, we would need some kind of document that specifies, okay, these are the resource types, and this is what this resource type represents in terms of the API, and I think that would be, like, for me, the minimum thing that really has to happen for this method is that yes, it's good to have identified these abstract resources, but we have to specify the impact of these resources being available or not available on the API, and also maybe go more into detail about what, yeah, in general, like, what it means to have this resource available.

And then finally, I would say, with this deletion strategy, or this oldest block, most resources in Ethereum, at least when it comes to the historical data, they are somehow related to, to the block ranges. So, I think overall, it's a good idea to define the availability of these resources as a function of the chain history. But, I mean, one of the things is also, for example, here's the state resource. That's a good question. Like, what does that actually mean? Like, probably this means get balance or something, yeah?

Sina Mahmoodi: It balance is called basis.

Felix Lange: stop.

Sina Mahmoodi: Okay, so then, basically, it's like, for the… for getth, what we would return here is that…

Felix Lange: the… the state would be available for the last 128 blocks, so every time you query it, it would give you the oldest block, which is, like, head minus 128, and then… or something like that, and then it would give deletion strategy window retention blocks 128, is that correct?

Sina Mahmoodi: Yep, exactly. Unless you're running an archive node, or you manually configured guest to…

Felix Lange: For the tri notes, I mean, this is also kind of nice, basically, but this is already getting a bit… I wouldn't really call it trinotes, maybe you could call it, like, state proofs or something. So that's, like, a resource. And yeah, you can have that in a different window now, and… but for some archive nodes, it's tied with the state, so it's like… I… I mean, I get the idea. I do think that this, like, deletion strategy with the window and so on is a bit… strange, we could just give, like, a list of block ranges, for example, and I think that would be enough. Right? I mean… If we… if we give away the strategy here, then it's a bit strange, because then we have to be able to capture any node configuration somehow by the strategy, and for example, in Geth.

For some of the things, like, for example, for the blocks, we can have kind of this, like, spotty history where, like, certain ranges are available and other ranges are not available. And this cannot be captured by any of the strategies here, right?

Sina Mahmoodi: Oh, if you have imported the error files.

Felix Lange: For example, if you have…

Sina Mahmoodi: Some error files and some…

Felix Lange: Yeah, so stuff like that. And then it already becomes a bit sketchy, and who knows what's gonna happen, like, you know, in the future. Maybe there's gonna be more things like that, where the protocol will require us to keep only, like, a sparse amount of history for some reason, or they can… so, I think this is a bit, like, of a slippery slope with defining these strategies explicitly, and it would be better to keep it simple and just say we have, like, lists of ranges which we have currently available.

Sina Mahmoodi: I think the only issue… I get what you're, hinting at. I think the only issue I have with that is Let's say with date, you say, okay, we have the block range, N minus 128 to N. Then, this is a moving target, it's like, every block, it is updated.

Felix Lange: Yeah, exactly. And it's… it's hard to capture that…

Sina Mahmoodi: in the result, unless you specify that it's a kind of window delete strategy.

Felix Lange: I understand it's… That was, like, the intention behind it anyway, because they can basically query it once, and then they will just apply, like, on the load balancer, they will take this definition, and then they will just apply it for themselves. Basically, they will have a corresponding model on the load balancer side that models the node's behavior given this strategy. So, this is… I mean, this is coming from the load balancer author, so obviously they want to know, like, right away, for every request, is this request gonna be available on this node? They don't want to always call ETH capabilities before calling anything. I understand that. So, in that way. It also kind of makes sense.

But then it's the question why the oldest block exists, like, I would say, because, I mean, if you just have the strategy, and you know we have always the latest, like, 128, you don't need to know the oldest block. You can just compute it yourself using the strategy.

Sina Mahmoodi: Yeah, yeah, I think then, you would need to also expose the head, and this is something that I've been thinking about. Like, it would be nice to also return the head block in this, in the result. And then, if you know the retention blocks and the window, then you can compute the oldest block available. But then the question is for other types of delete strategy, like in Geth, we have the pre-merge pruning. then… That's a question, like, how do you… How do you convey that result?

Felix Lange: I mean, I think ultimately what… for the load balancers, the best solution would be one where you have this as, like, a subscription, where you access the node, you open the subscription, and whenever there's, like, availability of the resources changes, you get a notification about it. And that way, whenever a new block comes, or, like, the indexing is updated. It will tell you that, like, this resource hasn't changed availability now. Like, we could even make it like that. We can give them, like, these, like, per-resource availability updates all the time, so that when, for example, the change in TX indexing is requested, it will basically give it an up-to-date view all the time. And then the thing is, from the load balancer's point of view, it is acceptable for some requests to fail, especially since almost all requests

are anyways read requests, which do not have any kind of adverse effect if they fail. So, if they happen to query the wrong node, which has already moved on or deleted a resource after having delivered the availability update, then, basically, they have to repeat the request with another node. But that's… that's okay. But then we just have to make sure that the API is capable of distinguishing between these cases. For example, for transactions, instead of returning null, if the transaction falls out, it's like what's… that's kind of the issue. We cannot really… Especially for transactions, we don't… we cannot distinguish ourself between, is this transaction truly unavailable, or was it just deleted from the index?

We just don't know that. Basically. So… That's the unfortunate thing, then, that, like, if they… if they happen to query the transaction at the wrong time, it may just have fallen out of the index.

Sina Mahmoodi: Right, with a transaction, it's hard for them to know which block it is in any way, right?

Felix Lange: Yeah, it's kind of a special case, so we can just… I think we can ignore this problem for now. I would still say that, like, long-term, it would make more sense as a subscription, or, I mean, it does kind of… but I think the discussion is very valuable, and definitely I like it a lot better than my idea of exposing the, like, processes that are going on in the node, and instead going via this route of modeling the abstract resources which are required to serve the API. I think this could actually lead to a very… Viable thing that really helps The users to determine if these requests will be successful or not. And, I mean, in general, we can only ever

define the resources which are needed to service the API. So, I mean, the question then becomes, like, is it possible for all the clients to give updates about the availability of these resources, or does it totally not match what other clients are doing? But I think it seems pretty obvious to me that, like, all of these things are basically I mean, one thing that isn't here is the block headers, and I think that's a good thing, because with the block headers, it's always a bit special. Like, block headers don't really exist for the purpose of the RPC API. But they do exist as a separate concept in the protocol, so it's kind of a good thing here that they don't…

it doesn't actually have that as a resource, for example. Because then it would be confusing, then we would have to define, yeah, what does it mean for the block headers to be in range, but the blocks are not in range, and all the clients would have to behave the same with that, so… I think it's good the way… like, the way this is defined is nice. But we have to take it forward another time, I feel. This is not gonna just go in now. Okay.

Sina Mahmoodi: As for… as for concrete feedback for what we can do, I think you suggest that, Renaming trinods to state proof. I think there was something else that I'm forgetting.

Felix Lange: Yeah, well, I was more thinking that it would be nice… like, your idea was nice with, like, giving the head block, and also, having… and then I was saying, like, maybe it should be more like a subscription. Because then, it's maybe more acceptable for the load balancer to also Basically, always res… instead of receiving the strategy, just receiving, like, the up-to-date values from the node. Because they would just, like, whenever it actually changes, they would get a notification. And then, yeah, there is still the possibility of some requests failing, but that will always exist, even if they simulate it on the client side.

Sina Mahmoodi: Okay. Yeah, we can, we can, I'm gonna write these on the… issue on the PR, and we can take it forward.

Felix Lange: Yeah, thank you. So… This was it for the PRs. We have a lot of these outdated and stale PRs. I don't think we're gonna get to them. To be honest.

Chase Wright: I just posted one in chat, it's… I think it can be merged, it's just one link.

Felix Lange: That is easy, yeah. Yeah, that's easy.

Sina Mahmoodi: I have another one that I think can also be merged.

Chase Wright: Yeah, I just posted…

Sina Mahmoodi: Yeah, this one, exactly.

Mercy Boma Naps-Nkari: Yeah, I also have another one, this one.

Felix Lange: Oh! Okay I mean, yeah, so this is fine, you know. I think… Okay, so we got that one, so now what was the other one? Okay, so there was 7… 763, fill each simulate V1 test with max use gas.

Sina Mahmoodi: We already added this field to the spec, And… We didn't fill the tests.

Felix Lange: Oh, so is it currently failing to fill, like, here on the… because I think it should now be filling the tests on the CI. So it's a bit weird that it's not failing. Because as far as I understand, it should…

Sina Mahmoodi: It's probably because the guest version is not updated.

Felix Lange: Did you update it in this one?

Sina Mahmoodi: What? Not really, so… No.

Felix Lange: This is a… this is a bit… I… I would…

Sina Mahmoodi: Also, I didn't add the… sorry, I think I also forgot to add the generator.

Felix Lange: Yeah, but it's still… I mean, that's why, so… but no, is it adding new tests? No, no, no. No, no, it's… But that's a bit weird. I would say we have to investigate why is the test not… why is the CI not failing? I mean, I think we are… basically, we are… we might not be actually filling the tests on the CI. For sure. I think that was, like, supposed to be, like, a goal, but maybe we didn't actually end up implementing that. So…

Chase Wright: I mean, I haven't… I haven't seen any CI… Updates the tests. When… at what point would the CI update the test during the PR? It's not about that.

Felix Lange: detecting that this update modifies the tests in a way that isn't… like, basically, what we want is for the CI to tell us that you are modifying the tests, but the generator would overwrite your modification later. So, basically make…

Chase Wright: But I think the generator is updated, so I think… I think the generator is updated.

Felix Lange: But not in this PR, no?

Sina Mahmoodi: I think it's possibly that the generator doesn't need to be.

Chase Wright: Yeah.

Sina Mahmoodi: Because it doesn't have the… return object.

Chase Wright: Yeah.

Felix Lange: Yeah, okay, I understand it, but I mean, still, this is like, if I run the generator on the main branch, is it gonna produce this modification, and you are just giving this modification as a PR, or… if I, if I wrote.

Chase Wright: That is my… that is my understanding.

Sina Mahmoodi: Like, if you have the latest version of Geth, and…

Felix Lange: Yeah, but the latest version of Geth, this is something, the Geth version is… Let me… let me see it.

Chase Wright: I mean, to answer your question, Geth is failing the JSON RPC compat tests in Hive. It's not 100%.

Sina Mahmoodi: Yes, yes.

Felix Lange: Yeah, I understand that, but then… Okay. I'm just filling the tests locally now and seeing if they change. And on the main branch. So if they don't, then this PR requires a further change to make it actually, like, repeatable. Yeah, I understand that Geth is failing him now, so basically that means… I'm not sure, but let me, let me see. So the tests are outdated, is what you're saying?

Chase Wright: Yes.

Felix Lange: Yeah. Well, I will verify it, yeah.

Chase Wright: Okay.

Felix Lange: Okay. And then, what was that one from Mercy? There was another one.

Mercy Boma Naps-Nkari: It is.

Sina Mahmoodi: 75 eighths.

Mercy Boma Naps-Nkari: dates.

Felix Lange: TX pool namespace spec and generator. Yeah, okay. I guess you guys… Hmm.

Yeah, the textual summary, I think it's a bit weird. To be honest, This… I… I… I mean, do you really think we should specify this? Especially if we have the other one. Like, that's the thing, if we have, like, TX pool content, why would you need this TXPool inspect? I mean, this was, like, a hack added for Geth, like, a long time ago. I understand that maybe it's useful for some people to call this or so, but… this should never have ended up in any kind of, like, public API, to be honest. Like, this format is just… I don't think we should… we should… we should have that in spec. And also here it says that the string is actually not standardized.

Yeah, I think this… we can't have the inspect, basically. Because that's… that's just… this… We shouldn't standardize that one.

Mercy Boma Naps-Nkari: Okay, so I should get rid of that.

Felix Lange: I think it's more the question of, like, what people get out of this. I mean, this… This… this was added because… basically, it gives the crucial information about the transaction, which is, for some people, this is genuinely what they need. So, we can talk about it here. I mean, we're a couple minutes over time, but I guess whoever is here doesn't really seem to mind that much. So. we have TXPullStatus, which just gives the count. So you can call this, but the information value of this method is very… low, I would say. I mean, yeah, it's useful to see if the transaction pool contains any transactions. Sometimes that's what you need to know. But, yeah, most of the time, I mean, maybe you want to know the actual transactions here. So then…

You go in here and you get this, like, Huge… value, so basically the amount of data you're gonna get from the TX pool content method is very large, and it's gonna give you all of this information, like, what is the what's the gas limit of the transaction? Who is it from? What's the transaction hash? What's the input data, what's the non…

Chase Wright: We… we all… we all know this. I think the point here is documenting what all of the clients already do. The only one who says, like. had any questions is… is Besu, because, like… like, is the… is the point here to… re-implement the spec, or is the point to document what already exists, what clients are already doing, and what all the RPC providers already report back, and make sure that all the responses match, or… Yeah, but I mean, like, these responses…

Felix Lange: never, like, I mean, this is just… we cannot even test these responses if it's a… if it's an implementation you find string. I was just kind of trying to, like, lay out a little bit what's the reason why this method exists, like txpool inspect, compared to the txpool content. So I was gonna get there very soon, but, I mean, I know it was maybe a bit too lengthy, what I went into, but… The… my point was more that, like. there is some kind of spectrum of, like, verbosity of response, and, like, for TX pool content, the verbosity is very high, and then for, like, TXPullinspec, the verbosity, I would say, is, like, medium. Like, it gives you the hashes, and it gives you some amount of the information about each transaction, but it doesn't give you all.

Like, here, it only has the sender, and then it has a breakdown of the fees. So… this is… but this response is, like, specific to Geth, maybe. So, it's like, another client could return some other info here, so that makes it completely unusable, except for, like, you know, for debugging the client, which would put it more to the debug namespace or something. Like, it's not… I don't think we should specify a method in this namespace that, like, you know, is only for debugging the clients and gives, like, a… unreliable response. So, in a way, I'm a bit…

Chase Wright: But, like, what would your proposal be, then? to… to just not document it, or to go into GoEthereum and be like, delete this method, because… I don't know what the alternative is.

Felix Lange: I think the alternative is, like, this has always been our thing, is, like, we have to, for example, also with eSimulate and so on, just, like, we have to drive the process forward to the point where we… we are able to come up with a method definition that captures what users really want to do with these outputs. And then we have to make everyone implement the, like, improved version of the method that actually does what people want to do, instead of, like, documenting hacks in Geth from, like. 10 years ago. You know what I mean? Like, this is… this…

Mercy Boma Naps-Nkari: I understand what you're saying, but the problem is, trying to get, people that are not clients seems to actually, like, have an input on this. It's pretty, difficult.

Felix Lange: Yeah, I mean, we can kind of, like, infer it a little bit, like, for example, like, I think the main thing is, if you have TX pool content, it's basically the same as having txpool inspect, you get more data from TX pool content, so if you have the content. which has a structured output that gives you the… I don't really fully understand what is this with the strings here, like this… Appears to be some kind of, like. priority or something in the TX pool, or I don't know.

Mercy Boma Naps-Nkari: So, the…

Felix Lange: Is it…

Mercy Boma Naps-Nkari: Strings are more like, they match what, GET has in, in its implementation, so…

Felix Lange: Yeah, exactly, so that's what I meant. It's like, basically we're back to just, like, you know, replicating what Geth has. I understand that, like, yes, it can be valuable to, like, capture it in the spec somehow, so that there's at least a spec for it, but I think also have to… we have to see that, like, what we have in Geth isn't always, you know, like, the best thing in the world. It's just, like, honestly, sometimes it's just… nobody really… like, from the perspective of having, like, a standardized API, this is never how these things were supposed to be used. It's like, sometimes, literally, these methods were added because someone was just in the middle of debugging something, so they just added a little method to, like…

print it out, and then, like, years later, people started using that method for, like, production purposes, and now we're in the current setup. That's not… but I don't think then the spec process has to necessarily repeat that. I understand that it feels like progress to just add the method to the spec, because then, you know, it's added and everyone's using it, but I also feel like we have a responsibility here to actually ensure the API is, like, sane, and we're not just specifying all this, like, weird stuff that we're gonna have a really hard time removing later. Like, we're just cementing it in.

Tullio Canepa: Felix, I agree with your take here, but then I would suggest maybe you could move TEX pull inspect. in a… in a GEF private namespace, something like GEF takes full inspect. We have some of them in Erigon, under Erigon namespace, and I think it makes it more clear that it's something specific of the node.

Felix Lange: No, that's true, that's true. I also definitely think that, like, especially with TXBone spec, but also some of the debug methods, the stuff that has been added there over the years is not good, and it has led to this situation where, for example, it is technically totally unsafe to enable the debug namespace to anything, but still people require certain functionality from it, so then they have to filter the methods and do all these things. I understand that this is a thing that should be fixed. For sure. So, but here, I am more arguing from the perspective of the spec.

Tullio Canepa: Yeah, yeah, yeah, yeah, and I agree on that, 100%.

Felix Lange: Yeah, so… I mean, definitely, this one is here giving, Oh, so they have the nonce, yeah, okay, I understand. Yeah, that's a bit crazy, actually. So this… the whole thing is, like, this map is basically keyed by the… by the… Sender address on the first level, and then by the nonce on the second level. So you… if you have more than one transaction from the same sender, then instead of them being an array, you can directly access them by the nodes. I guess that kind of makes sense, like, in some ways. I think we could… it's actually not just a priority, it's just, like, a… gives you all the… all the… it gives you, like, a…

direct access by nonsense, I think that's okay. Like, the content method is probably okay. Yeah, the pagination, I also agree that it's not really valuable to have the pagination. Because we cannot freeze the TX pool content in a meaningful way, it's always gonna be a snapshot. But yeah, I mean… Can we just agree not to standardize the TX pool inspect? Like, is that a reasonable thing, or do you guys really wanna…

Tullio Canepa: I agree with that, but then I would suggest to move it in another namespace, so it won't come back in the future.

Felix Lange: Yeah, that'.

Tullio Canepa: I mean…

Felix Lange: That's true. I… this is… but this… this would be on us in Get, then, to, like, to do that. So that's… that's something… For sure.

Chase Wright: Yeah, so, like, I could just speak, you know, from my experience at QuickNode RPC Provider, is, like, if guest supports something. then we have to support it, you know what I mean? And, like, if we have to support it, but then we want to run Erigon or whatever, then… and, like… we can't, right? Like, that's the situation that people find themselves in when they're running RPC services, is that if guest supports it, and the other guys don't, then it ties their hands, right? And so… Yeah. So that's where… that's where I'm coming from, is like, yeah, I… I fully agree with what Julio's saying, is like, if we're not gonna document it, then it needs to… then it needs to move.

Felix Lange: I mean, I'm okay with moving it. I'm okay with breaking people's usage of TXPool Inspect. It is not… it is going to create some disruption, for sure. We will have to make sure that people have some kind of… fallback, but the fallback is… I mean, TX pool content is, like, superior in many ways, and the only way where it's not superior is if the transaction pool has so many objects that requesting them all through this API is too much. But then what we should have is, like, another version of TXPool content that just gives less data, which I think what people are using with TxPool Inspect is it gives them a very quick way of seeing which transactions are the top-paying ones based on the fees. So it basically gives you an overview of

Transaction hashes, they're… the sender, the nonce, and the fees, right? Like, that's… I think what this is about. Or is that even… does it even contain… I'm not sure what it contains. Anyway, I think it… it… it just… we have to, unfortunately, I think, defer it. The points were very good, and I mean, I'm totally on board with adding this specification for this namespace. just with this inspect method, I think it's kind of bad. And it will be bad in the testing as well, because then we always have to resort back to the spec-only tests, which… I mean, in this case, the spec-only tests will be kind of perfect, but… It will basically just say, yeah, it's a string, and that's it. We don't actually know what's in it.

So here, it would have to say… it would have to say spec only, because then it doesn't check the actual text. Okay Right. Yeah, thank you. We will take care of the remaining PRs. It wasn't, that many. So, yeah, okay, I think we should end the call now.

Mercy Boma Naps-Nkari: Yeah, thank you very much, have a nice day.

Chase Wright: Thank you, Bar.

Tullio Canepa: Thank you, bye.

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