eth_multicall Meeting, Jan 6, 2025

Transcript

how's it going have been squishing some bugs yeah I fixed the bug that I was uh I was seeing like uh the request where the the block finder was returning block number zero for the base Block it's now correct but uh the SSR is still different uh because the I think the difficulties are uh different for us it's straight zero what is the hash or the block number that you're fetching uh no I think uh I me I and I

fixed the issue that we uh that I was getting uh last time yeah it's it's it's the uh properly uh populating the request for Block parameter and for the block finder was returning the wrong block number but the HS is still different that's what that's what I'm saying the block hash you mean yeah yeah the but not the block has of of the parent you now get the parent to match I guess uh for the first block the parent has is correct yeah are there any other feels of that different is is the block size different uh block size didn't see but I see difficulty is different total

difficult and difficult size is different as well the to I don't remember how the total difficul is calculate nowadays isn't I thought the difficulty is supposed to be zero always but was it repurpose to something else the field in the block header you mean yeah yeah it should be I can check the IP thought it was always zero now but this difficult and the total difficulty this the total difficult is that Frozen to some some number and the difficulty zero total difficulty isn't part of the block nethermind team has wanted it to be part of the block for a long time but they have not been able to

get it actually included oh so it's otherwise expected zero but we are actually populating with some number it shouldn't be part of the block header I'm I remember get this returning total I don't remember see like the the clients keep track of it but it's not part of consensus if I if I remember correctly the thing that's part of consensus the thing that's in the block header is the difficulty for that block there total difficulty yes get return some number to it but the difficulty on get is zero but the total difficulty is some ZX C70 and something El so yes there's two

two things one one is the consensus data structure which does not include total difficulty two is the block object returned when you ask for a block over Json RPC which includes things that are not part of the consensus data structure and total difficult basically that's that's what we care about what is r in basically of course we care about the consensus one but I we don't see what's underneath we just see what's returned yep uh the consensus one contains the priv round now so in the block header in the block header yes difficulty was replaced with a Rand out value so it has some value

and I believe that g is returning I don't think that's correct I believe the difficulty field in the block consensus block header is zero and there's a new field at the end of the block header like I'm looking at EIP 4399 right now and it says the difficulty block field must be zero thereafter because there's no longer any proof of work oh right okay you're thinking about you're not actually storing Rando the the op code changed from the difficulty op code now returns prev

Rando right okay we are not return the run now in the receipt either yeah the mix has field was oh mix is the run I think so the mix is was kept so that there's no problem during the merge like no confusion for the clients and instead the mix hash headfield was repurposed to use pref and then the total if got this

constant I guess no what else uh the total difficulty is stored by each client in a separate index and I I believe we wanted to remove it like and it was merged in the specs in the execution API specs so all of the other methods have dropped total difficulty I think oh yeah our our client has still to our node still have total difficulty upd it for a while uh let me check if it was merged in G but I'm pretty sure it was merged in the

specs yeah I remember now uh yes it was merging gu okay so uh for the test I can see that total difficulty field is not expected I'll remove it and the difficulty field should be zero for neither mind it's different some number there I think we can would everybody be okay with just removing total difficulty from the returns lock ater object entirely it's removed oh it is removed so so each simulate does not

include total difficulty as part of the returned block values okay I I'll remove this uh last week I couldn't do much because I felt like so so yeah I'll remove this to Total difficulty block head yeah we don't have total difficulty but we have the difficulty is the difficulty still needed though I mean it's not needed it's always zero it's just a but but the user it can be

overridden it can be I mean I guess we can allow users to override it I don't know if the clients will all agree on what happens when you override it because by definition it is set to zero and so a client could be spec compatible and consensus compatible and not actually look at that field no no actually it's not in the override field so it cannot be overd but just returned we can return it maybe there's some value at least it makes it consistent with what's the consensus data structure like it does feel like we should return all the parts of the consensus data structure even when the consensus data structure is dumb and has extraneous bites in it I guess the the the block sizes or

something returned is that used somewhere that's also has been wondering for long time why it's different on get and Nether um block size is I guess technically part of consensus in the sense that the rlp needs to match exactly and so by definition block size is kind of you can extract the block size by just counting the number of bites in the rlp but I don't know if that's how it's def defined maybe there has different definition how to calculate the block size like do you include header and everything or you just include the transactions State changes yeah I'm not sure what size is supposed to you're talking about just

