eth_simulate Meeting, Feb 24, 2025
eth_multicall and eth_simulate Meetings · 24 Feb 2025 · 13:40
A meeting of the developers working on eth_multicall and its successor eth_simulate, held on 24 February 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
uh I have been with working with the test cases with with CA that there was some changes in the get and or the places that we need needed to fix and not those are fixed and the test tests are running again that's my updates I if she has anything uh so yeah I mean apart from what you mentioned uh Kari and I can also share that um gu merged my PR for for fixing the parent block hases so hoping that will fix some of the test cases for me uh I need to syn with deep T through but didn't manage due to time
differences on the tracing PR but I think it looks all right it needs some polishing but it's like should be good to experiment with if you uh killer I want to check how it works yeah there was I noticed on the documentation that the how it's being C is quite different from each simulat I think it would be preferred if it would be kind of as similar as it simulator of input and output as possible except with added of tracing stuff um is there some serverware which I can use or do I need to I guess I should inst NE my to no we don't have a server
with it no sorry can you share the pi uh yeah let me find the pi and I guess Cena should take a look at that as well if that's something that looks good or not yeah I think uh once we have kind of the design dog updated then happy to look at again I sh it in the telegram okay for traing for E Cola I guess get somewhat Allied on what it looks like or
is the specs for that right different yeah it call should be similar might be some minor differences especially on error codes maybe not ER code but messages codes should be the same that sounds good have we decide what to do with the gas estimation stuff that's something I think still it's open discussion what should we do there didn't we have a tentative agreement uh from last meeting I don't remember exactly what it was but we had we had a set of options that we said we
would think about okay and I guess everyone spent the whole week thinking about those things certainly okay those are the that's not great and did we agree that we make a V2 version with this support or something else that sounds good to me should we vote on those options then what should we do I think C want that the global gas lag and then M was against that that's time yeah I feel like at least Interceptor we have use cases
where we do not want that right or you argued I guess Kari that we have use cases very close to not where it's bad but in actual we yeah our use case would have problems with that right we' be way overestimating oh estimating on what what at the moment we make multiple calls but yeah if if you could just estimate one of the tri well you could estimate one triction then and overestimate a lot on those where we had checking balances and that kind of stuff I think it would work in the Interceptor and we wouldn't need to estimate those stuff so I think interor it be always enough to just estimate one transaction right exactly if there is a
global that would be problematic for us because we never want to estimate anything except for the um top trans transaction the stack right but we could always set the maximum gas limit for the for the other stuff or from the previous run set the gas used value so the are we assuming that I see so you if you provide any gas limit then it would not run the estimate like there's no way to estimate with the starting gas I think it would only do the estimation for those where the gas limit is missing otherwise it's using the user provided gas
limit let see but but if it would estimate all the transaction then I don't think that would be a good idea at all I think you still need to be somehow way to pick which you want to be estimate and which are not one way of doing is that you just give gas limit to everything else that that is not estimated I think the sinus idea was that if the that flag is set then it changes the behavior of what does it mean that the gas limit is missing at the moment we have that kind of logic how the gas limit is estimated if if it's not set yeah and that that flag would would no way change that
behavior yeah I I don't know if there's some some other use case it would be nice to get feedback from other users as well has Cena reached in all those other providers I think they would also have some preference on on this last time we had one one person from there but he didn't seem to have that much opinion in either way and and I think this success of the gas limit estimation came from those other providers is Interceptor works even without it but it's not perfect but it works and but other the providers they were more prefer that they want
some option for this okay so let's do it this way then then we um I mean I we can together kilari write a short dog uh with the current proposal whatever it is like let's just agree on one and then take it to them I think it's easier this way and then they can complain if there's something they don't like yeah yeah that is the best way to get things done I think they better that that we make an implementation then they complain it's wrong that takes longer but but which which which of those Su should be
made I don't know if nethermind has any preferences how it should work I would like it so that you could always specify which transaction you're estimating and which are not I guess that's the second last option which I would prefer oh what does mean Max gas estimate is gas limit you mean that you said gas limit and then the estimat and then it's always would never spend more than the gas limit yes it would do an estimate with the starting number being the max being whatever you set the gas limit to oh but but then the estimate could res end up being whatever yeah so it would still try to
estimate it but it refuse to go over whatever you set for gas limit and so the way the bisecting would work is would first start out by running a transaction with the gas limit and if it fails it just it's done doesn't even try it again if it succeeds and returns anything less than gas limit in terms of gas used then it will tra rerun with that lower amount but I guess that's very different from how it's be has e on on those other methods as well um yes I don't think estimate gas I think estimate gas just ignores the gas limit field entirely not actually sure about that I think that's quite confusing for the user because you cannot in way know
is it helping or not or or why would you set the gas limit to some max value I mean you might have a rough idea about how much a transaction is expected to cost and so you provide that and um it decreases the amount of bisecting you have to do order to get hit a Target so it's cheaper but it's still hard for the app developer to know if it's helping or not I mean it's helping as much as if you get back a number that is lower than it is helping and the amount it's helping is the difference between the number you suggested and number you get back yeah I guess that it would be somewhat confident that you can get quite wide range of values depending on which if
you just recreate the gas limit by one gas then you can get a widely result if you set the gas on to one gas you're going to get a failure one one gas lower than some other value the the red gas can be very different if the gun of the trans is behaving weirdly no you're saying you might need to bisect oh but you get one one gas less you're done bisecting because you only have you have no way to bisect anymore and so you run it once you get the gas used you run it again and you're done yeah that the function is smooth and it's behaving nicely and not that there's some kind of weird behavior in the very specific case that you're
referring to where you set a gas limit to 100,000 and you get back a gas used of 99,999 you're you're done at that point because you cannot bu anymore I mean you estimate with 100,000 and then you estimate it with with 99999 and and those can result in very different kind of estimations oh sure I mean we still have the same problem as estimate gas always has which is yeah yeah the best you can do is bisect and hope that the user didn't do or the developer didn't do anything stupid yeah I think I would go go with the second option so just you pass the flag and if you pass both you just get an error nice and simple yeah and that that flag is for each transaction not not Global yeah what was your reason for disliking that one Cena
is it just the the way gu is architected it's easier to do a global I just find it concept simpler um and I don't think that the other options are particularly harder but it does make it a bit easier if you have the global fight yeah I mean I think even with a global flag you still have to decide whether to estimate gas on a per transaction basis right yes because if the transaction has a gas limit set so you still have to do per transaction gas estimation it's just a question of where does the flag live doeses the flag live outside or do the is the flag I guess is the flag do we estimate gas a combination of a Boolean
on the Block Plus a number or the presence of a field on the transaction or is it just dependent on a Boolean on a block or sorry a Boolean Boolean on transaction I suspect because of that the second one is the simplest to implement but that may be negligible compared to the other reasons for choosing one like conceptually simpler I would not be offended by either number two or the last one yeah because you aik yes if I was feeling better I would be very offended by one of those I don't
know which though well we can write some documentation which not about do and then I to propos to the other people yeah then let's take these two as leading options and yeah I think there's someone in our telegram that is or was using e simulate in like a a library we can run it by them because they're actually imping something I think you know who that talking about Clary no maybe it was somewhere in Discord you and I and this person had a conversation
about uh they were doing simulation type stuff in some library or yeah a few weeks ago maybe and I'm trying to think of people who may have an opinion and thoughts on design the couch not for me y same yeah talk to you next week then talk you guys next week okay thank you talk to you thanks bye