eth_multicall Meeting, Dec 16, 2024

Transcript

yeah CA has been discussing that he would want gas estimation to the each simulate and then we have be discussing should that be the new method or should be building right into the current version and I would imagine that we should be change the spec again to add that so or in that case should be a new method but then it's bit annoy because then you have to run the new method and then you need to run the each simulate after that even though it could be just one call each simulate you do everything how would it look if it was integrated would they if you leave the gas limit out then it would always estimate it for for that method and

after it has estimated then it kind of includes that in the transaction then it would continue it the processing so you could do the do the gas estimation for multiple transaction a row at the same time yeah I don't think I would do it that way because there's um estimating gas is not cheap and I would worry that doing it every time is unnecessary since most of the time you don't actually need it like anytime you're just doing a call just to get State yeah and we thinking of that there could be a client parameter where you got limit how many transaction it can estimate it for and then we could agree on some default for that but yeah I I

think for cases where you just want to use as a call and you don't actually want to make a transaction then you would be estimated that gas for no reason why would be just using some kind of maximum amount of the gas yeah well then well then it could be that instead of setting gas limit to undefined you set it to some string value or something like estimate or something like so it would be more explicit about that that would be okay with that like make it so within the e simulat possible to tell it to do a gas estimation I'm just not fun of that they keep modifying the spec all the time and keep adding stuff to that and at some

point we should just just make the H simulate V2 and then add stuff to that so I think if the changes are if the changes are purely additive then it's possible to do without versioning to next youth simulate but even with with that then son RPC is supporting each simulate you don't know which version they are supporting you just know that they're supporting V1 which would be any of those versions right this gets down to capability detection and some sort of handshake with the RPC server so you can ask the RPC server do you support X Y and Z ahead of time so that way you don't have to probe for it unfortunately as even though many people have asked

for that over time no one has ever written a spec for it and so we don't doing that and I think even that it would be difficult then you would you asking to do support each simulate and then do do support this features of the it simulate so in that case I think it would be also better if it would have it simulate V2 I hate building a whole new version of something just for you know one feature that you could could add no one option would would be to create a new method where you just estimate gas with and then it would would return just the gas amounts and it wouldn't return the

actual result of the simulations but I feel it's a bit waste because calculates those anyway but it doesn't return them but I guess that's what the current it estimate gas does that it throws away all lot results that it could return return to the user uh yes which is very frustrating for app developers so I think we we should why do you mean it frustrating for well not they need to run each simulate first and then they run the set transaction so there's two round trips or it could be kind of like only one it's just overall wasteful to in most in many cases maybe even most cases you need to do two things one you want to

find out will this call succeed or not so if it's if it's not going to succeed I want to surface that to the user with as much information as possible such as error codes or things like that um and then two you need to know if it's if it does succeed how much gas is it going to take so I can properly construct the transaction and right now apps have to do both so they have to make an e call and then they have to do an E simulate sometimes they'll just do the E simulate because the E simulate will I think these days return at least the revert reason but you don't get the other details that e simulate would provide such as um event logs and uh transfers and stuff like that and so I think that especially with e simulate where we're

returning more Rich data for the simulation unlike e call which return very bare B data I think people are going to often want to do an E simulate at on the app level and they're going to want to do a estimate gash and so having them call twice is just doubling the amount of work that node has to do but even with it simulat if the transaction fails then we are not returning the logs so it's not in a way better than that I thought we were no that's just returning error code not the logs up into the point of failure we would need a tracing support

for that yeah I thought we were returning logs thought we had a discussion but then but not maybe we had discussion about it but I don't remember why we decide except that's how it used to work before and I don't know if the if the clients or evm somehow works or that it cannot return those not sure CA would probably know I think with the when the transaction fails we should get better better information why it failed anyway but that's not that's what you need tracing call to do and I usually use tender for those

cases when it fails and then I don't know why it fails and then tenderly is somewhat good in explaining why the things fail but it would be nice that the E simulate could be do that I think they tra Trace everything yeah this gets back to I definitely think that there's more data than node could easily get for relatively low cost that we could return figuring out what that set is that is what is the the intersection of that set for all clients where it's all clients can easily get the data and save it and return I'm not sure how trivial that that is well one option is to make that new method that is the tracing it simulate

