eth_multicall Meeting, Mar 24, 2025

Transcript

So is it tracing it simulate now live the metro mind or is that not released on the just merged but not released released just merged? Has she not taken a look at it? Uh, no I have not. You should agree on the specs of it and then probably write an execution spec for it as well. Mhm. So, um, there is another update from my side. I brought this up a while ago.

Um, but we have someone who is interested in adding the beacon route and withdrawals fields to the block override. And I am planning to merge this PR today. It would be nice if other clients uh would take a look at it and see if this is something they would also add. I mean, I we got a temperature check a while ago and I think everybody said they're okay with this. Um, so yeah, I'm just moving ahead with it now.

What can you do with them? Is it that you just get the correct hash or is it can can you do a withdraw and then can you do the transaction with with those that it or is it that that it is locked for some time or how does it work? You can pass in a withdrawal and the EVM will have to process it. There is not much to gain from it specifically like except for so block hash it's there's a completeness uh thing to it but sorry so this team is particularly

testing the ELCL uh connection so they need the full-fledged simulation and this is part of it. But can you do the withdrawal and then can it don't transfer it? It just you just initiate the withdrawal but then you cannot actually exit I guess. Um I'm sorry I didn't understand the question. I mean with the withdrawal I guess you are not getting the ETH out yet. It's just a request that you want to withdraw. Oh no. This is a request from the CL. So the EL will actually deposit ether to the the accounts. So there's an ET transfer being done. There is an e transfer being done. Yes. And does that

producing log? Uh oh that's a good question. H I think I feel I feel it should but is there some kind of is it some kind of special kind of transaction and that's why it's not being tracked. It's definitely not a transaction. It's something that's done as part of the inherent block processing. Um, and and I guess then it's really difficult for us to make a log for it because we don't know really where it goes because all the logs are under each transaction. We could make a log that comes from the deposit contract and to the user, but then we would need a transaction

that produces the the log. At the moment we don't Oh, you're saying we have no place to put this log. Yeah. Uh yes, our structure doesn't handle block level logging because that kind of thing doesn't normally exist in the Ethereum that block cannot produce and logs. I guess that's bit annoy that if you want to track where the ET is going then you have to figure out the withdrawals separately. Yeah, I agree that this is um this is annoying. We have to find a solution for it.

And I guess when you do withdrawal, you don't really know how much it is being moved either. It's not something that you could easily see that if there's a withdrawal, then you know it's this amount of ET. I think you you know this. And I guess you have to make a curious before the withdrawal is made at how much it there is and then if the withdrawal is triggered then then you can maybe deduce it. Well the the assumption is that the CL will feed us correct information. Um but when you run the age simulate you don't Yeah. Yes.

I don't know how we could add log for that unless we make some kind of phantom transaction but that also feels very hacky unless we add some kind of new new field that would be somehow log produced logs but that also seems quite weird. I would prefer the second one as part of a general push to get logging of all ETH transfers into the system. I guess this is the only place where the block could produce logs. I I guess the vo cannot trigger it any smart contracts or anything like that.

No, the withdrawal cannot initiate code. Um I I so like to go back to the error thing. So basically if we will uh add the balance by the given amount regardless like this is not something we check. So like when you see the withdrawal this is not something that can fail on the e side. You can know that this will happen. Can you pass any hash there and it will always pass it. There's no checking or anything be done.

You can you can pass any value there as only the address has to be valid of course but that's um yeah done in but how can you make the it transfer is that then you always make the transfer to that account but you don't do any checking for that checking for what that there's an eight in and the withdrawal is in the The thing is that the the ETH is coming from the beacon chain.

Oh yeah, it's minting. Yeah, as far as the E is concerned, it's been minted. It's just account balance plus equals whatever. But how do you know how much is being minted? That is that is a field. The withdrawal object, it has a field called amount. So yeah. Okay. then I don't see this as a big that big issue because you can read from that already how much is being moved. So the person who is making this thing should already know how much it is being moved or mean that yeah so I don't think it's that important then that there's a log for it. Yeah, agree.

I thought that you were tricking some object and then depending on the state of the chain that depends how much it be made, but if it's a straight with a field that you can see, then I don't then I don't think it's that important. I I agree that it's not critical. It would be nice though if um if a user is trying to like replay a block or something, it would be nice if we logged these. Uh, but it sounds like it's going to be a pain because you don't have a place to put it and so I'm okay with ignoring that. But if you're replaying the block event, then you can see in your each statement how much is being minted. So too many pull down. It just means anyone doing this has to write code that checks both places. It's the