the size field right think it's called size yeah I'm looking at the E simulate notes only say even suggested at one point just getting rid of the size field which I'm not opposed to well I think it's somewhat can be useful field for us if we understand why it's different it might be something that that it should be the same but it's not and then that could kind of explain why the block hashes are not matching that's why I I find it more easier to kind of check than the block hash I feel

like if you have mismatched block hashes the first step you should take is get an LP of each client's block and compare them and having the size is not a step that I would if I was troubleshooting I this connect between clients I wouldn't look at the size if I got a block hash mismatch I would look at the RPS and compare them and see which one what where the difference lives maybe there's some scenario where looking at size would help but I would rather just skip straight to the rlp comparison that also don't help help with the if the state is different right so they you do RP comparison and then if you see that the state hash is different then you know where your

problem is and you go investigate why it's yeah I me I guess okay so if there is a a block has Mis mismatch first thing I would do is compare the Json outputs of each and see if there's an obvious difference there and that's where you'd see the receipt route the transaction route the state route Etc if all those look the same then I would look at the rlp version of each from each client and compare those and if those are the same means there's an error in your hashing function if those are different then you can narrow down where your error is I don't think I would ever look at sides for trouble but yeah I I used to see blocks blocks where everything is matching except the hash and the block size yeah so I I would I would get rid of block I would get rid of the size and

then just make sure there's a way for each client to return its rlp somehow it can be you know whatever what was that difficulty is not matching for some number so I'll first get rid of that then I'll compare the LPS because everything is LM uh on that notes we uh change the time stamp to the times are increment to 12 seconds so that should now match with another mind as well yeah I Reed it to original original value 12 you M mean that we should get rid of

this size field and I'm bit against that because I thought the spec should be Frozen and we shouldn't touch it anymore and I don't think it's that big deal that's there yeah I mean for that's I think the strongest argument for leaving it and I would defer to that if that's what people want and yeah I don't I'm actually sure it could be used for for some reason depending how it's defined I I don't really know how the block size is defined and I guess that that's something that we you should kind of look into how it's defined uh yes I mean it's not part of consensus so each client may be defining it differently which is we should

standardize is that the if you do the get Block get block by hash or get blocked by number I think you can get the size variable there as well so that's where it come from yes it's the same right but there's a good chance that the client don't return the same value that's interesting do those methods m match on it on the historical blocks okay that's my dat I guess then we still have the pendic question what to do with the gas estimation stuff didn't you guys decide that last week we did we did did but I don't know

if you agree on it and if you don't agree then that's good luck spec Frozen can't change it we didn't fight the spec but my preference was that we make a V2 method and it the only feature it has is that and maybe now we can remove the block size as well but then I I don't know how much the client people enjoy that then they we would have the V1 and V2 method is that something that people are against or not no I wouldn't see why it would be an issue to have a V2 method that's also my preference you

simulate V2 and it has an additional flag it allows you to tell the client that you would like to get the gas estimation done as part of the call um on a per transaction basis so each transaction that you supply would have like a flag on it saying I would like the estimate I'd like you to estimate gas for this transaction when you execute it that's my preference I would make the gas limit so that you can leave it out or you can put a number to it or you can put a string like estimate to it but I guess get didn't like that idea oh yeah I I mean not from an

implementation point of view but my argument was mostly regarding the providers and but I I haven't got like I haven't asked uh anybody yet in about that so uh still pending from my side but you you would be fine if it's that kind of like variable that can be of un missing number or a string and that's fine or you would you prefer that we add a new variable instead like estimate like estimate true or false or meod yeah I think that having it as an

explicit flag is better the problem with explicit flag is that then you can set it to true and then you can set your gas limit and then it might be a bit unclear for the user do you use that gas limit or do you estimate or yeah we already have a default procedure for gas limit right so we have this thing that we take the whole amount of Black Block estimate and reduce it by how much it was processed something like that so yeah I guess it's a bit confusing which one will be used but I think I think it's actually not that bad like if we have a like basically gas strategy something like that advanced or

accurate versus dump that could be interesting if you want to allow different kind of gas strategies but that would then make everything more complicated yeah maybe you could pass kind of evm code that you could kind of write your own gas estimation Logic on that with the op codes please provide us with a gas estimation algorithm in Sol in evm by code exactly I didn't understand your gas limit true I would put gas limit kind of estimate like string estimate sure the