and I think CA was discussing at that some point but I don't know if he has tried it out yeah but yeah I don't know what to do with that gas estimation this is it very important that it needs to be included or is we can also Implement so that clients are implementing themselves and they're doing multiple each simulate calls but that's a kind of even heavier yeah I would want I would want to spec something out we at least all agree on it yeah which should it then be a new

method that's the question yeah like I said I'm I'm not a fan of new method for this I do think we need to spec it out I just don't think it should be a new method I think we should just included it in current method yeah just then there's going to be multiple versions of each simulator out there which is all we1 versions but they are not actually we1 version but they we1 and then something else I mean is this something that what is the workaround right now for apps if if an app if an app wants to do an estimate they do it themselves

manually no there they eat estimate gas but it just works for one call and I think in the future in way it still would work for the most of the cases except you want to build that kind of simulation St maybe the first question is to find out what the behavior of all clients is if they receive an unexpected um unexpected value for the gas limit like a string what happens if there's a string in the gas limit do they and probably probably return invalid prams yeah that would be much in yeah

okay I'm thinking maybe we could just you know ABS could always fall back back but invalid prims means they they can't just kind of blindly test it well what do you mean that they can well they would make that call and then they figure out that they cannot do that they what I was thinking which I don't think will work is they make the call with the V2 stuff um or the v1.1 stuff meaning they specify that they want to get um gas estimation and then if they don't get a gas estimation back that's fine they

just move on with the traditional way of e estimate gas and if they do get a gas estimation back it saves them a round trip but if the client is going to crash in that case then that's not a good idea well you cannot do the E estimate gas if you're doing trying to do multiple transaction in a row like what would be the point of the it simulat yeah I'm trying to think of a way we can make this we don't need a new version so it's on my mind right now hey guys hey we trying to think of how do we add the gas estimation to the it simulat right yeah

um anything any conclusions no good on I think the annoying thing if he implemented the cor version is that then we have kind like two versions of each simulate we have the older version and then they had the new newer version out there and then the client in way cannot know which one they're using well eventually that everyone would probably with using the new version but it's annoy that we had the V1 but it still there's new multiple versions of the V1 yeah I think that adding new methods yeah I think adding new method would be something like multi- estimate gas or

something or it simulate estimate gas the other option is is we just start working on the other option is we just start working on E simulate V2 and we collect all the things that we think should be in it and this is one of them so we do have a new version but it comes with more than just this like I wouldn't want to do a whole new version just to make it so it can make guess I would argue this is more urgent than some other features

we've been talking about for v2 I would personally like to see this happen um as early as possible because it does seem like some users kind of need it yeah I agree I mean we Interceptor could certainly use it we do this janky thing that gets it wrong all the time not all the time but in the cases when there there's the gas op code being used and it seems like quite many code that actually use it so guys I'm bit out of the loop so the problem is that e simulate doesn't estimate gas correct and if you're got a simulation

stack there's no reliable way to estimate the gas one of the cost okay so we would like okay so we would like to add kind of either V2 or simulate gas or whatever uh that would simulate gas okay question mark from me uh because the uh standard simulate gas uh so calculate gas or whatever was it whatever estimate gas estimate gas oh that's yeah I just went out of my mind uh is doing potentially multiple executions of the transaction with

narrowing down the the actual gas limit right and seeing where it fails and where it doesn't fail in eth simulate context that can be potentially really resource heavy or do we have any better idea well I don't think it's any more resource heavy for a single transaction because you would only you'd execute the prior transaction however and then you would reexecute multiple times the next transaction but you would store your pro prior State like you wouldn't discard it and so that way you can do the same kind of search um without having to reexecute the whole stack every time well yeah yeah yeah yeah like in in essence it's not the not something