same problem we've had with Ethereum for a long time where it's very hard to um do like a full audit of all ETH because there's a bunch of different ways you can get ETH and they're not all logged in the same place. Um, it's just kind of a continuation of that same problem. And I'm okay with kicking the can down the road yet again. It would just be nice if one day we actually solve that. I guess I don't have when the self destruction kind of goes away then this another way to move it to some place that shouldn't get eat I guess.

Yep. just there's there's always one more way that we someone can move ETH that isn't accounted for properly in a lot of tools. That's all. Again, it's not a big deal. I think we can kick the can down the road. It's not going to break anything horribly. Just you cannot have a smart contract that cannot receive it because of these things. Yeah. So, I guess we should add this to the spec adding these kind of things. Yeah. Read viral object. I thought we had something like that but I guess it's only what we are returning but not something that you can override.

Yeah. So yeah, there will be two extra fields in the block overrides object and you feel this should be part of the V1 and not not V2. I Yeah, I think so. It's a backward compatible change. Um the other change that it will kind of incur is uh we do return the beacon root hash in the header of the blog and now when there's this block override then we have to also update that of update it in the header but I think this is a minor change.

Is there still anything else that we are missing in the overrides that or something that they couldn't replay old block or do you think this didn't have all of this? I think if I think about the withdrawals before but we didn't see any use on adding them but I guess now there's a use for it. Exactly. What does the bas think about this? Sorry I'm too out of touch to have a qualified response. I'll have to get back to you on that unless Mercy has an opinion on it. I know Mercy's been looking at some basic stuff. I don't want to speak for you though.

To be honest, I phased out. Can you give me one sentence recap? Can you should I explain it? Basically, just to withdraw us to the state overrides. That's it. The block overrides. Yeah. Mhm. Oh, yeah. Yeah. Yeah. I remember I remember that we were discussing that. Yeah, we can probably add that. I don't see any major problems. Is there any spec for it already or? I haven't written anything at least. I don't know if Cena has anything for that. Uh, no, I don't.

It would be good to to write at least some basic spec just not to basically all the names of the fields is the most important one and decide what those are. Yeah, for that [Music] I can share what we are using or I mean it's not merged yet. So um I didn't hear have you had time to work on the shim or the uh phrasing stuff? Uh no sorry we do have a request now uh in guest to add a new method for a batch version of

create access list and it feels like another feature that can be added to v2 similar to estimate gas. We could also specify that if you want we can create the access list for you. This should just be a regular access list, not a witness. Yeah. How would it work? It simulate is that you run some simulation and then you want access to the list to be generated for some specific transaction and do you might also want to generate for multiple trans at once I guess.

Yeah, I think the use case is to generate it for multiple transactions. And the tricky part is that similar to estimate gas create access list also has to do sort of a binary search or like a iterative approach of like it will run the transaction multiple times to create this access list. So why I understand I understand how it's theoretically possible for someone to have an access list that is a function of the gas used and the gas used as a function of the presence of an access list. Yeah.

But it feels like a just massive waste of resources to support those obscure use cases. It feels like just do one pass, get the access list, return it, and if it's wrong, someone can go do it by hand themselves. I would love to tell you why we do it this way. This is one of those situations where I feel like, you know, if someone is going like we've told people over and over and over again, don't have your contracts logic conditional on the gas used. And we've talked about removing gas introspection specifically to stop

people from doing this. And so I feel this as well. Yeah. Yeah. UF is I think getting rid of some of this. I think one issue I have with this change is that that I I feel we should freeze the spec and kind of start making these things to version two but it seems like at the moment everyone wants just want to modify the existing one. I think I think access should go in version two.

It feels very similar to estimate gas like almost identical. Yes. What about the we travels? Should that be in the V2 or V1? With withdrawals, I'm a I'm a fan of in V1. It feels like it's just something that was missed in V1. And we've already talked to the clients and everybody that we've talked to has said they're totally fine with adding it. It felt like just an oversight in the first pass. There's something missing from our spec on accident kind of thing. All this year, there's always have been something missing from our spec. Sure. I think this this one is easy enough and it fits in enough. It doesn't change this one feels like it's easy enough and it doesn't change the shape