idea is just it's it's a string my biggest my my biggest issue with that is just not all languages do well with um properties on objects that have multiple types like Union types like that so some languages really do make it or very easy to do number or null um very hard to do number or null or a string as the type yeah C Is Not Great with that but doable yeah it's also doable I I would argue it's not as clean but

yeah the I mean I think it's doable in all languages and we know it is because it's required for the block tag which is a number or lat latest and so we know all the L clients can do it but if I remember correctly it's kind of ugly and a pain in the butt in some languages and it' be nice if we don't do more things that are a pain for some languages if you do the other method then we somehow need to agree that what do we do if there's a kind of multiple kind of conflicting rules like there's the gas limit and then there's the estimate pleas Bas flag I would say the gas limit represents the upper bound that would be my my

boat so that the first the first try would be at the gas limit provided and then um you would go through your normal bisc and you would see how much it costs if it reverts you just return the revert don't try anything else if it's if you use less then you would try to again with less so same strategies we now don't use the 30 million gas as the starting point that's even more comp I was just thinking if the estimate is set then it just wouldn't care about the GH limit at all you could do that I wouldn't be opposed if people think that's significantly easier but C can you ask around if that this would be something that the other

providers would be kind of preferring they would be fine with this kind of thing I can try I suspect the answer you're GNA get from the providers is I don't know yeah when we have implemented that say say that it's dumb because of this reason that's kind of what happened with the it simulator they wanted more features to to it after we had done everything that's always what happens well good feedback for v2 or

V3 yeah okay anybody this is the most important feature to have for VT V2 or would rather the V2 be something else than this but I would imagine this is quite important I know for Interceptor it's one of the biggest pain points right gas estimation well it somewhat works sure but I mean this is like we've had to hack around it quite a bit like it requires a bunch of code on our side and it's not perfect yeah I think the second so so do you think it's better to idea put the complexity in the nodes instead of our our software yes because the

nodes already have the code and already have to have the code because of other methods so unless we want to make it so clients don't do gas estimation anymore which I'm guessing people would be fairly against um there are some benefits that gas estimation being done on the Node directly because the node can not it can keep around some portion of the state that it needs in order to do the estimate whereas if you try to do it remotely by just you know make a call try it get the result make a call try it get the result then um the client has to reconstruct all that state each time whereas the estimate can you know keep a lot of stuff in memory and so I do think there's performance reasons to make it put it on the client and so I be kind of

against removing it and I don't think anyone wants to remove it either I think the other thing that Interceptor runs into correct me if I'm wrong here Kari is offchain calls interleaved in all of this like balance checks and code checks things like that right like we have to do some we have to go through some effort for that to work in Interceptor yeah yeah so being able to add other queries that occur at certain points in the simulation stack would be useful for us I don't know if worth adding to e simulate directly though but we can already do that you can just put call calls between transaction of course

inside transaction you cannot do anything except you can still change some contract and then then you can kind of make it through calls between right we can't an example of something we can't do is we can't get a proof generate a proof right and so there's no way from inside of the evm to do the equivalent of e get proof yeah but but nobody's using that I guess well I mean sure maybe that's why see you later see uh it'd be nice if people started doing proofs more like the the whole system is designed to be provable in various ways and very few people leverage that um but it would be it is something we can't currently do so we

can't have a simulation stack and then generate a valid proof on top of that simulation stack which then we use to generate more transactions for that stack and so if if there is an app out there that acquired such a proof which they do exist I I wrote One a long time ago um we couldn't use Interceptor for it or res simulate just mild annoyance yeah is anyone is anyone meaning Rohit or Lucas against making e simulate V2 due gas no not really

uh but how would we do it I we were discussing that with sometimes gas estimations need multiple passes and would we do multiple passes on those yeah so the idea would normal gas estimation strategy each transaction that is given as part of the E simulate call would have a flag set on it whether defaults to false where you basically the caller says I would like the node to give me a gas estimate for this transaction if that flag is set then the node would go through the normal gas estimation process and when it comes to rate limiting the node would keep track of every execution required as part of the gas estimation towards the rate limit so we've got that like 100 million gas rate limit or

whatever it is that's configured on the client if you have to do you know six calls of a transaction to estimate then each of those are counted towards your rate limit count okay give me a second I'm looking at one thing um other option would be have limit how many gas estimation you can do I think gas sorry guys we will use the same error margin as we have for EA estimate gas currently right because there's an error margin there configured for example what's the error margin uh so the idea was that g introduced this some time ago and we copied it that uh we

