eth_multicall Meeting, Nov 25, 2024

Transcript

we have Rohit today who will be taking uh implementation duties from o um Brit just started today looking into so he's not really up to date on on most things we had a knowledge transfer internal session today uh but yeah uh please uh be uh uh not you know he's not up to date on everything yet is uh looking into from through the implementation specification Etc so uh still fresh hi everyone hias thank you hey roit

welcome welcome yeah so I'll be working on the ne mind side on it simulate let's see how it goes I guess we don't really have updates on the progress no not really but uh would be good to define the next steps for example for Roy to uh what he should look into if you can uh give a bit of context doesn't know what's the state and what's missing and what's need more or knows but uh I'm not sure he's also like up to date so I think we were

discussing something about time stamps uh but uh I don't know what's the next thing there I'm also a bit out of the loop to be honest yes I kind of think that the next step that I want to I want to do is just read about the proposal about it I think 484 full request then I'll see the implementation on the N mind side I'll will play with it I'll try to run some tests I believe we have have tests hi tests are currently not all passing another mind is that correct you know Ki yeah there's huge amount of test that we need to get past and yeah so that might be good place to

start yeah I think the good place to start is to run the hive test and try to of run them and see what are the differences and then start fixing those issues MH sure so once once once they get familiar with the all the implementation from I said then I'll run those tests and we'll start fixing them and working on them and I believe we have a suspicion that the time stamp is the root cause of a lot of the failures right and so um look for whatever test I haven't looked at them but presumably one of the tests will focus on that so I'd say start start there we think the time stamps are wrong there many tests where the Met

might and geta disagreeing on the time stamps those should be looked at and I think if that time step issue is fixed then I would imagine many test will pass after that okay the first re I need to look on the time stamp I think the O is talking about the default time for nether mind is 12 second right Lucas uh yeah he mentioned that our first time stamp is 12 seconds why it shouldn't be and uh yeah but I'm not sure I haven't looked myself no me in there I'll look into it it should be one second should be one second yeah then we discussed with

uh with metamask and some node providers in Devcon and they had some worries about each simulate and we were thinking that the kind of consuming G gas will they'll stop most of the do attacks but they were mostly worried about that you make calls that prod huge amount of traffic so you can send very small it quy and that will produce huge amount of outbound traffic and that is expensive for the node providers and at the moment we don't have really good kind of pixes for that but that's one thing that they were worried about I think we have a global setting for Json RPC to cut the traffic

at some point cut the I would have to double check but it can potentially maybe allocate some memory bigger chunks so maybe that's potential problem let me check I think this probably output I think it's the same issues with the E call I think with e call you can like similar kind of stuff but with the E simulator you can produce logs and that kind of stuff with e call you just produce one call data but I guess you can produce huge Co as well so you could still attack the node no with that yes some extent you can

uh yeah I do believe that RPC uh in G also has a limit on how much you can you can output so there will be a cut off point yeah there is a Max uh response body size and it's I think around 30 megabytes by default never mind that's quite a lot uh yeah 32 megabytes mhm that's our default but uh someone can lower it right so it's uh I expect RPC providers would be aware of this let's say at

least that they can manipulate this and lower this if this wants because if you're learning a local node we don't want it to set it by default to low I think and for RPC providers I think they can they should explicitly set it even if they set it for 32 they should have this explicitly defined in their own spec yeah I agree then metamask also wanted that that we could have pre-stage and post stage for all all of the state that is changing and if they would have this then they wouldn't need to have some kind of own infrastructure in doing that kind of

calculations and then CA at least said that this shouldn't be too difficult cover some kind of state diffs what do you mean stative yeah but okay uh that's doable would that would be you know extension of the spec right and would this be optional I think so right definitely those states are going to be huge I guess if they're not being proven is they want does metamask want Pro proven States or just the data just the data oh I see okay that's maybe not too bad then but yeah I definitely feel like that should be optional I'm guessing

most people won't need it I was surprised that when they're running the Sim simulations to get the uh what tokens the user is getting and what what they losing they are not using events for that at all but they just using the state and they saying that you cannot trust the events and you kind of you canot calculate from the events when you're using tokens that they kind of Behaving Badly but for that reason they don't want to use events and I I kind of disagreed with that I think those events should be or those contract should be kind of you shouldn't pick the user needs to trust the contract in anyway so then they need to trust the events as well but but they disagree with this yeah I agree with you feel like if

some contract is not emitting the proper events not it's not an rc20 token and if you don't support it that's fine it's mostly those rebasing tokens where you can send certain amount of tokens but then your balance changes differently based on the and you cannot tell from the token event how much your balance has changed yeah I don't know it just it feels wrong to bend over backwards to support ridiculous things yeah but for that reason they they would need the priate and postate because they want to calculate the token balance from those instead of from the events so I'm not convinced that's a