more uh resource intensive but just by E8 simulate itself being potentially more resource intensive because you can just feed more transactions there like is that a potential problem we can say not but yeah just potentially we can fit for example 10 transactions and now you do this 10 transactions each of them end times right so it's like hundreds potentially even of execution you're saying just that e simulate has potential for single Json RPC method call to cause a lot of load on the um clients and if we add simulation onto that that can

potentially magnify the amount of load you can give to a client with a single RPC call right uh yeah and that would potentially would have to you know be countered with good limits and that could potentially limit that functionality right what you can achieve that's kind of my question right there I think there be limits how many estimations you can calculate so if you make a each simulate call with 10 uh transaction with all missing gas estimation that then that that would be huge load for the node and I think the clients could have some kind of parameter on how many kind of times they can do the estimation because that is not in the under the gas account so it should be somehow be limited

sorry so I think the the way way to solve this seems like we should just make every single estimation execution so if your if your estimation strategy involves bisecting calling running the function over and over we add each of those attempts to your total gas you can spend in a single Json RPC call which I believe all the clients have limits on right and so if you do an E simulate and you tell it estimate gas of the 10 trans transactions and it requires a complicated bisection to Def find then you have to pay for all that and so your um your per Json RPC gas utilization limit that the

clients have just you know it adds up and so as a application developer you want to do two things one you want to make it so it's easy it's easy for clients to estimate the gas of your transaction and two you want to make it so um you're you know not doing too much otherwise you're going get R limited the estimate gas that the clients do right now does it have a happy path where if there is nothing fancy or about the gas estimation it only needs to execute once or does it always need to execute at least twice or does it always need to execute eight times for the bsection it's only very limited happy path like if it's only a transfer then

you can know the gas value or maybe one or two cases like this you don't have anything in the clients where it's like um run the transaction once and then run the transaction again with exactly one with exactly the gas that it costs and see if it still works to so you at least only get two in a happy path there's nothing like that I can check exactly logic always straight I believe not I believe yes well because okay so wait how much gas limit are you going to give it in the first place Al so my thinking was in most transactions I believe you can give

it a gas limit of let's say 30 million or whatever and then you execute the transaction you keep track of how much gas was used along the way and in theory changing the gas limit to that number should make the transaction still work and in that case that means there was no gas introspection going on and everything's happy and so you basically just execute twice once with 30 million gas and then once with whatever gas you estimated with that 30 million and then you'd start only do the bisection if that second run failed which means you've got some sort of gas introspection going on in the contract you feel it's easier to do that you always add some kind of like Global class and then always when you're are

doing the estimation that it adds to that or subtract from that instead of just kind of limiting how many gas estimation you can do I would feel it's quite complicated to add a new gas thing there so I think we had that mic that logic you're saying at some time ago but it people were complaining about it and we had to change it to be uh more exp you know more explore the the the gas space because of something I don't remember the details but I I know that we it didn't work well really yeah uh it was also like a bit weird for us uh but I would have to look

it up uh what was the problem if you do find that let me know um I don't expect you to go looking that up but if I'd be curious why that doesn't work like I would think that do you Happ to know were people complaining that the gas was estimating incorrectly or is underestimating or overestimating do you remember that much uh I think underestimating actually in lot of us the bigger problem I'm confused I don't know how you can underestimate because you estimate once you get a number you try it with that number and then if it works great you're done how that could possibly underestimate not sure if I understood to but that was the

reality um Let me let me try finding it one challenge here is also I think e estimate Gas Works very different for for each node implementation so that's not really standardized what search is done or what happens there so that's also it's one point where the things are or the different clients are return different values for them if you do the it in the it simulate but maybe that's something that they can be okay with I think get for example very recently that they modified how theate works like maybe this year or last last

year for example they they use different algorithm or something uh yeah that that the modification was just to limit the binary search to have some bigger error margin and I think we also adopted it so not to just uh fine-tune the estimation to the last one gas right but have some kind of okay if it's under this error margin we're fine we don't have to estimate to exact you know integer value it's like with some and I would imagine that you still use do it bit different than get or it it's same no we are no we are doing more or less the same at the

