eth_simulate Implementers' Meeting #49

eth_multicall and eth_simulate Meetings · 19 May 2025 · 14:58

A meeting of the developers working on eth_multicall and its successor eth_simulate, held on 19 May 2025. Client and tooling teams compare implementations and work on the specification for simulating transactions. This meeting covers a client implementation update and the spec for eth_simulateV2.

Topics

From eth_multicall and eth_simulate Meetings, hosted by Ethereum Foundation.

Transcript

So, looks like Cena's going to be a little late and Kari is going to miss. Anyone here from one of the other clan teams? I will take that as a no. Sorry, can you hear me?

Yes, I can hear you now. Okay. I wanted to ask would there be a need of joining this call with um the ROC standard call? Yeah, I just commented about that in Telegram. I my personal opinion is to keep the calls as focused as possible because I suspect there are some people who join this call who don't really care about other Ethereum RPC things and there are probably people on the Ethereum RPC call who probably don't care much about E simulate and so combining the calls I know is simpl simplifies things from a management perspective but I worry that there the people who attend the calls may not appreciate it because yeah I I was thinking the And

again I noticed that the RB scores was just for the execution API like general maintenance and then legion of pers and stuffs like that. Yeah. So if the RPC call I think there are a number of people who would like to help improve the RPC situation on Ethereum. Um I don't know if that's happening in the RPC call yet or not. I don't intend, but if it's just people talking about uh maintenance things and minor details here and there, I suspect there will be a number of people in this call who aren't interested at the very least.

Okay, thank you. Like for for example, Kari and I um don't work for any of the client teams. we work uh on another project that depends heavily on eth simulate but it doesn't really like we don't have a role to play in the rest of the RPC ecosystem. Okay, thank you. Hello Cena.

Hello guys. I think everyone else here is non-client teams. So just you sound like you had no updates. Uh yeah, there hasn't been any update for me. Um yeah, I'm just basically waiting to see if uh when we get test parity with SpU and Nethermines and then my goal is to push for the spec and test to be merged in the repos.

Uh yeah, I mean it sounds very reasonable to me. I think a while back we wanted to approach all core devs again with it. Do we no longer feel that's necessary or do you no longer feel that's necessary? Well, I I I would assume that approaching all core devs or one of these channels would be how we can push it to be merged. Um, okay. But yeah, I think it's we kind of need to get the tests uh passing together before Yeah. Yeah, I agree. Um hopefully I think on that front we're basically waiting for

Nethermind and BESU to move forward on that. There's nothing outstanding in GU as far as we know. Okay. I don't have any updates. Um and Clari is not here so no updates from our side. So maybe we can ask everybody else on this call if they have something they would like to bring up. Um Mercy brought up earlier before you got here um a question about do we want

to merge this with the JSON RPC call. My initial feedback just to reiterate was that I worry that the people who are attending this call may not want to participate in the RPC call and people who attend the RPC call may not want to participate in this one and so I worry that a merge may a merge of the two calls may result in some set of people being frustrated by lack of focus. Um but I suspect there's another subset of people who would attend both and would rather just have one meeting instead of two. Um so my preference is keep them separate but curious what yours is.

For me, what I care about is that the people who are attending now will keep attending. Otherwise, I'm if there's one call and I can attend both simulate and RPC, then that's good for me. I am also somewhat interested in the RPC call. Uh but it just happens that uh on Mondays I cannot at the current time attend. So So you would like the RBC call moved and you're uh ambival ambivalent as to whether they're merged?

Yes. Okay. Okay. Well, if no one else has anything, I don't have anything. And I don't didn't get word from anyone else indicating they're going to be late. So, I'm assuming no one else is coming. I don't know where BU and another mind are, but maybe just busy this week. I think I have something to say. The ARPC call is like it happens two times in a month, like bi-weekly, and it's by 400 p.m. UTC. No, 3 p.m. UTC rather. And there was a discussion last call about um getting project maintenance. I think

um light client um said he won't be focusing on on the ROPC um execution API repo. Then he mentioned about getting someone to work as a project maintainer or something like that because there are so many PRs that yet to be merged or looked into and then the front end aspect of the execution API also needs to be taken care of although some people from the GS team are also looking into it I think so and the general idea now is I might also be contributing to the stimulate call but I don't really know if how to go about it, how to go about um contributing to the