great use case however I do think that I I can see other use cases where pre and postate could be useful that was mostly for um developers and analytics but yeah that could be an optional flag and then you could enable them so we could still use the each simulate one for that to add that kind of feature but I still think we should first get the spec working before kind of starting to add new new stuff so that we have two clients that both are supporting it simulator do you s have any comments on this state stuff uh no you summed it up pretty much for

me you want to include them as well um yeah I'm fine with it uh so metamask was one user that asked and there was also someone else from one of these dexes I don't remember exactly um they also explicitly ask for some something similar so seems to be a a use case that people need is there some standard format on how to return those actually no do do we return them after the whole query or after each

transaction or each block or how they should be returned oh yeah I think we should return it after each transaction um because at least as far as I know one of the use cases is to be able to then do estimate gas um so we yeah we have it simulate but if you want to do like full gas estimation for a call then you need to know all the state up until a given transaction so that you can then at least in gas we have we it's possible to do estimate gas and override the state so um if we return uh the state diff at

transaction boundary then users can do the estimate gas and provide the uh State override uh to get something in the middle of the call stack would it be more useful to just build e simulate estimate gas or equivalent yes also so two two followup questions on that one if we had e simulate estimate gas would it still be worthwhile to do the pre- and post State and two should we focus on estimate gas as a first next feature before the pre- and

post States I think uh the there was a separate distinct use case from like from metamask about this so it seems like it's still a valid thing to add like valid feature about priorities I'm not sure yeah I think they still want to estimate transactions with the each simulate so or with the gas do the gas estimations with the each s yeah I feel like e simulate estimate gas is probably what I would pick for a

higher priority one and I would suspect a little bit easier but maybe I'm very wrong about that there there's also a lot of things that you need to decide do you estimate for each transaction or you just estimate the whole bundle or how would it work each transaction definitely because the user needs to be able to prepare the bundle before they submit it and each transaction needs to know how much gas it needs but I don't know how that would work if you do it for each transaction then do those trans also depend from each other yes like we we're assuming it's basically exact same thing that we do in Interceptor where we're assuming that the user will at some point in the future submit all these transactions in

the order that you you're simulating them and in order to do so they need to know how much gas to give each one I guess that BEC even more complicated problems you going need to multiple it's kind of combin problem if one transaction takes more gas then the other transaction might change how much it requires yeah to optimize multiple gas limits at the same time uh I mean use optim you optimize them in order so you do the first transaction calculate how much gas is going to cost and then you move on and then the second transaction C how much gas is going to cost to move on I don't think it's any different than

just the normal procedure people follow where they estimate the gas for the approval and they estimate the gas for the transfer yeah but that case those are sent separately you are not sending them those at the same time not to change the topic but um I think at some point somebody even raise like adding call calls like call information to but then it feel like we're basically sneakily standardizing this tracing API so yeah I mean is that is sneakily

standardizing in the Trac API so bad it's not um I mean yeah I think that would be nice I do know there are a lot of people who would like to get in uh internal call tracing so um they they don't want full tracing and operators or node administrators don't want to enable full tracing because it can be very expensive but I I would assume that just doing call tracing and nothing else is probably not too bad and so maybe node operators would be more in interested in turning that on instead of turning on um

full tracing and so maybe we could just focus on that uh yeah I definitely agree that full tracing is probably not something that we would want to add but like call traces seem interesting and they do seem to cover like most of the use cases that people care about so um yeah something to think about okay so step one get all the Test passing for E simulate step two add call tracing or E estimate gas step three add everything

else easy peasy all the time more features always you know guys you create created a RPC method that's behaves as the whole blockchain so what did you expect it solves everything solves everything that's right trans blockchain RPC right so after it works well enough then we

can remove all the other RPC methods kind of optimization yeah you can also replace consensus and just have everybody e simulate on a larger and larger exaction history I don't have anything else sounds like we're the primary thing I think is getting nether mindes passing the hive test right that's our our major roadblock at the moment yeah it would be really good to get it match with all of the get stuff and then we can be more confident that

get is also working correctly but we need uh what do we need for that the mostly the biggest problem okay the time stamp is our like uh what we think is wrong but we generally need uh we need correctly doing everything like all the block hashes yeah in the end yes the current suspicion is the time stamp is causing many of the tests fail and once we fix that many of them hopefully will pass maybe all of them um if they don't then we need to go and figure out what the next one that's failing is and figure out who's correct NE mind or guess fix it in the appropriate client go on to the next one Etc we know right now that