moment so wait but I guess the point that Kim is trying to make is it's hard to standardize the exact value because it's an estimate and every client might do it differently so we can not rely on the fact that they will all return exactly the same value and we shouldn't probably is that the point yeah well we could write in the spec how it's done but I don't know if we want want or are we find that different clients are returning bit different estimates I think we actually want to give some latitude for clients to improve on their estimation strategy like you know both clients did recently they both changed their

estimation strategy because they found a better way yeah I agree I don't think this is something that we can necessarily enforce I think we can enforce it but I don't know if we should but it's just something that we understand that then that then the results can be a bit different but I think the bigger question is how it's going to be Implement do we want to implement the current implementation or do we add new method or do we implement it in the V2 I think that those are the three options that we have like in the currently we already

have the eat estimate gas and then eat coal and each transaction all all in a way separately yeah like I said though it's just it's it's very wasteful like we're talking about how we can make it so it doesn't over load the RPC server and I feel like first thing we can do is just not be so wasteful it make it so users can do a single call instead of needing to do two for the same thing how about eth simulate V1 with estimate okay I come

up go ahead uh I will send some issues that we have with gas estimation that we complaining before we changed so uh when we were trying to do that maybe I maybe if Micah is smarter than me white this failed it seems unlikely but I can take a look yeah I think we were just like gave up and say okay we'll just follow G at this at some point no I remember I remember I knew at some point why it was wrong but uh I don't remember now guess your brain is full

yeah you know M increase the gas limit m is my external memory in normal normal places so but he's not here at the moment so yeah I've sent few issues that we had with that to telegram let me take a deeper look on them maybe I'll remember way but yeah we also had recently problems with Theos is safe because they are using the gas or they're doing something weird with the gas stuff I mean so we can take a look at

this from different angles one is complexity I think so this is I think one reason why we should leave it out of e estimate because it's just becoming a Swiss army knife that does everything um and the other one yeah what mic said would be an argument to put it in um is simulate uh I was also trying to think about this from a use case perspective is it that you would always need to do the simulation when you do the estimate gas like are these use cases always coupled

together I wouldn't say always but it is common so you have one call that gives you um very detailed results of a transaction and you have another call that tells you how much gas a transac to use in an app you often want both of those things you want to have detailed results of what will happen when this transaction is executed and you want to prep the transaction for submission which requires getting the gas estimate and so in many cases I wouldn't I don't want to say all cases but in many cases an app will call will do both because it needs both pieces of data and so it would be nice if we didn't have to hammer the node with two separate calls that do exactly the same thing on the Node they just return different uh subsets of results which then the user

has to combine together it' be better if the user could just make one call get both sets of results back which the client has anyways um that now we could what we could do is do like an eth simulate estimate gas function and that returns all the data that eth simulate returned plus the gas estimate in which case the user could only call the estimate gas but at that point we might as well just call it e simulate V2 I feel like and what if the user only needs the estimate gas um I mean if they only need to estimate gas I believe on the client's side the same amount of work needs to be

done either way it's just a question of what is included in the result set and so the the client in both cases still needs to do run run the whole simulation it still needs to run all the blocks it still needs to do all the work it just what does it return is the only question and so we could another option is we could do e simulate V2 and have some sort of uh options where the user can specify what data they want back so say I don't I don't need receipts back I don't need blocks back I don't need this back I don't need that back and then sort of like how you uh if you guys are familiar with working with the graph um where you kind of specify this is the set of things that I want in response to this query and then on the back end then

does all the same work it's just returns different sets that way you're not overloading your network with unnecessary results I I wouldn't want to do something as complicated as a full the graph implementation though right um I'm personally like okay with these options I think at this point it would be nice if uh the ne mind just starts prototyping this and seeing if any issues

arise um but I just saw that sorry this is a bit of a change of topic but I saw that roit left I was wondering what happened with the time stamp discussion did you guys talk about that as well or uh we haven't I think talked here uh so I don't know a mic from NE mind really dislike one time stamp because it's unst standard or never mind we have a configurable parameter and we configured it for all our standard networks uh that tell us what's the slot time so you would generally love to just follow that and have it done like that instead of producing a

