Chase Wright:Okay, I guess we could just get started. Felix is here, and I…
Transcript
Chase Wright:As far as I know, this is everyone who usually participates.
Chase Wright:I guess I can share my screen, and we can probably get started.
Chase Wright:Boom.
Chase Wright:Okay.
Felix (Geth):There isn't gonna be too much to discuss today, I think.
Chase Wright:Yeah, which is totally fine by me, since it's the day after Easter. Let me see, let me… let me see. So,
Chase Wright:We do have this one,
Chase Wright:This one is fixing the error message checking in, in the RPC compat?
Chase Wright:I looked at it, I… I think it's fine, but, you know, I'm not as Go expert-y as you are there, Felix, and…
Chase Wright:some other people. So they added a test, it got approval from From… this person?
Chase Wright:That's it. Okay. I cared.
Chase Wright:Also, welcome back, I guess? I think you've been, you've been gone for a while.
keri:Thank you. Yeah, yep.
Chase Wright:Okay, cool. Yeah, so, I don't know. I think this is… this is probably good,
Chase Wright:I know that these error messages are sometimes, client…
Chase Wright:And, like, depends on the… how the client does…
Chase Wright:some of this stuff, so I don't really have a problem with it. I think it's fine.
Chase Wright:Does anyone have any other opinions?
Felix (Geth):No, I think it's okay, but it's a bit… it's a bit strange, so this now… Changes the comparison?
Felix (Geth):So that it will… Always remove this kind of combination, so any object
Felix (Geth):Which, like, so any object containing key error, which has an object containing key message, We'll have that message
Felix (Geth):removed.
Chase Wright:Yeah.
Felix (Geth):It's just, we don't really have this combination except in this method, but it's just kind of a strange…
Felix (Geth):It's like the same… we have a similar kind of logic already when it comes to, I think, some other thing there in the comparison, like, I think with some floats or something, we also have this similar kind of thing, where it's… the comparison is a bit custom.
Felix (Geth):But I…
Chase Wright:Yeah.
Felix (Geth):I understand that it's, like, the best solution That is possible.
Chase Wright:Yeah, you know, so, like, I've had… I've had conversations with some customers, you know, previously, where,
Chase Wright:like, they will complain if it's not, you know, byte for byte, and a lot of times, it is these messages, and the error code reverted, or, like, ABI, you know, parsing that the clients do sometimes to provide
Chase Wright:human-readable, useful error messages, they're not… they're not the same. And then, so, you know, if you are,
Chase Wright:a major exchange, and you're depending on multiple RPC providers, and you're doing comparisons across those RPC providers to make sure that your data is good, then you run into these situations where it's not byte for byte, the message is slightly different, and then
Chase Wright:You know, if you're doing a dumb analysis, like.
Chase Wright:Is the hash of these two responses the same, or whatever, then they're not going to be the same, and it does cause some issues.
Chase Wright:But I don't… I don't know if that is a thing that we can enforce or fix reasonably within our PC compatibility testing.
Felix (Geth):So I think it's just kind of a strange thing, because in this part… I mean, usually with the errors themselves, there is no problem, because we already removed it. It's just that because this is a legitimate result from the call, but inside of this result, we have
Felix (Geth):These, like, errors.
Felix (Geth):which have error codes and messages, but they are just a part of the response. So it's kind of a strange situation that only really comes up with the SimulateV1.
Felix (Geth):I mean, one thing we could do is, for example, just take out the message from eSimilatev1 and just say this is not… the client shouldn't return any message there. But then that's also not very helpful. I guess you do kind of want to see the message, but…
Felix (Geth):It… or the other thing we could do is…
Felix (Geth):I mean, why is this even using the arrow code and message type of situation? We could as well have…
Felix (Geth):just predefined errors, which are just strings, and then it should say, yeah, this call failed because of reason reverted, or something. And then we would have a standardized set of things. It's only because in eSimulate, they are kind of…
Felix (Geth):using the same machinery that we sometimes use also in ETHCAL to run the EVM and capture the error, and then they return the error in this… in this way. So that… that leads to these diverging responses. I do think this fix is okay, we're not gonna change it in the spec.
Felix (Geth):for now, but I do think that this is kind of an avoidable situation from a spec point of view, because technically, from a spec point of view, all the messages, like, all of the… not the messages, all of the values that are returned
Felix (Geth):by the clients should be the same, unless it's completely impossible. I think in this case, it would actually be possible to define this API in a way that makes it, like, not dependent on the client.
Felix (Geth):But we haven't done that, so now we have to live with it, so I guess this fix is okay.
Chase Wright:Yeah, I mean, I… I think I agree with that, like…
Chase Wright:From… from, like, a… you know, a troubleshooting, debugging standpoint, like, Having the message is…
Chase Wright:is generally more useful than not. Because, you know, there can be 8,000 reasons why something reverts, and if you don't have
Chase Wright:Any… if you don't have any idea what it is, then, you know, your analysis has to go much, much, much more deeper.
Felix (Geth):Yeah, definitely, it's nice to have the message there, but it's also something where it… I mean, there is also the error codes, which are supposed to be unique, and it's also a bit funny, because these error codes are the same as these, like.
Felix (Geth):general EVM call message type error codes. So that's also a bit strange, that we're kind of hoisting these error codes up into the result of the
Felix (Geth):Of the thing, it's just kind of a…
Felix (Geth):like, ETH Simulator's honestly kind of a messy thing. So, we'll just… I can… I can… I can merge this.
Felix (Geth):I will have to look, into the code a little bit. It is kind of strange how it's written.
Chase Wright:Yeah.
Felix (Geth):But…
Chase Wright:Okay.
Felix (Geth):to be honest, like, I mean, it works, but it's also, like, the code is not that great.
Felix (Geth):Nope.
Chase Wright:Okay, well, when you have time, you can provide.
Felix (Geth):Yeah, I'll get to it differently. If it fixes the eSimulate error for Bisu, then that's also nice.
Chase Wright:Yeah, Besu is at, 94% last time I checked for compatibility testing, so… Doing pretty good.
Felix (Geth):That would actually help a lot with getting them closer, yeah.
Chase Wright:All right, the next one is the testing Build Block V1. I don't think we have to talk about it very much, but it's been… it's been merged. Most of the clients support it, so I'm looking forward to seeing the results of the
Chase Wright:upcoming Hive runs, yeah, we'll move on. The next one will make, Sina happy. So we added the getStorageValues method. Again, that'll be nice to see in the,
Chase Wright:upcoming,
Chase Wright:Hive compatibility and make sure everybody's on board. I know multiple clients already support it, including NetherMind, and Reth, and Geth, so that's good.
Chase Wright:After that…
Chase Wright:I don't know, Mercy, if you want to take over here. We have… we have your two PRs that you wanted to talk about. I guess we could talk about… which one you want to talk about first?
Mercy Boma Naps-Nkari:The, the…
Mercy Boma Naps-Nkari:Okay, I can go with the, the TSpoon space. Okay. I had to open, like, some couple of pairs on,
Mercy Boma Naps-Nkari:Eterx, and then Nethermind, because…
Mercy Boma Naps-Nkari:GET and Red has the full method implemented already, so… although Erigon, I checked their codeBesu, they had… they had all four, but they commented out two, so I asked them if there was a reason they commented it out or something like that, so…
Mercy Boma Naps-Nkari:I was hoping we can match this, since… Besu also said if implemented it, that's another thing.
Chase Wright:Okay.
Mercy Boma Naps-Nkari:So I'm not sure if…
Chase Wright:We have Julio here, maybe he can… he can comment if he's…
Mercy Boma Naps-Nkari:Oh, oh, okay.
Tullio | Erigon:Yeah, I think we don't have inspect, but we have already discussed it last time, I think.
Tullio | Erigon:So… We kind of decided not to standardize it.
Tullio | Erigon:If I remember correctly.
Felix (Geth):Yeah, there's this thing with this… the inspect is just kind of weird with these, like, string responses, because we're gonna be running into the same issue that we just discussed now, where, like, the clients, they are allowed to return whatever, so then we would have to, again, you know, update the comparison in the tests to allow for a mismatch in this.
Felix (Geth):And in general, the method is quite…
Felix (Geth):useless. I mean, it exists in clients, but that doesn't mean it's a good way. And we discussed it last time that… I mean, it is…
Felix (Geth):now, I guess, documented that these…
Felix (Geth):Summaries are… like, these strings are client-specific, but that doesn't really help much with the fact that this is effectively not testable.
Chase Wright:Yeah, I think I remember that, and I do think that the general consensus was that we should just not do TXPoolinspect, and we should keep the other methods. Is everyone on board with that? I think…
Felix (Geth):Now, I…
Chase Wright:I think that's fine.
Felix (Geth):I mean, it's better to specify less for now.
Chase Wright:Yeah.
Felix (Geth):there's a need to have some kind of more compact response, then we can define one, but it cannot be TXBull Inspect as it is now, because as it is now, it's just a huge hack.
Chase Wright:Okay.
Felix (Geth):It's not, not, you know…
Chase Wright:So I'll make a comment here, and…
Chase Wright:Marci, I assume you can probably… Deal with that.
Chase Wright:Okay, so, I mean, is everyone else agreed that
Chase Wright:It's pretty much good to go, as long as we remove TxPoolinspect. Is that the last action item necessary here?
Felix (Geth):Yeah, I think it's… Fine, yup.
Felix (Geth):Okay. Thing is, for the test, it's gonna be interesting. I mean, it is possible to test this.
Felix (Geth):But… not… I think, for now, the tests here, they mostly have…
Felix (Geth):The empty responses, or do they have something in there?
Chase Wright:Let's see, TS4… let's see.
Felix (Geth):I mean?
Chase Wright:Tests. Die.
Chase Wright:So that's the inspect the status.
Felix (Geth):So this is gonna lead to some pain, I think, because it has 5 pending transactions, but the thing is, this is very much dependent on the client policy, so we will run into some problems with this, simply because when we merge these tests.
Felix (Geth):the… it basically…
Felix (Geth):because the client instance is shared between all tests in the test suite. So, the… all of the RPC Compact tests. I'm not even really sure why that particular client had 5… had 5 transactions in its pool.
Felix (Geth):I mean, I guess it's because in some trans- other tests, we do send a transaction, and that runs before this one.
Chase Wright:Yeah, I have, so when I was doing some of the testing build block stuff, when… when we reach chain head, we do have pending transactions in the queue, at least… at least on the get side. So I think that's… that is part of it, is that
Chase Wright:We have a bunch of pending transactions.
Felix (Geth):Yeah, the issue is just that it's not gonna be the same for all the clients, because the transaction pool policies might be different, and there's nothing standardized about that. So this means when, depending on the client implementation, there might also just be 4 transactions, and then that's also fine.
Felix (Geth):But in general, also, one problem with this particular test is that
Felix (Geth):It… the response is completely dependent on the order in which tests are executed, because it is just shared state that we are seeing. We didn't explicitly put any of these transactions there in this test, they are just…
Felix (Geth):state that was created by another test. So we have to figure out how we're gonna test this at some point.
Felix (Geth):I do think it's valuable to test it, but…
Felix (Geth):I think this would be one of these things where, actually, we should probably… have…
Felix (Geth):Yeah, we should somehow implement this, like, schema validation in the test or something, and then have it so that this is one of these spec-only tests that only validates the schema or so, because it's not super easy.
Felix (Geth):for us to get the client to a point where it has a very, very specific transaction set inside of its TX pool. I mean, we can kind of try, but…
Felix (Geth):This is gonna be tough.
Felix (Geth):I just ordered…
Chase Wright:I… I think I… I think I definitely agree.
Chase Wright:I think what we… maybe what we should do is just make it spec only, for now.
Chase Wright:And then, once it's merged in, we can actually go look at the results, see how the clients are actually, returning, see what they're returning, see how similar they are, and then we can probably make a decision on, like, how much we need to fine-tune it, and then, like.
Chase Wright:We could go so far as to, like, send a raw transaction into the nodes, and then just make sure that that is a response within the TX pool content. Like, that is maybe something we could get.
Felix (Geth):Yeah, yeah, yeah, I know. This is where we now enter this issue that these tests, the way they are executed, it is really showing its limits with these types of tests, because
Felix (Geth):the only kind of test we can really do is we can just check what's the return value. We cannot perform the custom validation, so then we would, again, enter this whole world of, like, trying to figure out what is the specific result validation required for this method.
Felix (Geth):I think…
Felix (Geth):it is possible to add something like that. For example, we could start adding, like, we can add a framework that allows us to do a custom validation on the result.
Felix (Geth):for example, into RPC Compact, and then we can have any kind of validation, and for these methods, it would be something like, yeah, this…
Felix (Geth):this particular transaction has to be in there, and that's our success criteria, and if there's other stuff in there, it has to pass the schema, for example, so we could define it like that. It's just that this is not implemented now, and it's gonna be a bit of work to actually get this delivered.
Felix (Geth):So I would just say… also, another problem is that if you market spec only now, the way spec only works, it was implemented by Carrie at one point.
Felix (Geth):it wouldn't really work either, because the current spec only will actually verify the structure matches. And so, because these functions return, like.
Felix (Geth):They return these, like, objects with, like, these weird string number keys.
Felix (Geth):it will actually try to match that on the response, even if you put spec only. It's because the current spec only doesn't use the actual spec, it uses, like, the…
Felix (Geth):It tries to make sure that the… Jason… type.
Felix (Geth):returned by the client is the same as the JSON type in the test. So we do have some work to do anyways. This is not, like, as straightforward. But we will get this done. I'm just saying, for now, the testing for these methods has some issues because of how the test framework works.
Felix (Geth):It is still good, I think, to put in the specs, because these are existing methods, which all clients kind of have.
Felix (Geth):And, it's important to have them in the spec.
Chase Wright:Okay.
Chase Wright:Makes sense to me.
Chase Wright:I… and I also, you know, I don't want perfection to be the enemy of, good enough for now. So…
Felix (Geth):It's just that if we merge it, it will make the test fail. And that's… we want to avoid that. And if we make it spec-only, the test will still fail, so we just have some work to do to get that to…
Felix (Geth):to get that to pass, and then we can get and see the next step. So there's some… a little work ahead, but I still think it's a good step to have this.
Chase Wright:Yeah,
Chase Wright:Yeah, yeah, yeah. I mean, I agree. I think, you know, just from, getting all of the clients on board, like, introducing a test that fails is…
Chase Wright:It's not the end of the world. But, yeah, it's fine.
Chase Wright:Alright, I guess we can move on. So, this is Doc's ad site versioning. Mercy, if you…
Chase Wright:Have any… thing to say here. My only question is, if this did get merged.
Chase Wright:I can't see the photo.
Chase Wright:Oh, that's cool. If this did get merged,
Chase Wright:What would… what would the version show on the… on the production?
Chase Wright:dock site.
Chase Wright:Because there's no version currently.
Mercy Boma Naps-Nkari:So, it kind of, like, would display the current version we have, so if you would not want to, like, maybe toggle between various versions that has been, shipped or released, you have to, like,
Mercy Boma Naps-Nkari:I need to see the screenshot again. It's somewhere on the top.
Chase Wright:Sorry. Yeah, yeah, it's, like, up here.
Mercy Boma Naps-Nkari:Yeah, yeah, yes. So you have to, like, toggle between it to switch from one version to the other.
Chase Wright:Yeah, no, that makes sense. But we don't…
Chase Wright:We don't have a version, do we? Like, there's no currently specified version.
Mercy Boma Naps-Nkari:No, I had to make a test version to, like, get this image, right? So, I was trying to, like, see if it actually works, so…
Chase Wright:Okay, so in order for this to work, we would have to go, we would have to actually cut a release, yes?
Chase Wright:Because we don't… we don't have any.
Mercy Boma Naps-Nkari:Yes, but you can test it, like, on your local, maybe Rond du Pierre or something, like, to.
Chase Wright:I don't think I'm set up to do that on this laptop right now. Sorry.
Mercy Boma Naps-Nkari:Okay, so you can just run npm run docs version 1.0.0, then you can get that, and then you view it on your local host, just to see what it looks like.
Felix (Geth):We do actually… we do actually have some versions tagged. We could also just do tag another version.
Felix (Geth):Just to get that… like, we can just make a pre-release, for example.
Felix (Geth):And then… and then we would have it. The question is mostly, like… I mean, so this adds the…
Felix (Geth):This adds the dropdown, but… the…
Felix (Geth):Oh, so there's this file that contains the versions, I guess?
Chase Wright:Yeah, I don't know how this works.
Felix (Geth):Yeah, that is actually kind of an interesting question, like, where are the versions going to come from?
Felix (Geth):Are we just gonna add them to this array, or…
Chase Wright:Yeah, I mean, we don't have, like, a…
Felix (Geth):in the future, we haven't… I mean, we haven't really thought about it too much. I mean, we do want… ultimately, we want the…
Felix (Geth):how this is supposed to work is that we will have a GitHub action, just like now, that will…
Felix (Geth):Occasionally do a build, And for that build, it will pull
Felix (Geth):It will basically generate the site for each of the listed versions.
Felix (Geth):and then it will allow you to select between them. Because we don't actually want… I think this is actually kind of a smart way to do it with the file, because we are not gonna want
Felix (Geth):10,000 versions on there, right? There's only gonna be, I mean, we're gonna have the 1.0, and then maybe we wanna have, like.
Felix (Geth):the last…
Felix (Geth):10, 15 versions or something, but I don't think we want to have, like, hundreds of versions in that drop-down. At some point, they're also gonna just expire or something.
Felix (Geth):So it's actually not too bad to have this file that configures which versions are actually… you know, which versions should be… the docs should be built for.
Chase Wright:Yeah, so do you think, we should have something like,
Chase Wright:like, a GitHub action that when we cut a release, it… it updates this…
Chase Wright:this version before publishing? Or do you think we should just do it manually?
Felix (Geth):I think the main thing is just that this GitHub action is going to be a little bit different, because it also has to fetch the built OpenRPC spec for that version, and then generate the docs from that. So that's kind of the thing, like, the docs are gonna be generated from the OpenRPC output.
Felix (Geth):But the OpenRPC output right now is not in the repository at all.
Felix (Geth):So that's kind of the thing, the OpenRPC output file.
Felix (Geth):is an artifact that you can build, but it is not contained in the repository. And so our plan is that when we will create the GitHub releases that
Felix (Geth):of the versioned API, we will attach a JSON file, which is the OpenRPC specification. So there will be, like, a release artifact, which is that JSON file. So our GitHub action that builds the docs has to then
Felix (Geth):download the OpenRPC.json file.
Felix (Geth):For each of the listed versions, and build a documentation website for each of these versions, and then this dropdown is supposed to just switch between these versions.
Felix (Geth):You know what I mean?
Felix (Geth):Mercy says she gets it.
Felix (Geth):But… Do you understand?
Felix (Geth):Or should I try to explain it better?
Chase Wright:No, I mean… I mean… I'm… I mostly understand,
Chase Wright:But I… I've never built the, OpenRPC stuff, so I don't…
Felix (Geth):You can't see it! So if you go to the main… if you go to the branch selector, there is actually a very old thing that was recently made to work again. There is this assembled spec branch.
Felix (Geth):So, this is… this is something very strange. I own… I didn't know about this until recently as well. We do have a GitHub action, which
Felix (Geth):Every time a commit is made to the main branch.
Felix (Geth):it will reBesu this branch to add the OpenRPC.json on top.
Felix (Geth):So it always creates… it always recreates this one commit that adds these files. I have no idea why this is there, or who depends on it, but this has been there for a long time. And in this branch, you can actually see the current JSON files, which you can otherwise only get by building…
Felix (Geth):We do also, I think, deploy them into the… like, we deploy the… the most recent one.
Felix (Geth):into the GitHub pages, so it is also possible to download the current one somewhere from GitHub pages, the current JSON file. But for the releases, the problem is we need this, like, version thing, so we basically, we need a…
Felix (Geth):for every single tagged version, we need the canonical open.pc.json that corresponds to this version of the spec. And so that's where the release artifacts are gonna come in.
Felix (Geth):Actually, it's kind of interesting, we do have some existing tagged releases, but I'm not sure what's in there.
Felix (Geth):I think there's no… there are no artifacts in the current releases. The releases that were made were all made by Matt when he started this repository, just as a kind of…
Felix (Geth):I mean, no, it just has the default assets, it doesn't actually have the…
Felix (Geth):It's just the YAML files.
Felix (Geth):So yeah, these are old.
Chase Wright:Yeah, 2024.
keri:I think if we could start tagging releases, then that kind of solves the problem, too, of, like, that transaction pool.
keri:Thing that we were talking about, too, where we could, instead of, like, failing clients, we could warn them and just say, hey.
keri:This is coming up.
Felix (Geth):Yeah, yeah, that's…
keri:I'm gonna fix that. Yeah, yeah, okay.
Felix (Geth):Anyways, the whole plan with tagging the releases, we've just been dragging a little bit. We should've… like, we've been talking about it for quite a while, and trying to prepare for this, like…
Felix (Geth):the addition of the version, so several, like, while you were gone, like, some small steps have happened towards this, and so now we're kind of at the point where we feel like if we would tag something.
Felix (Geth):We can kind of make it work, but we still need to work on the actual pipeline, like, on the build pipeline.
Felix (Geth):That works with these tagged releases.
Felix (Geth):Because if we just tag a release now, it's not sufficient. We need to make a release, and then we also have to attach the OpenRPC JSON files to that release. We need something that downloads these files, and then builds the docs from the release thing, and so on, and none of that is built. Like, so the current PR just adds the drop-down, which is kind of nice, but also…
Felix (Geth):Yo.
Felix (Geth):Not really.
Felix (Geth):Cool.
keri:Yeah, I have something locally to run Hive off of a specific version.
Felix (Geth):Yeah, that's also nice. That's also another step that needs to be done, yes.
keri:Cool.
Chase Wright:Okay.
Chase Wright:Anybody got anything else? I mean, I think that… Pretty much covers… Today.
Chase Wright:Everything that was in the agenda.
Felix (Geth):Yeah, I will look into this one, yeah, into the error message one.
Chase Wright:Okay?
Mercy Boma Naps-Nkari:Sorry, I don't know if you can hear me. Yes.
Mercy Boma Naps-Nkari:Yeah, I wanted to ask about EIP770 to the set code, transaction.
Chase Wright:Do you have a link or something, or…
Chase Wright:What do you want to say?
Mercy Boma Naps-Nkari:And I don't really have a link, like… I was trying to look at, some of the test cases, because I was trying to, like, fill in some tests that we don't have, then I noticed that,
Mercy Boma Naps-Nkari:like, the… it's central transaction, and it simulated V1.
Chase Wright:So, what about it? Like, I don't know, I'm sharing my screen, but I don't know what… what I should do.
Mercy Boma Naps-Nkari:like, I'm talking about adding test cases for it, like, that's my point, like, the…
Mercy Boma Naps-Nkari:There is no, like, test cases for it on the test file.
Chase Wright:And… I understand. Which… oh, okay.
Felix (Geth):I… so for… you mean for EIP7702?
Chase Wright:This one?
Mercy Boma Naps-Nkari:Yeah, the…
Felix (Geth):No, it's not a specific issue,
Felix (Geth):It's just, she was just saying, in general, we have some, we have some missing tests.
Mercy Boma Naps-Nkari:It's not an issue, I'm asking about… is it okay if I should write a test case for it? Sorry, it's raining over here, I don't know if you can hear me.
Felix (Geth):We can totally… we can absolutely hear you, and I understand what you're talking about. It's not about a GitHub issue, it's about the general question if…
Felix (Geth):some tests should be added for it. I think for each send raw transaction, it's not super necessary to add tests for EIP7702, because we know that the clients accept all valid transactions there, so…
Felix (Geth):basically creating a test that… I mean, it's just another test that submits, like, a hex payload to this endpoint. We do kind of expect them to accept that, but it is just, like, a given. I don't think we need to specifically test that thing. It's not gonna increase the coverage by…
Felix (Geth):much at all. I mean, we could add that test, but it's just guaranteed to pass like any other. I mean, I would be very, very surprised if that didn't pass. That said, yeah, I mean, if you feel like for completeness' sake, it should be tested, that's the thing, but what was the other method that you would want to add it to?
Felix (Geth):It was…
Mercy Boma Naps-Nkari:That's justice.
Felix (Geth):I mean, you mean eSimulate as well, or…
Mercy Boma Naps-Nkari:No, I was trying to… I was comparing it with It Simulate, and then send raw transactions, like…
Felix (Geth):Yeah. Okay. Yeah, so for each simulate, I think we do actually have, some inputs, but that's because
Felix (Geth):eTsimulate has the… this is something we also figured out recently when debugging some stuff, so…
Felix (Geth):ETH Simulate is kind of the only place in the API where the… transaction… object…
Felix (Geth):parsing is kind of exposed in the tests, so what I mean by that is.
Felix (Geth):the… the… there are two representations of Ethereum transactions in the API. One is this, like, hex…
Felix (Geth):blob format that is used by send raw transaction. So for that, you just send a…
Felix (Geth):you just send a serialized transaction as hex. That's not very interesting, like, the client will internally deserialize it, and then process it, or whatever, but…
Felix (Geth):this is not very interesting from an API spec perspective, because it's just a hex string. But then there's also the other format used for transactions, which is used inside of
Felix (Geth):ETH send transaction, for example, And also in ETH Simulate, where when we are submitting the…
Felix (Geth):transaction, we are submitting it as a JSON object containing fields.
Felix (Geth):And so there, it kind of matters if, for example, we use the…
Felix (Geth):Because the different transaction types have different fields.
Felix (Geth):So, for example, the 7702, it has the authorizations.
Felix (Geth):which… Are not present in any other type.
Felix (Geth):So, it does kind of make sense to have test cases for these inputs, because they are specific to,
Felix (Geth):specific to the different transaction types.
Felix (Geth):It would be…
Felix (Geth):It would be kind of interesting. I mean, so this is also where, for example, this issue that you clicked on, Chase, there's this issue here that says authorization signature handling in ETH call. That is also related to that, because in ETH Call, we have kind of a similar pipeline, and we do also accept, like, the 7702 kind of payloads there.
Felix (Geth):So…
Felix (Geth):But I think we have sufficient coverage for that right now. So this issue is more about extending this, like, generic transaction, or this, like, transaction input to have, like, other stuff.
Felix (Geth):specifically for EIP7702, but what we have now is sufficient, actually. I don't think we really need to do this thing that the issue says, it's just more like a convenience feature, and so far, hasn't really been asked about much, so I guess it's okay. But definitely, there is this thing that for certain transaction types.
Felix (Geth):These methods, like ETHCALL, EstimateGas.
Felix (Geth):eSimulate, eSendTransaction, they will be… have to be extended with new fields. And then it also makes sense to add tests for them if a new transaction type is added.
Felix (Geth):But I think for now, the EIP7702, we have enough tests, I would say.
Chase Wright:I do… I do have, one other question. We have this issue about post-marriage-only clients, and this has come up a few times. I know we discussed
Chase Wright:the possibility of adding, like, profiles, right? This seems to fit… fall within that discussion. What do you… what's your take on…
Chase Wright:the… Clients that only want to support post-merge.
Chase Wright:Everything.
Felix (Geth):Yeah, I mean, there aren't that many differences in the post-merge versus pre-merge. It mostly comes down to these, like, older receipt formats with the post state root versus the status. The status, like, a very old difference, and then it's the question of.
Felix (Geth):Yeah, I mean… I guess that's maybe the only difference. The… in the API,
Felix (Geth):like, there aren't that many differences in the API over time, so we could actually get away with
Felix (Geth):Having a chain that only has post-match, and the only thing we would lose is support for these old receipt formats.
Felix (Geth):So… that's maybe acceptable, I'm not sure.
Chase Wright:So, like, if we create a profile that is… like, if we get to the point where we have profiles, we create a profile that is, like, post-merge-only clients, then I guess that means we're going to have to create another Hive chain, right? We're gonna have to create a new Hive chain that doesn't have
Chase Wright:pre-merge blocks.
Felix (Geth):Yeah, we could generate another chain. It's very easy to generate another test chain that doesn't have the post-merge blocks, that doesn't have the pre-merge blocks. There's a flag for the Hive chain tool that makes it emit, like, a post-merge chain. We use it in some other tests, so it's very easy to create this.
Felix (Geth):So, that is not the problem, it's just a question… and then, I mean, if you would do the… it is totally possible to, like.
Felix (Geth):on this issue now. Like I said, the only thing we would lose is maybe the support for some of the tests. If we want to go to the point of having the profiles, and then having profile-specific tests.
Felix (Geth):it's a possibility, I mean… But…
Chase Wright:That's a lot of work.
Felix (Geth):there's gotta be very, very little… very, very few differences in these tests, is what I'm trying to say. It's like, maybe it's actually not worth it. Maybe it's just not worth even testing this old stuff.
Felix (Geth):that is… I've been pondering this, at least, that I think maybe we should just give up on this and make it, like, all the testing post-merge, because it's more inclusive for the clients, and it's actually kind of easier.
Felix (Geth):But we do…
Chase Wright:Yeah, I fully agree with you on one hand. Like, I mentioned in one of the issues that the ref team brought up, because they wanted to change the target for one of the tests, and it was like…
Chase Wright:archae, like…
Chase Wright:people want archived data, and I don't… and, you know, even non-archived nodes can return receipts, you know, from, like, pre-merge blocks, in theory. And so, on the one hand, it's like.
Chase Wright:I totally understand not wanting to support the legacy stuff, but then, on the other hand, it's like…
Chase Wright:as a consumer of the API,
Chase Wright:the answer that you get to the exact same query is going to be different depending on which client you run, and as an API should just be a black box that returns whatever.
Chase Wright:I… I don't know, it's kind of weird. It's like sweeping the issue under the rug.
Felix (Geth):Yeah, I understand.
Chase Wright:Yeah.
Chase Wright:So… it's tough.
Chase Wright:Okay.
Chase Wright:I guess that's it.
Felix (Geth):index.
Felix (Geth):there is honestly… I'm… I'm just thinking…
Felix (Geth):Like, this… this one change that we did to the receipts, where we… where we removed the postage route and added the status.
Felix (Geth):It was one of these… very few changes.
Felix (Geth):That are like this.
Chase Wright:Yeah.
Felix (Geth):It's basically… it was kind of a one-off type of situation, where they were… they reused a field that was… that had a different purpose in the protocol.
Felix (Geth):And that has never happened again.
Felix (Geth):from that point onward, they only made additive changes to the objects in Consensus. It's just… that was the only time where they changed the meaning of an existing field, and that was mirrored on the API as well. And it makes it very awkward, because it's basically like a breaking change that occurs mid-chain.
Felix (Geth):it's, like, built into the chain that there's a breaking API change somehow at, like, block X, and that's… that's just very hard to work with. I think it was maybe a mistake how they pulled that off, they should have…
Felix (Geth):I'm not really sure how they could have changed it, but it was just kind of…
Tullio | Erigon:Oh, but, why are you saying that a field changed in the meaning? Because if I do recall, it was root field.
Tullio | Erigon:In the… in the receipt, and then status.
Felix (Geth):Yeah, yeah.
Felix (Geth):So they… I mean, in the underlying RLP objects, the fields don't have names, right? They are just…
Felix (Geth):They are just indexes into some kind of array.
Tullio | Erigon:Hell yeah.
Felix (Geth):We can say that, like, the value at position 3 in this list has a different meaning after block X.
Tullio | Erigon:Okay, in the RLP, but I was thinking about the JSON object, the problem.
Felix (Geth):The problem is that the JSON is not… you literally cannot… like, in Erigon, we were facing the situation where Erigon was kind of supporting the status, so it was basically parsing the RLP object, and then interpreting it as a kind of…
Felix (Geth):Object that has the status field, but that was incorrect, because you have to interpret it at the time of
Felix (Geth):Basically, you have to be aware, is this, like, a receipt that has a root, or is this a receipt that has a status? You have to distinguish that in your internal handling of it, and if, for example, it has, like, length 32, then it's,
Felix (Geth):it's a hash, so it's the post root, so you return it with a different name. But this logic is, like.
Felix (Geth):it's just very ugly logic, like, it was maybe a little bit of a mistake to add that to the protocol, but it's also so long ago that there is no way for us to change it, and there isn't really another way to do this. So, we just have to live with it now. But I'm just mostly trying to give this
Felix (Geth):Give this perspective that this is probably the only change like this, and that is the only reason why we have to have this, like.
Felix (Geth):compatibility all the way back in the tests, because there is no other part of the API that really is different over time. It's not, not like…
Felix (Geth):it's not like… I mean, I guess…
Felix (Geth):One other thing we could say is that, in theory, If you have a block.
Felix (Geth):if you do get block from an old fork, it's going to return less fields, maybe, or some of the fields are going to be null, whereas if you access a block that is newer, then these same fields will be set, because the fork has now filled them. For example, there's things like the withdrawals. Nowadays.
Felix (Geth):Every block contains
Felix (Geth):consensus, like, withdrawals initiated by the consensus layer. But in earlier forks, there was no consensus layer, so these withdrawals are not present on the old blocks.
Tullio | Erigon:Yeah, yeah. And also TDD has the same.
Felix (Geth):Yeah, but the thing is, with the TTD, we all decided that we will just not have that anymore at all. Like, for example, in Geth, we simply do not serve the TTD for any block, regardless of if it's old or new, because
Felix (Geth):We always had to keep that as a separate index, and then.
Tullio | Erigon:This index is for you.
Felix (Geth):Yeah, so we basically just retroactively removed it from the API, even for the old blocks. So that is also a possibility, that you just, you know, we just…
Felix (Geth):Choose to remove something.
Tullio | Erigon:Okay.
Felix (Geth):And… and we're not gonna come back and be like, oh yeah, we have a testing profile where it checks the TDD, like that. It's just… this is just… I mean, we considered it, but it's, like, annoying, because then we have to… yeah, so we're not doing that. But for the blocks, it does actually kind of make sense, for example, to be able to support a block that…
Felix (Geth):doesn't have a certain field, because it literally doesn't have that field in the underlying representation as well. And I do think we have some tests for this, but maybe I'd have to lie, maybe it's actually… I'm not fully aware. I think we do some checks.
Felix (Geth):I did, at one point.
Felix (Geth):consider adding tests for… that does, like, get block on every fork, but I'm not sure if I ever was… I ever landed that.
Felix (Geth):Let me actually check.
Felix (Geth):Hmm.
Felix (Geth):Yeah, no, I mean, yeah, we do, yeah. So we have, get block London fork, Get Block Merge fork, Get Block Shanghai fork, Get Block Cancun, Get Block Prague, and so on. So we have them. But we mostly, like, the London one, I guess, is the one that's pre-merge.
Felix (Geth):So that is, like, the other thing. And these tests should, in theory, return, like… so the point of these tests was to ensure that if a field is added.
Felix (Geth):To a later fork, then it's… we have to figure out how this impacts the old block, so that's why we have these tests, to make sure that the clients don't accidentally add some information into their block when… when it's not actually present in the underlying data.
Tullio | Erigon:Anyway, just to be clear, I'm not against removing the root field from the JSON RPC representation, even because having it just
Tullio | Erigon:I mean, removing it would allow me to
Tullio | Erigon:delete some weird code that we have in Erigon, so I… I would be happy to.
Felix (Geth):Yeah, but we don't really want you to delete that code, right? Like, that's the whole thing, it's like…
Felix (Geth):We don't want to… we basically wanna stop testing it, but you're still supposed to have that code, because… Okay.
Tullio | Erigon:Yeah, yeah, yeah, I can, I can.
Felix (Geth):You have to give, like, the… the… that's, like, kind of the… so maybe that's an argument for not removing this.
Tullio | Erigon:Yes, yes, exactly. I mean, if I need to keep the code, then I'd like to have the test
Tullio | Erigon:for that code as well, maybe with profiles. Or otherwise, if we decide that we don't want to invest into profiles for testing and keeping the test for that code, then please let me throw away the code as well, because keeping the code.
Felix (Geth):Chaos.
Tullio | Erigon:I mean, the test is the worst option, in some sense.
Felix (Geth):Exactly, so that's why we are in the current situation that we're in now, where we basically decided that we will not
Felix (Geth):The clients which do not support pre-merge.
Felix (Geth):they just literally cannot pass the test right now, because the test requires this compatibility. And I also just checked it, and it's also the same as for the,
Felix (Geth):get blocked by number for, for example, the London fork. So we have a test there for… that… that… that requests a block… block at the London fork, and this, block
Felix (Geth):contains
Felix (Geth):several, like, it contains some fields, but it doesn't contain, all of the newer fields. So it is, like, important that this test basically is preserved as is, so the API has the semantics that if, for example, the withdrawals are not present.
Felix (Geth):from the consensus layer, then they are simply omitted from the response. And I think that's also something quite important, whereas if you request a later block, it is going to have the withdrawals present, and if there are no withdrawals, it's going to be an empty list versus the field not being present. So I think that's also something important, that these distinctions kind of matter.
Felix (Geth):And they have to be… echoed by the tests. So the get block… London…
Felix (Geth):Would also be broken if we… Remove this.
Tullio | Erigon:Okay, so do we have an issue about this profiling feature in…
Felix (Geth):We were kind of gonna work on that after we got the… so there are two things right now. One of them is, like, we're having a pretty hard time getting these, like, released versions together, so that was, like, the priority number one, was to just make sure that we can actually do the versioning. And once the versioning is in, we can start working on the profiles. I didn't want to mix the two, because we were.
Tullio | Erigon:Oh, no, no!
Felix (Geth):Such a hard time.
Tullio | Erigon:Of course.
Felix (Geth):We're just getting chipped.
Tullio | Erigon:No, no, no, I was just arguing that we could have an issue for the profile feature, and then refer the issue into this other issue, because it's a dependency, basically. This can be solved when profile issue is addressed.
Felix (Geth):Yeah, that makes sense. Yeah.
Felix (Geth):I think that makes a lot of sense, yeah.
Chase Wright:So the only thing that I'm wondering is, like, I think it's okay, right, if…
Chase Wright:Ethrex or another client is… if the test exists and it fails, okay, so it's at, like, 99.99% pass. Like, I think it's fine, but, like, this particular issue says that their client literally cannot
Chase Wright:import the chain ROP, and I think that… that prevents them from even, like, starting, right? And… and.
Felix (Geth):Yeah, that's true. They cannot load them, because the test chain has the fork spaced out by, like, one or two blocks, so it's, like, every second block, there's, like, another fork.
Felix (Geth):And they don't like that, because they need all of the pre-merge forks to happen at block 0. But if we do that, then we basically don't have any ability to request these earlier…
Felix (Geth):that's kind of why… why I implemented the spacing with the forks, is because… so that we have some block where we can actually request some, like, old data, and it's not just all, like, the new. So, it's just… I mean, in some ways, it's just a limitation of their software that they cannot import it.
Felix (Geth):They could kind of import it, because there's also the post state, so they could technically just skip importing the chain and just import the…
Felix (Geth):the states?
Tullio | Erigon:The post-merge blocks, yeah.
Felix (Geth):Because they can also snap-sync, right? I mean, they can snap sync to the current chain, and the current chain is also
Felix (Geth):a chain that has a pre-merge prefix, so they could technically do the same operation, and just, like, load the state, and also load the chain, like they can do now, and then they could serve all the API. I think that's actually…
Felix (Geth):That would be another valid way of doing it. They just cannot, like, full sync this chain, because they don't have the EVM rules implemented for the earlier forks, but they have the ability to operate on a chain that has emerged in its history, I think.
Tullio | Erigon:Yeah, yeah, I do agree. They should skip the block that they not support, and deal with the rest of the chain.
Tullio | Erigon:And then not answering… not answering API before the merge, but…
Chase Wright:Is that a limitation of our current… Hive pipeline, then, that…
Felix (Geth):I mean, I guess so. I mean, the one thing is that we basically supply the clients with the…
Felix (Geth):We supply them with the chain.urlp file, and they have to process that to get the state. They have no other way to come up with the state than to process the blocks. We could… yes, in some ways, it is a limitation in Hive. We could…
Felix (Geth):give them the poststate.json, and just expect them to load it to their dataBesu, but I'm not sure if they have a code path for that, honestly. I don't think any… I mean, I'm not sure if any client supports initializing the state from a JSON file. It's not
Felix (Geth):operation.
Tullio | Erigon:And then, from another point of view, if… if we were to…
Tullio | Erigon:I mean, do the DRLP, the chain RLP for mainnet.
Tullio | Erigon:That would be obviously huge, but with exactly this structure. The merge at the same point, not at zero.
Felix (Geth):Yeah, it's a bit… I mean, yeah, so… basically, we don't have… we don't give them… we could launch another client that supports the merge, and then give it to them, and be like, hey, just snap sync from this one, and then we can run the test. Like, we could… we could do that, basically.
Tullio | Erigon:It's just zero.
Felix (Geth):launch Geth, it'd be like, here's the SnapSync endpoint, do your thing, and then we can test the API. Maybe that's how we should… that's maybe how we should implement that, I don't know.
Tullio | Erigon:I don't know.
Felix (Geth):It was just an… just an idea, but it's not that trivial to implement. We just, basically, we're not prepared for these kinds of clients, because we just expect that all the clients can just execute the blocks and…
Felix (Geth):You know, get… that's, like, their main… the main point of the client anyway. So, I think it does kind of make more sense with the profiles in some ways, because…
Felix (Geth):that…
Felix (Geth):But how exactly it's gonna look with the profiles with this issue, I'm not sure. To be honest, I'm not really sure how it's really gonna be.
Felix (Geth):So we also have to see that then.
Tullio | Erigon:Yeah, this would require profiles implicitly to also have different chain RLP, not the same chain.
Felix (Geth):Yo.
Felix (Geth):So each profile would have to have their own tests, and the tests would have to be generated on top of a custom chain. It's not a… I mean, this is kind of possible for us to do that, because the profiles are literally, like, the way we see the profiles, at least in the idea of it, is just for them to be a complete copy of the spec.
Felix (Geth):which… I mean, in some ways, the profiles are just, like…
Felix (Geth):how we generate the spec from the sources, because we do expect that the source files, like the YAML files, they will be the same.
Felix (Geth):we will have one set of YAML files, it's just that we can generate different outputs from them. So we can generate different OpenRPC.json, we can generate different, different tests, and so on from the same sort of…
Felix (Geth):thing just is gonna be gated by the profile. Certain things in the spec are only enabled in certain profiles, and by that, I mean certain methods are only in certain profiles, maybe even… yeah, I'm not sure.
Felix (Geth):this is actually kind of an interesting question. If we did have this profile feature, would we be able to say that a method behaves differently depending on profile? So, if we have, for example, the post-merge profile, then the, like, getReceived
Felix (Geth):kind of has a different response type, because we don't allow… I guess that's not really how we want to handle that, that's gonna be really complex.
Felix (Geth):Yeah, well, whatever, like, it's interesting to wax about it, but we will get there.
Felix (Geth):Just not now.
Chase Wright:Okay, that sounds good. I don't know, maybe we can, maybe we can get Ethrex people to, join the RPC Standards Call in the near future. That would be cool.
Felix (Geth):I mean, they would probably be quite happy to be around, yeah.
Chase Wright:Yeah.
Chase Wright:So, I'll reach out to them, see if, anyone wants to participate.
Felix (Geth):Nope.
Felix (Geth):Nice.
Chase Wright:Alright, well, I guess that wraps up… wraps it up for today. Thank you everyone for their time, and see you again in 2 weeks.
Felix (Geth):Yeah, thank you.
Tullio | Erigon:you all. Bye.
keri:Bye.
Chat Logs
No chat logs available