per spec the time stamp one is NE mind's Doing It Wrong C's doing it right but whatever whatever's after that maybe I expect there will be more uh issues so uh do we have a way of like uh logging ping blocker piece or anything like uh like uh that we can compare the other parts of the block rather than just time stamp because I don't remember at the moment we were talking about it at some point I think we are returning quite many blocks yeah but we are returning them but are we returning them through our Json RPC right uh yeah yeah and I would like to have some something more

native like more native to the evm comparison not sure if that makes sense so so when we when we get to the point where hashes are mismatching we can't tell where you can compare the RPS and that should tell you where the why the hashes AR yeah exactly exactly yeah do we have rlp version somewhere available or is it like to be done no we don't have the RP encoded block okay we hoping that when we get the time step and all the clear clear stuff that that the magical it as the block hases will be matching I think that's naive approach I think the other structure

would probably be receipts then because we do return the transactions if I'm not mistaken only the receipts that would be kind of vague and under the hash well my question mark should we have an option to also return block RP just for like the bugging purposes like guess part of the spec or are you just talking about in the test uh wherever right some because this is I don't expect people will use it but I might be mistaken I could I could imagine somebody using it where they don't want to have a library in their client that

turns a transaction into rlp which they then sign and so is asking for the rlp version of their simulation stack back would allow then it would have to be spe yeah I mean I'm I'm not going to I'm not defending this as a great use case I can just imagine someone wanting it yeah well I can imagine but we can we can tell them that's it's not our problem right right um because it's like yeah but the question mark should we should we have something like that then and it would be probably easier also to uh if if that time stamp thingy won't uh give us the result we want and I expect it it would that would be too too easy uh

then some easy way to compare the results in a well you know like full everything right and not not going from field to field and trying to find where's the difference yeah I guess sta would be one we add those features already if the state rout is the same the state is are the same right that's and state rout is already in the block yeah but the problem is the state rout is not matching then we to figure out what makes it not match yeah yeah yeah yeah yeah yeah yeah yeah yeah that's then we need to go deeper right that particular problem is the one that causes when a client Forks off it

takes 12 hours to find out why because comparing State diffs is hard well much there a better way for that nowadays uh tracing is the best way full Trace so if there's a fork on the Chain then all of the not will do tracing yeah generally we get tracing from one of nodes and compare right what's going on when we have a a consensus issue but the tracing isn't standardized so you can't just uh it's more or less standardized uh with yeah so like okay it's good Ian haven't looked at it for a

long time is it you know if we have a if we have a consensus issue it's like manual work still right to to figure it out exactly what's happening but yeah it's like for yeah so it's like more or less standardized but it's not that great so I'm not opposed to have some option like a flag or something you can pass where you say I would like to get the rlp of each transaction back and it's I would say rlp of the block of the block of the block on the Block Level including the body or just the header that's debatable is it okay if we provide this

feature in a branch and then discuss whether we want to merge it or yeah maybe let's do this time something first and if we have still the problem let's focus on that maybe that would be the like seems F to me because I I expect we will need to do something like that if we if we are not really close after the time stop is like said that there's a self-destruct one as well I don't know if that was fixed already uh to be honest I'm not sure because we were fixing something but uh we had issues with our test so we weren't sure

uh if it's actually fixed and one of the things rocket will be looking into is that test and and uh going there so we did have some kind of fix but uh we had problem testing troubles testing it at moment uh so yeah that's something that we roit is aware of we'll be looking into mhm yeah I would recommend the first thing would to gu the test sh working and be able to run tests to see the differences mhm okay so more less up to beat anything else so we are still still hoping to fix those issues and then

hoping that everything match after that and if they don't match then we start to working on this other kind of stuff yeah see what's the difference yeah let's go with this this part I'm I'm you know from my uh experience there that's it would be too too easy if that's only that's this is the only thing this isn't your first rodeo well you know it's like a consensus issue right you basically want to have consensus between e simulate and it's you know not that easy yeah anyone who has done po client Dev knows that it never works in the first try it never works first five or

10 well I have a couple other cases that can be one is that we have have n get has a different defaults for different transaction that those and that's one to look at as well that those are matching and then the we had also that interesting way of calculating the gas limit if gas limit is not missing that's also one case that also could be looked at if we are not matching those but I'm hoping that the evm is running the same in Get N mind so if provide the same input then it should behave the same yeah yeah the AVM the the very internals are are definitely the same because that's that's consensus on the main net but uh like the the outer the instrumenting part is

definitely different and that's that's the root cause of the problems hand G nope and Rohit if you have any questions then just ask in the chat and people will help you question so don't be afraid of asking stuff noce I I'll just ask on the telegram Yeah by I so what did it say I believe in 1 minute

so uh bye everyone talk to you again next week y talk to you guys yeah bye bye