of any objects. It's um it's seems obviously missing like when you think about it you're like oh why is that not there versus like access list generation and estimate gas is something that um feel more like new features to me. Just as far as drawing lines go this feels like a pretty easy line to draw. Does everyone agree on this? When I asked in Telegram previously, everybody said yes. I think I believe that included Basu, Nethermind, Guth, and us by way of me. I overrode you.

Let's do it that that way then. Can Sina share me the some specs with the withdrawal stuff and then I can write it to the RPR? Yep, we'll do I do think we should related to that. I think we should mer the PR. Is anyone opposed to merge in this point or do we feel something? The same issue is with the test that I don't know also when those should be merged. Uh that's right. We want the tests to go in but I don't know which order those would go. They need to go at the same time. Oh yeah, that's a good argument. I think test should go first or at the same

time. We should have the test ready and passing in at least two clients if not three before we merge. Okay, I'm convinced. Anything else? Not me. Shina, can you look more into tracing stuff? You can maybe then write the spec if you agree on those things. It was done. I on the uh on the test since we're on the topic, we did have this issue uh

pertaining to the logs bloom. This was fixed on on G. Um, so this would be something to test again and see if there's still the mismatch between the clients. And the other one that was also found by Pisu was when we are creating the transaction object from the arguments then we are not um we are not setting the from the sender basically on the on the resulting object. So uh let's say I have a call

from account A to B. Uh this is my simulation and then I run simulate v1 and then I get the block result and it it has the full transaction flag set. So it has to return the full transaction and GU is returning an empty from field here and this has caused some mismatch to Bizu. I was wondering if you guys are like um what how is Nethermine behaving here and um what we can do here like in G codebase this is really tricky to do actually to set the correct sender.

Why is the sorry I think I missed something. Why is the sender missing? Like every transaction has to have a sender, right? So because when we receive the object from the user like when we receive the input the the user only specifies the the sender address not a signature and when I convert it to a transaction object then it does not have a like sender address it only has the signature so like kind of the sender address is lost in this translation but it's executed with the sender right it is executed with the sender. sender.

Yeah, the EVM executes with the center. It's just that the resulting object is missing the the the sender address. Is it missing the field entirely or you have it's returning like zero zero address. I see. And that's because just due to the way GU is architected, you just don't have that information at that point in time. Mhm. Yeah, I I mean I I definitely am sympathetic to um architectures be, you know, being different, but this definitely feels like we should include under even if it's hard.

Yeah, I'm not sure what's going on. If you can't do it deeper, you can always map it probably uh when you get the results right and just repopulate the sender based on the transaction because it's in order. Yeah, I guess I could do that. My worry is that I think people are going to expect that field to be populated and populated correctly and if we don't then it's going to lead to a lot of user confusion. I think the returning zero is even more painful than not returning at all because it feels like it's coming from the zero address.

Yeah. Okay. Um yeah actually what I think I will do what uh Lucash suggested. So yeah I do have a path forward now. Excellent. Is Basel now passing all the tests or agreeing with the death other than these things? Uh, I'm not sure about that. Sorry y'all. This is my first time joining one of these meetings. I'm just kind of lurking. I will be better next time.

No worries. I'm glad to see more people joining even if they are only looking. Um actually I can elaborate on that real quick if you have a second. My ulterior motive for being here is there's also calls regarding RPC improvements in general. So I want to be aware of how this process is working and see where there's overlap and there's things that can be improved or that um e simulate is pursuing that broader RPC improvements could learn from as well. I think the thing to learn is get at least two clients to implement your proposed RPC and then go tell everybody

we did this you guys should all do it too. Yep. Yep. Um I will send you a copy of my ETH Denver talk which essentially um comes to a very similar conclusion. Micah to discuss. I I would love a better solution but that that is the one that currently works and in decentralized systems sometimes we have to accept what we what we get. What do you feel like would be a better system?

Oh, I don't know, something where we had, you know, I'm in this position where, you know, I'm a huge fan of decentralized things, but I also recognize the massive value you get from having centralized leadership where you have a CEO or a CTO that says go build this thing and all these teams go and work on that and they integrate properly and they schedule it together, etc. Um there are huge benefits but the disadvantage there is we have no centralized leadership that tells us what to do which you know has benefits but also downsides. This is one of the downsides.

Do we have anything else to discuss? I do not. Okay. See you guys next week.