time stop that is unrealistic but yeah that's kind of why do you have the list where is used well we don't have the list but we have a conf default config for each uh Network we officially support and we put that parameter there what happens if that um config is out of sync with the consensus client what do you mean by that consens client the cons client tells you hey the block the time stamp for the next block is you know 14 seconds but your config says 12 okay yeah that's I we would still use the config because I think it's nothing

like consensus based depend on on it so it would be updated with the next release right um and in terms of there's a different thing probably because in practice this is every 12 seconds and when when do we like start the period that we are working from that's that's a different question but probably based on the parent block yeah we could do that so what about for blockchains that have sub seconds times is it a number no we don't support rational numbers there because the time stamp doesn't support rational

numbers right so the so you basically it's minimum value of one or is it minimum value of zero I guess is the question I think zero we can we can do it as zero and this currently this config option is used where other than here Ah that's a good question let me double check maybe uses it I'm guessing that kind of global config for whole chain so then and would be actually using all of it well we kind of have a local config right for each change so um okay something in the health check

Service uh in the merch plugin we use it for something okay that's nothing important ah when we are building blocks um how long to improve the blocks for example when to stop improving the block right because we are because we are expecting the call from the CL right to get the block and at some point we we know that we kind of passed this markes doesn't make sense to try to build it again um us to optimize predicted You can predict when CL is going to ask you the next question based on well up to the point when it still makes sense to

try to improve the current block right and it's at some point yeah maybe it won't just ask about it and it's you know because it I don't know took from M or something and we yeah there's no point of of doing that um work you don't need to do if you can guess that you're already pass time yeah makes sense okay what is it doing here oh when we are trying to predict Fork Choice rules for next block and that is used to calculate base fee in transaction

pool when but that's that would be on on hard Forks right um and potentially if if the transaction will uh will uh yeah I thought Fork Choice was almost entirely by the CL these days uh generally yes uh but it's it's for transaction pool but we we do have we do have potential uh Forks now on time stamps oh I see you're talking about for scheduled hard Forks yes for scheduled

hard Forks right but we we need to we need to have this data for uh we need to have a time stamp to get the data for uh future release spec and where we can in gas estimation we also using uh header time stamp plus next next block so plus seconds per block block uh per slot so we are using in a few places to kind of estimate what will happen next right you're not using it for consensus stuff but you can use it to make predictions about the future that make it so you can your client can perform better and do a better job at what it does yes yes exactly exactly um and so gu does not have a

similar config is that my understanding at least not yet uh no not as far as I know we don't have something because also the we can just assume the block times to be that of etherum main net so even if we use I don't I don't believe we use the 12 seconds anywhere maybe we're in the transaction pool and I and I don't know it but um then again we don't need the config or network because well yeah um or only main yeah well Main and the test NS yeah so I'm like I mentioned in chat

I have a weak preference for one second just because um I know it seem seems like a very reasonable default if you live in a world with many blockchains and the user can always override it so I'm not too worried that being said I am not opposed to setting it to main net um timestamp and in in the case of nethermind that could be whatever the config says and in the case of gu maybe that just means you know 12 seconds hardcoded opposed to we would need to make sure that this somehow gets remembered to be updated when uh hard Works happen that may change that time so if the CL eventually goes to 14 seconds or 10 seconds or whatever we'll want to make sure that

both gu and nevermind get an update it sounds like nethermind already has a process in place for this one thing I'd worry a little bit about is that we just kind of forget that g has this the time stamp being used in some random place and need simulate um but in theory we can Hive test would catch that is that correct we do with the get that that kind of client variable is made somehow but it's just always 12 seconds and then the all the implementation can choose what what what they want to be put there and is GI opposed to just Mak it this a parameter what kind of

[Music] parameter like a c CLI parameter for example C flag yeah I don't see why though like I would rather have it as constant because if we're talking about it changing during a hard Fork then you wouldn't want to override that through the flag anyway and you'd want to update the codebase to actually reflect the new um time stamp like time slot times okay it's something that it's something that can be overridden in it simulate so if somebody wants a specific time stamp increment then they can just

