eth_multicall Meeting, Sep 30, 2024

Transcript

all right I think today will be a short one and so let's begin so on our side we finally cracked the needle the issue with sorry for that I'm probably also sick um we corrected the needle with the Contra destruction issue and through that found even more serious sorry for that even more serious one and now it is fixed uh uh and being fixed so we'll finally be able to update it properly and we'll be having more correct view on the block data set so uh that's it with us for now hoping for a

release soon and yeah that's it um I'm not sure I CAU that exactly so yeah we had did you find the time stamp issue or was this was some other issue no no no that was a bit more severe issue so the point of the issue was we have a contract it has a destruction call the destruction call is called and upon destruction call we need to in the code of contract transfer funds from the contract to the col for example and the issue was that we had no I didn't like no in information for the user of e simulate that transfer

actually happened so basically the log the this additional log that we created did not appear on such particular case and it appeared to be quite a deep rabbit hole that we died with lash quite deeply and now we are finally finishing at so yeah it's not related to time or blocks really from that side of things it is more related to how like uh evm event was passed down okay gotcha thanks um yeah as for me um not a lot to uh to report U Kari opened a PR against G to

our documentation for a simulate B1 I was reviewing that and we got that merged uh yesterday so that's done um something else was as you guys saw seems like rest implemented is simulate and we were trying to add them to to our hi testing setup so um yeah I wrote a patch to Hive so that they are included in the tests and um it seems like I mean killary would be the best person to comment on this but seems like they're not too far apart from our results just the the structure is somewhat different

maybe it's a bit older um but seems like we agree on a lot of things so that's uh good news do I agree on hashes no no I'm pretty sure that's uh that's G to be the last thing that would be actually a miracle that would be cool that would be a miracle to like done it from the Geto that would be a perfect all right uh is there any place like where we can take a look at the current diff State maybe we can we could ask Kar when he'll get uh not sick and show it on the next stream or

something like that so that people are looking into what would see all right so any other news there was some discussion on removed field on the chat so uh could you could anybody like remind us what was this all about so the issue is that the logs provided by the ethet logs endpoint have a field on them called removed this only makes sense in the context of a subscription where U when you have a reorg it basically sends you log lines saying this is the log line

that was removed due to the reorg and then it's followed by log log lines that are um added in their place um that doesn't feel doesn't really make any sense in the context of eth call or E simulate because you can't reorg in those cases and so the field doesn't really make sense but the counterargument is is that it's nice when you use the same structure for multiple things even if they're not you know totally the same if they're close enough and so the question is is do we want the structure of the log to match the eth logs call including the fields that don't make sense for eth simulate or would you rather have e simulate to have its own structure that is slightly

different would it then then mean that we would have e simulate logs yes we already do this these are the uh event events is maybe called NE mind I don't know mhm and we already do have those right like they're part of the response MH yeah so the question is just do we include the removed field in those are not it would always be set to false if we did include it oh yeah then it's just just an API structure question my my personal preference is to not include it since one structure is a superet of the other

in most languages that's pretty easy to deal with where you just have the kind of space structure and then the other one adds Fields um and so it doesn't bother me too much but I can appreciate the argument for having them be exactly the same also I think G May currently include the road field and so think is that true Cena I I believe so yeah because we use the same uh struct the same object type as these G logs so I think also like my so my slight preference is towards having the same structure and even in the in the if

simulate specs to directly reference the log type that is defined for E get logs I think we should try for consistency here the other option would be to specify that field as an optional return field meaning the client can decide whether to return it or not and if it is returned it will always be false so we can just specify it as it's either false or missing and they both mean the same thing so that way people who are implementing the other side of the API so Library authors and whatnot know that hey sometimes you might get this value and if so you need to deal with that dealing with that may just be mean

ignoring it which is totally fine or if you've got um but also sometimes you won't you won't always get the field so some other client may say not send it you need to be prepared for that and so this is basically saying acknowledging the clients may give different results because internal implementation details and the um the ethereum clients may give different results the libraries and whatnot that are interacting with those will just need to be aware of it and in terms of like using it when would be that situation that would set it to true so it's never set for to true for E simulate is only in E get logs because the way e get logs works I think it's get logs it's basically a subscription

so you tell the ethereum client hey anytime there's a new block send me the logs that match this filter if there's logs that match the filter in new block and it will do so every time that happens so you um it's particularly meaningful if you're on a websocket connection or some sort some persistently open connection though you can also pull pull and so what happens is excuse me sorry the ethereum client sends you a log that says Foo right and then the block that generated flu gets Fu gets reorg out and it's replaced with another block the ethereum client will say hey Fu was removed so removed equals true and then here's a log that showed up bar in the next block and isn't there

a that we can somehow have this in V2 in theory at least so that simulation of how the block was removed or something like that I mean in theory you could we could add it add complexity hypothetically what you want to do is you make it so when the user is giving you their um the E simulate call and they describe the the series of blocks they want they could say you know include this block and then remove that block and then proceed with these blocks it's a little bit of weird case it would be kind of useful for people being able to easily test their applications and make sure their applications work in a reorg scenario but it's it's a pretty limited value and it adds I wor you a

lot of complexity is it potentially needed on l2s or something like that uh the ability to simulate reorgs you mean yeah I mean it's useful just even for regular apps like it's a kind of it's one of those things that's like kind of useful you can imagine people doing something with it I'm just not convinced that it's useful enough to Warrant the extra complexity in ethereum clients implementing ethereums e simulate V2 MH so we have three options we keep it in and set it always to false we make it optional so for example re and

nethermind cannot have them or something like that or we can include them uh in some future for example release and make it dependent on like actual actual logic yeah or am I missing something I think that's correct okay let's think with it for for now I just type typed those three options into chat yay thank you hello

CB uh I'm leaning towards having it as optional field um I think having an extra field in the object is usually not a problem for clients to De serialize like if you have a yeah unused field in your Json object in JavaScript goal or languages that I know of when you're desizing that Json string then it causes no problem uh they just ignore that extra Fields um so I tend to say like it doesn't cause any issue um I would refer I would defer it to actually um to to the east get logs spec I'm not sure if this is I'm not behind

my laptop right now to check this but I'm going to do it as soon as I uh I'm at the keyboard to check how e get logs defines the log structure like is remove field included in there or not uh and I would just go with that yeah yeah let's make it optional for now uh we would vote also for it all right so with this I think I thank you so much everybody and oh yay you're here well no problem at all so probably if we are all out of topics uh let's see

each other next week