simulate call or how to go about uh addressing the problems that like client brought up. Um not the call itself, the issues like what you're working on it stimulate. Yeah. Um yeah. So for ETH simulate specifically, we basically just like the thing we need is we need I mean the thing we we need is Nethermine, Basu, Wrath, Aragon um to get their clients working with a simulate. Um I don't know how to make that happen besides just poking them every so often and saying, "Hey, what's up? Why aren't you guys done yet?" Um that is a hard problem. It is like

hurting cats. So, EC is an appropriate name. Um, for the RP more general RPC stuff, I think what is needed is somebody who understands the Ethereum JSON RPC well enough that they can meaningfully give technical reviews to those PRs. So, as like indicated, there's a bunch of PRs. People want to do a lot of things, but there's not really any process in place. And more importantly, we don't have someone who is a technical owner of that project in general. Like there's no one who has volunteered and said, "Hey, I would like to spend, you know, half my week just doing Ethereum RPC stuff and standardization." And

so finding someone that can is willing to do that um and has and and has a technical background to it. So the problem here is that the person you need for this job is someone who does have a technical background in Ethereum client development to some extent. Um or at the very least has a very strong technical background in API development. Um so yeah it's a it's a hard problem to solve. I I don't have any good strong advice for you. Sorry.

All right, thank you. One last question in general. Okay. Um, the last question I have in general since cuz I can remember I can recall from the beginning of this call client teams I think they're most um up to date with it simulate is best hardly best never mind and then get. So how do you like try to get other teams to work on this as in to know their progress and

also I there was a test that um that had issue that one client wasn't agreeing with the test or something that they had to like in fact sometime so what if something like this happens maybe when Aragon tries to join again how do you solve that I don't know if my question makes sense yeah so to solve the problem of if someone uh tries to implement it and they run into problems, I we definitely want them to bring it up. This call is a great place or the telegram channel is a good place to bring it up and discuss. There have been times where um GU GU currently, I believe, passed all the tests, but that's by nature of the tests were written from GU. And in the past, you know, when Netherm has had bugs, we discuss it with Nethermind and GET and

figure out who's right and then we update the test to match whoever's right. And so if someone has just like a problem with the spec in that or in the test in that regard then we just change the client that is wrong um which may be GU maybe another mind maybe someone else we fix it if they're coming in saying hey we don't like the design of this thing then it's a little bit late for that for Ethereum for e simulate v1 however for e simulate v2 you know we can talk about other options or e simulate v3 etc and so we can make changes in future versions As for getting other clients to actually participate besides GU Nethermind and Basu, um the only way to do that is begging and bribing basically just go

around and ask people please uh please implement this thing. Um hopefully as more and more apps and wallets start utilizing E simulate and I have seen some um do this there will start to be more demand for this feature and as there's more demand from this feature from users hopefully that bubbles up and eventually teams like Aragon and Reth will implement it. I think Reth actually has started implementing it if I remember correctly. I don't know how far they got though. I think has a functioning implementation as far as I remember. I remember that they were disagreeing on some things uh in the beginning. I'm not sure what is the state because they never participated in

the call. Um and I don't believe so I think this is a t like takeaway for me. I don't believe that we are running and basu as part of our CI flow. I think actually that would be nice if we can see what is the status of all the clients then it would give us some observability and we could we would know which clients to nag basically. Yeah. So maybe that's the answer is if there's anything you can do Mercy or if you know anyone that can do this to reach out to all the clients and get them even if they don't implement e

simulate just get their clients in do they need to get into hive specifically Cena or are all the clients in Hive but they're just not hooked up to this particular subuite. Yeah, we have a fork of hive now and we just um yeah we if they are on a branch then we would need to know which branch um otherwise I think I'm not sure if Bizu has actually merged this in in the master branch in which if in that case we can just add them now. Um, so is this is this something where you just need to like add a line to our hive? Yes. Or and say basu enabled type thing. Can we just

add can we just add basu ref uh an aragon and just say will fail and then we can maybe just send them and say hey guys look you're failing come fix come fix your bug and maybe that maybe that's as simple as oh you're looking at the wrong branch and then we can fix that easily. Yeah. Yeah. How about that? So, let's do that and then maybe in case in Telegram um and then maybe Mercy or someone else can help us try to get in touch with the other client dev teams that are currently failing and help them a little bit.

Okay. Anything else? Okay. I'll see you guys next week hopefully. Another mind base. Talk to you guys. Bye. Bye.