go ahead and provide all the time stamps yeah true true but still you know make make easier for people who Fork you uh but yeah well no not exactly because then everybody who will run a fork of G like for base then they will have to have this flag at that point I think I would rather just change this parameter this constant in the base fork and be done with it so that they because yeah it's like do you want to put the work on the fork maintainers or the fork users I think that kind of constant

would be good as well it's clearly explain what it does well I'm okay with I'm okay with either my position is held very weakly so well I think there's three options that even we keep it as it is or we put it to 12 seconds or then we put it to what the Block Chain is kind of saying that it should be there's going have three options I I assumed the third one or the second one wasn't actually an option anyone anyone wanted I assumed it was either either the client set it to the current blockchain so in gu that would be via

constant and nethermind that'd be via config file um or we just set it to one second is anyone advocating for just universally hardcoding at 12 seconds I am fine with that wait but so what is the difference we we're setting it to Conant one and constant 12 so this what I well you're getting not realistic outputs on right but for both cases right for both if it's either if it's one or if it's 12 is more realistic if we are in a minute so one has the advantage of it work it it's one everywhere so if we set

it to one it's one everywhere no matter what blockchain you're on it's just always one if we set it to 12 then technically we're setting it to is the block time of the blockchain you're currently working with I don't think necessar because could be just main specific and it's set 12 in the main net and the main is kind of what we care about most that's the option with the 12 like one is settings for 1 second is kind of like it's not good anywhere at the 12 seconds it's good like with 12 seconds it's only good the minut so it sounds like everybody wants 12 seconds except I'm the only one

arguing for one so why don't we switch to 12 and then it sounds like NE mind will have that be configurable via their config files and it sounds like G will have that just hardcoded um and that's okay because gu generally only works with ethereum main net or that's what it's targeting net and Ne mind is trying to build something that works on lots of networks and so it's perfectly fine for you guys to have different ways of storing that 12 I guess in the spec we could fight it it's 12 seconds but then it depends on network oh I see yeah we have to decide what to put in the spec huh H Well Network block time so so in the

spec I would say just list as Network block time and then you can maybe also say this is 12 seconds for main net at the moment at the time of this writing or whatever that sounds good to me and then if e that switches to 10 seconds then presumably G would update the constant 10 I can live with that okay okay uh so if we have this out of the way what about potential other uh hash conflicts what's do we have a plan to address them roit have you been looking into that

maybe you can weigh in I see you're back roit you're muted oh sorry uh I was uh I was looking into other issues where it's the where uh some of the tests are failing because of minor uh string mismatch or error code different were different for H mismatch for the test I look into it the test that uh uh mentioned in the job sorry ISU board where it says that nether get disagree on block that test

is passing right now it's about the test is called uh override all in Block State calls so that test is passing with other test uh I think I have brought down the number of failing test from I guess it was 83 to 75 I'll try to reduce it further if you have those case where the error messages are not unmatching then that that's fine it's not in spe that the error message can be what whatever it's more important the eror codes are matching but even that would be a good get scenario that we net mind and get

are failing in the same places and after we get that then I would care more about the error codes error codes were different too uh for Nei mind we didn't have error codes where we mention the maximum number of blocks that can be simulated I think it's 256 right that's a client parameter but I think the default was 256 yeah but if you can get all the all the case where the all the kind of happy case is working and then the or and the error case both clients are erroring then that's already a very good situation of course we want eror codes to match as well but I don't think that's so critical compared to the other

stuff mhm yes uh and for has Miss message for other test I look into it uh luish yes yeah I I am saying that for has Miss for the test when I am done with the all okay but we need to some kind of probably dump the blocks right in a potentially raw form if anything is missing from the uh Json not sure if anything is and compare or I have everything in Jason are the has mismatches that we don't yet know what go system for uh uh uh also I think one

thing I noticed for other test which were failing has misses are different hases are different other parameters are different as well okay like let see the log so say if if you so as you're coming across these other failures and you can if if you can easily figure out what the mismatch is like you know the it's just obvious you look at the the output you can see um if it's obvious the nethermind is wrong just go ahead and fix the nethermind if it's not obvious who's wrong just um share the difference in telegram group and we can then discuss and figure out whether the gu gu