don't estimate gas to like the the the smallest um detail but just to some uh error margin um yeah to avoid avoid re executing the transaction few times more uh yes and it's configurable for us in in Json RPC um configuration when the user makes an e estimate guas call they can pass in a parameter no no no it's for the note because gas doesn't have this as an option we didn't add a n default option we could but we could add it here if you want I mean that would be interesting

I'm open to discussing that I just misunderstood initially um so yes all all that would be the same so the the same strategy you Ed for estimate gas would be applied in each simulate when the user asked for it I don't have anything against okay one thing to keep in my mind here that I think get the net probably would return a bit different gas for this estimates and I think that would that's probably fine I think we are returning more or less the same at the moment so maybe there will be differences but there shouldn't be like we kind of tried to align more or less is not exact in in a way but yeah uh well I'm not sure I'm not sure what's the current state so I haven't like tested it thoroughly to be sure it's the exact same thing but

uh yeah we did we did try to align so I'm not sure if we align perfectly or imperfectly yet or I mean at the least my my guess is if there are little edge cases we could at least write tests that uh for Hive that would work on both clients but then there's red and red Al might have different strategy oh that's true yeah okay so maybe the question here is is are clients allowed to use different strategies for estimate gas estimation or is it part of the that you have to use a certain strategy and it does seem like we should allow clients to use different strategies yeah I would go with that that you can have different

strategies okay so when it comes to um any tests we write we just need to make sure that the gas estimation is not part of the test or you can or you can add a test that the gas estimation is is within some boundaries let's say of for 15 20% and it's above minimal right needed yeah I guess that's fair um like this transaction should succeed and it should have about this much gas and you have some variance in what's allowed yeah guess it's fine the problem with that is that then the block hashes and everything after

that will be different but yeah you can just check that the gas es estimation is not the in the block hash I mean that the IDE is that you can do multiple estimations and if even one of those differ then it will change all the blocks are coming after that the idea is that you can do multiple estimation in in one and then you kind of estimate the transaction and then you include it in the block I think that was the idea well the estimation shouldn't change the actual execution yeah so that wouldn't be part of the test the test would have um pre-written transactions added right like I don't think right now we have any test where the test doesn't estimate gas and then includes a then call simulate a

second time using that gas I mean that I thought the point is that you can do each simulate V2 met call and then you can set some of the transaction to be estimate and it would kind of estimate them all on top of each other and then add all the other transaction there as well so whatever the estimate RS that that is going to be used right away in the blocks I see what you're saying you're saying that if the user so if the user leaves the gas limit off then um the transaction is included in the block without a gas limit and or a gas limit of zero I guess I mean it always has has some gas limit we don't have there's no

gas what is the guess so right now you have to get a transaction hash for the transaction right and so in order to get the transaction route so you can get the block cach Etc right now if you do not set a gas in your Jon RPC call what is it default to a gas limit we we created the algorithm that is the of all the gas is left divided by the number of transaction that don't have the gas set yeah okay so you're saying you're suggesting that if they set the gas limit to estimate then the node should do an estimation and then include that transaction in the block with a gas limit set to yeah the value that was estimated

and then it continues the G of the simulation yeah so I did I was imagining that it would still just use the um block limit or remaining gas and block divided by transactions without gas limit for that transaction it would just return the estimate to the user so they could utilize it in the future um I would include in the plock right away with the return gly yeah I do like the idea of having it included in the block with the estimated gas but the exact problem you mentioned is going to be kind of a a sticking point because no I don't think it's a problem if you just agree that when there's an estimate then then we don't care about if the returns are the

same yeah saying like we just don't don't write any tests that compare the block hash when estimate is true yeah yeah I wouldn't compare the blocks well you could compare something that you assume that should be still true but the like block has shouldn't be the same right unless the gas limits happen to be the same right but we wouldn't test on that because gas limits don't have to be the same or gas estimation doesn't have to be the same algorithm for every client yeah yeah I could maybe be convinced I lean a little bit more towards just not using the estimate because it feels simpler and it allows us to have our clients returning consistent values I I

like determinism basically and including in consensus stuff and specs validation then we need to R some kind of gas estimation value I was just thinking that that could be the right away the gas limit so then the return it seem like return would be exct the same oh interesting yeah I was thinking you would turn a return a new field with the guas limit but I see what you're saying that yeah that's I think it's also nice that if you then you right right away know what kind of the what does the transaction return when you are setting that cash limit and what is the outcome

