eth_simulate Implementers' Meeting #53

Transcript

I wonder if we should stop having these meetings if other people are not joining anymore. Everyone thinks things are ready. Uh >> maybe maybe we we can discuss that and see if it's we should just There we go. >> Hello guys. Hey. Hey. >> We were just wondering if we should cancel this meeting since we can't get anyone to show up for it. >> Yeah. Um, >> have you been able to push people to do things, you know?

>> Hello. >> What things? >> I mean, you reported those report the those bugs that we found last meeting. >> Oh, >> yeah. So, >> you didn't share them with the rep. I I forgot about it. No, I >> Yeah, >> last week was a bit chaotic. >> And then there were those nethermite issues as well.

>> I know if there's somebody working with the nethermind at the moment. >> Reuben is working, but I pinged him here. Not sure he will join but I don't know the details. I also just got back lately when I was absent last week. I still want um I still think that we need the estimate gas feature. I think it's kind of required like looking into future and talking about the call.

I feel like yeah momentum has been not there recently. Um but yeah eventually >> momentum of development or you mean momentum of people using it simulate? >> No development I mean mostly I think people will eventually um start using I mean I know some people are using it already but also yeah the option has been slow >> and gas is kind of like important as we talked with as like it was mentioned by

unis swap. Yeah, but the issue that our momentum has been slow that we haven't been able to get it simulate in a way functioning the same way and all of the clients. So then I'm not sure if we should introduce a new method when we old method is not functional even I mean I think it's uh functional now I mean most of the clients have it merged they are all working uh yes we do have some differences but

uh that's just like the normal RPC But we should we should try try to aim to be better than normal RPG. Yeah, I don't know how is that possible. Is it just a wet dream? But I don't have any solution on how that should be, how we would get it to be kind of better. Mercy, you wanted to say something?

>> Yeah. Um, okay. It's not necessarily in regards to it stimulate, but it's on this issue about standardizing error codes and then we we are doing some sort of a background discussion about it. We came up with two um possible solution. The first one is to spec a repository which runs a generator and then publishes types as packages like npm or create then for client developers to just install and use it. The second one we came up with is to like allow clients to generate types themselves using the provided tools.

So we kind of like looking for a better approach. Um if there is any impute on which will be much more better to go with. I'm fine with anything that gets maintained. >> Okay, that will be option two because the the drawback we had with option one was maintaining it to kind of like it has an extra maintenance to it. So key managements and package ownership and all of that. But with option two, the only um um kind of disadvantage we have is like requiring some kind of setup and willingness from client to run

the generator and integrate it themselves. So >> I feel there should be test cases so that you have for each of error code you have some kind of test that would produce that error then would somehow maintain that that those have been obeyed in a way. Yeah. So I don't know if anyone has any suggestion, feedback or possible I don't know.

>> I'm still just reading the proposal. about the proposal. We had um discussion then we had so many background discussion because we realized that there's so many things that can go wrong then we've not like really finalized I I think one problem with the JSON RPC is that it it's not conscious of critical so then people are not so kind of strict about that it behaves the same way on the on all of the clients that's why it doesn't also stay consistent.

Everyone have their bit their own rules and there's no strict rules how things should work. They just kind of that kind of general consensus on how in general it works but no nothing very strict. The one note about specifically execution errors is um I think it will be a bit difficult to get all the clients agree because depending on how detailed they are clients might perform some checks in different orders.

Um not all of the checks are at the consensus level and there is some flexibility within clients to do them differently which means that um in some very edge like edgy cases uh they might return different error codes. This doesn't mean that we should not aim for it. It just means that we have to find the right level. I I think in that case if you have build some test cases then then we could think that for some tests it it's okay that if it returns some error on some list or if if you are trying to send some e that you don't have balance then maybe they can be checked in different orders but

it should be it should fail to some of the specified errors but it doesn't need to fail on the same error. I think that's one solution for that problem. >> Okay. So in order to get what you're saying stressed um so in in other words we kind of like have to like spec a repo then provide a sort of a registry file plus a generator to that each client or project can then run the generator as needed themselves because this will now give them like a full control without needing to um have a library or kind of like checks that will fail during CI/CD pipelines or Okay,

there is a CI/CD pipeline. It's called Hive. Uh this is where the tests are run for every client. Um I think it what it comes down to basically is when we write the test for these kind of edge cases where clients differ then we would have to do something like uh Kilari suggested. Basically for some of the cases uh there would be multiple valid error codes. I think that should fix it. >> Okay. Thank you.

What's the website you're talking about? >> Trying to find the link. >> I'm saying economy. >> Uh, it sorts them by the different test suits. So, here Um so we have like RPC compat where it's simulate test are located.

Basically on top of the page you can see how clients like uh how many tests is each client failing and passing in like a nice summary. >> Oh you can see that the RPC compat aggregate but you cannot >> diaper per method. So maybe that would be >> that would be nice. >> That would be nice. >> Sorry, but it's not all clients. >> There's all clients there.

>> Yeah, only EF. >> Oh, okay. >> But for for example, for the error cases, those could also be added here, I feel. I don't know if hive supports that kind of that you that you you would pass it. I guess you would would pass test if it if it's some of the list of the error codes. So you don't have to kind of get exactly the same error codes for all of the things. Do you know who is m maintaining this?

if you could ask them to add by method if that's possible to do. But maybe that's hard to do. >> I think it would be a bit more tricky because each of these test suits they are completely different from one another and so you'd have to write a custom page for RPC compad. Um but yeah, I mean the repo is is the hive repo. This is where the code is. >> What is the disk V4 and disk five?

>> Uh discovery protocol like P2P >> for this five clients are not passing the test very well. I guess that's new. >> This five is new. It hasn't been rolled out by default to yeah all clients yet. I think the CL clients are running disk 5 since the beginning but EL started on disk before and uh yeah somehow the migration has been taking longer >> course

>> I guess in general more more filters would be nice to have for that but otherwise I think this is a very nice And I know I know if mer use this kind of tool. You would just need to write the test for each error case or multiple test for each error case. Do you have anything else? >> I don't have anything today.

>> I got a pink for from woman. We fixed some tests and we'll be fixing more. Like still quite a few of them are failing that we'll be fixing more. Great. >> Okay. Let's see. next week. >> See you guys next week. >> Sure. >> Talk to you. Bye. >> Bye.