should change or nethermind should change one for every test is the size parameter is different size that's not uh that's not part of the hash I believe so it's and has as well parent has problem it's going to be a pain that's a problem yeah yeah it's going to be pain track down too so for the parent hash one I think you we will have to dump blocks um probably dump the parent block and compare like in some sort of raw format either um rlp or maybe Json we might get lucky be able to compare the

Json well hold on because it depends if if the parent has which Block's parent is uh is wrong is it the base block or is it a simulated block or is it a phantom block because like um it might be that our Phantom blocks uh have slightly different parameters or or it could be that the the parent block was simulated and it has a uh different block hash or not matching block hash and because of that every block after that will have weird parenes yeah that's what I need need to

look into but the error that I was looking What's the title of that I think the block size also interesting like why why that I de and that's maybe easier to debug than the block hash okay it could just be the two clients are calculating the are defining size something different thing since it's not part of consensus I mean it's not part of consensus except for until it makes it to rlp but the the size parameter might

not be used in that calculation yeah that's why I would having r P to the bug would be probably the most uh conclusive yeah okay I I I I'll continue to fix some of the issues and walk on this HS has mismatch okay there some other issu that I'm also saying is that gas mismatch or how gas it saying the gas used is zero it should not be interesting I would first try to fix

yeah I would first try to fix those in a way that are clear clearly different and only after that go the block hash is because those bugs also might be fixing the block hash issue y definitely the block hash mismatch last okay okay like I before if you if you run to one where you're not sure if if nethermind is correct or not just paste the details in the E simulate um telegram room and we can decide who's right G or nethermind don't just assume that nethermind is wrong um it could be that guess is wrong as well yeah exactly and to add more to that these tests were filled with a guest client so if we have

a bug then the test themselves will be um so yeah feel free to reach out to me or if you're not sure about the test to kilari and we'll get this sorted there so when I see defense yeah helping on okay anything else I guess we didn't decide I guess we didn't decide anything on the G gas estimation yeah gu information you kind of hted it's something that can continue discussion next week

well oh yeah I guess we're almost out of time I think the thing to think about and maybe discussed in telegram is just do we it sounds like everybody's in agreement we do want this gas estimation I feel mildly strongly that we should make it so whatever we're doing to estimate gas does return whole um like a complete response so that way users don't have to use estimate gas and a separate call to get data back so like logs and revert reasons and return values all those things should come with the estimate gas response if the user wants them at the very least um just so we're not unnecessarily adding load to the the clients um I'm okay if if everybody really wants to have a new method I won't fight it hard um I have a

mild preference for not versioning quite yet but I can appreciate the arguments made for versioning sooner rather than later and so I'd be okay with we have a couple options one we just do e simulate B2 and it just all it does is ADD SM gas or we could try to bundle up some other things but as Cena mentioned we're going to run into problems with you know that might take another year and we don't want to wait another year just to get gas estimation out and we could switch out over to another method e simulate estimate gas I think I would personally rather do a V2 instead of a new a separate method just because the E simulate and eth call are basically the same thing on the client they're just different result sets and um I I going forward it'd be nice if we

could get rid of that whole concept and just have one method that does both things because it's again it's doing the same thing on the client in both cases it's just maybe a configuration option in the parameters for what data you want returned or something like that that would be my preference um happy to continue discussing this over telegram though I think if you make V2 then I don't know how difficult it would be to T add that that feature and nothing else and then if you had new more features then that would be V3 so that in a way would be somewhat fast to deploy new versions instead of kind of making the huge amount of changes for each each version yeah I'm not totally opposed to it I mean the software we write over dark Flores I mean we're pretty

aggressive with our versioning we just put new new major versions out every every week or two um and so I don't mind that strategy just one more E I promise just one more it's always one more e but but eum doesn't go with the version numers we are still in the eum one we should go with eum 2 oh yeah we started on that okay I think we're done for today we'll continue talking about the the gas estimation in Telegram and then maybe next week we'll make a decision yeah y see you sounds good talk to you guys

see you guys later