of it yeah I mean they're definitely advantages and really the only downside is determinism in our tests like with the if we don't have it then I think with the it or with the Interceptor as well we would need to still need to make like two calls that you first need to estimate the transaction and then we need to actually see what the transaction does well I mean you could just you could assume somewhat safely that the transactions are going to do the same thing um but that is you're right that is not a guarantee I think that's the point why we are doing that because we know it's not always do the same thing yeah yeah yeah I can be convinced to go with what you're

suggesting what the nice thing is about that is then you can do estimate multiple transaction at the same time and they all included with the kind of the gas prices yeah gas limits anything else I guess for this then at some point I probably could write the spec for the V2 I guess uh yeah at some point we should probably do that I don't know when the right time like like right now we're just discussing what is V2 maybe we should everybody just you know over the next week think about what should be in V2 these would be things that other users have suggested feedback we've gotten for what people ask for I don't

know if anyone here gets feedback on these methods and then maybe talk about including those in V2 see what we want to include what we don't sounds like we got the gas limit thing and removing the sides From the Block header or from the Block I have also test this right up I guess I could that had some ideas that we discussed before there's the witness creation is that witness creation is the same thing that as the get proof um no witness is basically just the I mean you can have an untrusted witness or a trusted witness the point

is that it gives you all of the state necessary to execute the block locally so you if you had a local evm you could run it given the block and the witness and then in theory the witness can also be proven and so you could include a proof of the witness that the witness was valid um that being said I'm hesitant to go through the effort to do that until ethereum main net transitions to whatever they're going to transition to whether it's veral trees or something similar and just because we're going to have to redo all that when the time comes yeah I add the gas limit stuff to the

that block post see you next week I guess yeah one one change the I think we tentatively wanted the second option gas limit uh separate from the gas estimation Boolean field not a union type yeah like that hello we just need to they we just need to agree what to do if those both are defined yeah I'm okay with what you suggested hello what did you say Mercy yep sorry can I say something um so I

was trying to figure out if there's like a g up discussion um similar to the other ones we have with um C meeting and all of that because most of the time I get lost in the meeting topics are you wondering like sorry go ahead is there an order like similar to the one with cevs or um the other meetings that we do have cuz sometimes trying to get track of what is going to be discussed in the call I can't like really Point what exactly oh no it's this call is very informal we don't have like an agenda each week other than there's a telegram Channel you can join um I'll get a link to it if you're not already there um but

otherwise uh we basically just show up and I mean almost everybody here is either implementing or otherwise using this new method we're working on and so we kind of each week show up talk about our progress um it's very informal compared to the C dev's call I don't know how to does any know how to invite into telegram I don't actually know how to work Telegram I don't think I don't think you can give a link invite link I think you need to invite specifically can in chat there there's a invite link to the telegram Channel if you'd like to join and so sometimes we'll we'll mention in that channel we'll talk throughout the week about things we're working on and then

someone will say oh maybe we should talk about this at our next call and that's the closest thing we have to an agenda or any sort of organization for this call okay cool because um during the last um it's cat headers meeting something like this was discussed I feel like this is one of those things that there's good AIS out there for I see them joining all these other meetings I'm in where you an AI joins a meeting says a note taker are there any good uh median summarizer AIS these days I've never used them I just see other people using them all the time I think we used to have one here at some point long time

ago I would have no problem with some AI notetaker summarizer joining these meetings and generating automatically generating notes the one what is the one that You' think I'd remember because L I have some meetings I show up in zoom and there's like 15 note takers and they all post in chat saying I'm an AI notetaker you can go to this link and you'd think by now I would have memorize the names of them but I do not know the name of any of them despite them spamming every single Zoom meum I've in just about I'm also fine if someone else wants to take I'm similar boat with Kari it's not something that I would like to do but um I have no problem if someone here wants to start taking notes and you

know throw up an issue and even feel free to mention me in it and I can review and just verify that everything was captured that being said the advantage of AI notaker is AI are surprisingly good at uh understanding what's going on even in complex topics and so it has the advantage of the unlike a human where you need to have specific knowledge of a topic sometimes U AI are very good at doing it without or rather they have all that speciic knowledge because they have all knowledge on the internet okay so before next week I'll try to make note of what these AI note taking apps are or if Mercy if you find some feel free to share them in the e simulate or you can mention me I'm also

in the cat herter Discord if you want to mention me there I can let you know if it's one of the ones I've seen used anything else not for me yeah see you next week y see you guys next week bye