eth_multicall Meeting, Jun 3, 2024

Transcript

could you open up this one clar could you open up this one I was wondering so the issue there is that we have a set of calls for overrides but you are asking me to set base Fe per gas to non zero but is like immediately when I'll do that it will most probably potentially stop passing because we are in the like e call mode where we allow everything and anything to be zero so the question is shall we set base fer gas as if it

was filled in like correctly is but keep the validation uh like running non valid a mode and thus in real life the base FAS will be zero or shall we like just say to the user sorry no we cannot run this that's a good question actually now I realize that whys zero yeah but the get R I think get is lying in that situation I don't know how the get is doing that situation so if you are running on non validation mode and then you asking for the base fee op code then do you return zero or do you return

the the current base fee and at the moment get is returning the kind of the real Base fber gas but then that's somewhat wrong because then those transaction are not using that that's a good question the moment get I think get is kind of lying what the base Fe per gas is and net Min has returning zero okay but then I'm sure which is the correct I think both ways have their problems and benefits if we set it to zero then the user will at least see that if he wants

to set it not to zero he can do that and when he will do that we will evaluate it respectfully as if it was said to not zero for example and like validate it a little bit tidy tiny little part of valtion but yeah I get why it can be confusing somewhat but wait because I thought that we are setting to zero actually I thought if you create a new block don't you set it to the what is expected normal block to be I thought that if we are in um nonvalid

uh well yeah we do actually have this code to set base feed to zero so I am surprised that this is returning something else actually this was the I remember it was the other way around it used to be that gu was returning zero another one was not returning zero and we had a discussion which one makes more sense yeah I think it was because we had uh validation mode on by default okay so now the question is [Music] um I mean if if death is returning nonzero base fee then that's probably a

bug our spec is just saying that you should return what it is but then I think this is something that we should add to the spec but we decide to do here but at the moment it it should return return the corrent base fee but then I think it's weird because the transaction should still go through or would it would it one be one way to do that you set the base feish calculat correctly but then somehow when you sending the transaction then you are not actually subtracting the base fee from those transactions but I don't know if that would be confusing as well so I think the the point here is that the gas price is also zero right and one of the reasons why we decided to set base feed to zero was

then when you do something like subtract gas price from base fee which should be valid all the time but in case Bas feere is non zero and gas price is zero then that would be a negative number which is going to be invalid yeah I don't know what is the correct way I don't like either of the solutions yeah it's a it's a nasty thing but so M have ideas I have been trying to figure out what you guys are talking about and failing because I missed the first part

yeah so just to recap there is a set of calls that are made to simulate in validation mode off and the gas gas uh Base gas fee is not set so the question is do we set it explicitly to zero to indicate that we are like in this no validation land or do we set it to something else uh Guided by some rules specifically for validation mode off yep yeah I would the point but we want to send free transactions but I would still want to kind of get correct execution otherwise

but you cannot have both good point so either anyone who's looking at the gas price op code is going to get a bizarre result possibly divided by zero in revert yeah which is impossible on Main net um but this is validation mode off so I would say set it to zero because the freeness well okay so two options either set it to zero or set it to the right value but don't charge the user yeah that's what I was suting or gu so the perfect world you would set set it to the base fee of the block and you would set the priority fee to zero and you would deduct

the deduct from their balance if they had enough to cover it if they don't then you just say h okay we tried um that would be ideal I don't know if it's worth the complexity to do do all that so let's do it in V2 yes okay so so for V1 just set it to zero or set it to base view of the block zero I think sounds like Z so that way people can work with contracts addresses that have no money I think zero is better because most case you just want to make free transactions and that's less important

that the Bas Fe is correct I think yeah okay yeah I'm I'm I'm Board of zero for for non validation mode yeah and and just to be clear so we return zero in evm and also in the block header yes this is this is assuming that this is easy for you guys I know the base fee technically can never go to zero so it may actually be hard in some clients to make this happen Bas fee seven right from the maps in practice right and so that's my only worry is that if we say oh set it to

zero there might be some clients we're setting to zero like just is really hard to do or breaks something or has a divide by zero error or something like that yeah I'm not sure might need custom code because it's we can definitely run transactions without it but transactions are not blocks and yeah so so it's like a lever deeper right uh in terms of abstraction I guess we can have we can have the block still have a base feed right it's just the transactions would skip the base fee check I think that would be the best way if you can do that yeah we can probably do

that okay so the the yes because the Bas V is part of the block header but then again if the address can offord it then I I think it would be nice that if you would then it would pay the Bas base fee but then that think it gets more complex and then it can be also confusing that if you s the money to one that then it actually some can afford some can't afford and beh produce quite weird Behavior yeah I think okay I think I'm convinced that the best way for it in my mind at the moment is user can put whatever they want want for their fee

and we just always accept at whatever fee they said they wanted to pay like if user says Max fee of X we will allow their transaction through even if that is lower than the current base fee so basically we're in nonv validating mode we're removing the check that the max V is less than the base V yeah but the main question here is what do we do when it is not set at all so the user haven't set it explicitly for us yeah sure zero all right then I would assume it's zero yeah yeah so zero and um skip the check that validates that the max fee is above the base fee otherwise everything else

is like normal they get deducted for the Min of um base fee and their Max fee and again it's just we just removed the check that Max fee has to be greater than base fee is that something that can be done or is that difficult I there if you the transaction is ready to pay more than the base fee then we should only reduct the base fee though otherwise just what they are willing to pay yes yeah I think that that would be the best way if that's easy to implement otherwise we had to think something else let's make some tests and

see so what we are saying is um if gas price was not set set both gas price and base feet to zero if gas price was set then doesn't matter what base fee is we just we pass the validation is my understanding correct sorry I lost you for a few moments I think I think I think you're setting the basally always the correct value you just skip the validation for it that

then you just allow transaction to go through without it to being higher than the base Fe yeah I put in in chat um what I believe is currently in production main net which is the first block and then what we're posing here would be the second block so you'll notice the assert is missing and we default Max fee per gas to zero if it's missing that double bar means um fall back to in this example yeah and then the question is if this is easier to implement or

not yeah I'm I'm hoping that the the clients being optimistic here the clients have the implementation like this where the assertion is separate from the fee calculation if they're like the same thing like they're done in one line then it might make this more complicated to okay so but what is the base Fe here then the Bas Fe is whatever the Bas Fe for the block is as calculated normally oh okay then in that case the like the transaction will fail on balance check uh for the nonv validation mode that they have there in chat this is saying we take the smaller of the base fee or the the max fee for

gas the user supplied and if the user supplied no Max fee for gas then we just uh take zero smaller of zero or base fee which is always going to be zero oh yeah okay okay okay yeah sure um I've got like 40% optimism so this is going to be easy and guess another mind 60% that one of you is going to have a hard time making doing this and we're going have to change my main question would be if it would be as if for the end user he is calling is call so if we can keep that

everything is probably fine and end for the end user and otherwise we have some issues to think about I think call with e call you are getting the correct base fee no eth call lets you provide no base fee and it will treat or no fee and it will treated as a fee free transaction yeah but if you ask what the base fee is you are getting the correct value not oh you get the base fee for the block yeah I'd be I'd be okay with that if is that it's a good question to ask is in gu NE mind if you do an E call with a with no fee set and there or a fee set to zero and then inside of your the contract so in the evm execution it

calls the base the gas price off code what's returned is it zero or is it the blocks basally if the user did not provide a any any fee or any price then we return zero for both gas price and base fee inter for NE mind I think so but we'll have to create a test to check I really you in E call you're calling a contract that is getting the base fee you are getting zero I would imagine that you are

not yeah was so this was a behavor change um few months ago ah okay yeah I don't like that because then you cannot get the B VI with it co is there I don't think there is a Bas code is there yeah there is that that's what I'm doing in that test was this added after 1559 I'm looking at 1555 1559 yeah right now and I do not see a new off code it was a separate EIP but it was shipped at the same time oh that's right yeah okay remember

that but yeah I guess the reason why it's through the next zero is exactly the case that we have now the problem we have now yeah I tend to agree with Kor be nice if the base fee op code returned the block space fee however I don't know if I care enough to want to postpone getting this out to main net anymore and so if that's like non not more than zero work for either of you then I would say let's just go with what eth call does well I pref if you can do that but if I don't know if it's difficult to implement and if it's difficult to implement then I'm not strongly kind of pushing for for this just if it's easy to do then I we should think think we

should do this way but I I I imagine that it's difficult to do if get has decided already to return zero for the base fee of the E call yeah we would have to diverge from his call which is not super nice it's but then the simulation is more more difficult if you need to but I guess if you really want to get it correct then you can always calculate the base for yourself and set it so I think that's in a way fine that then the user needs to do more effort but it's still possible to simulate it the correct bere I think that's good do we have a test for

that and for E call uh for a simulate that would actually like test this uh this thing to be both on the contract side like inside the contract call and in the output that's what the test I you said is doing it's getting all the uh it's returning all the uh those BL parameters from the evm and then it's of course that each Sim is also returning all those block values and then I'm comparing them to each other that they are matching MH and that's how we found this issue because get and Ne mind is disagreeing

on the output but all only on that base fop code and not not on the others all right so another one question I had was I remember we had the page for the error codes or at least error codes were included into some page what happened to it does anybody know where I can find the page with error codes that are like error codes explanation uh laid out because I I remember I had seen it but I don't can cannot find it like it's it's in the executions back in

I can share the link please do here but then there's a lot stuff and just just find for ER you can find the list mhm there's two list there's that when the transaction fails and then there's when the whole thing fails could we somehow add it to the Wiki page it is

possible because it was I think it was there sometime ago but yeah right I don't remember it has been there but maybe we can add it you mean the read me you mean the one that we had on the like docs folder but yeah now when I see it it's all right I think it is all right so I can give some status updates so we've reviewed you uh is simulate code base so probably the at least core of the code base will be somay soonish merged into the client

into the master and we'll have I think at least for now a flag that would be set to false by default that would be able to enable if simulate if a user wants so when you'll be starting a Docker image you'll just pass in the flag set to true and users will be able to call it otherwise it will be disabled by default and yeah so we'll be able to at least merge the the changes and not have a lot of pain of rebasing and merging it each time we do any updates to the call and also I done the like call header as a base for Return of the call

so we'll have the in today's release I think we'll have the correct is uh call header so not not call header simulate result that you'll be able to to compare with gu one it should be noted that types are different at least by default between how we do it on the like client and what you are referencing in the the RPC docs so there may be some differences like long versus U 256 but

hopefully nobody would really really check it I think so the potential issue potential test that would be quite interesting to to check would be set block number to something bigger than long in C and and to see what would happen did you have to write custom code for returning this these times so before that I had a custom like object that I returned with the field scari wants and uh I just cast it forward and backwards from the types we really use to the types that are sent but now when we are

just like inheriting from the uh from the call header From the Block header base it will be a little bit different but it should be consistent with eore get Block yeah yes it probably sh okay great um yeah so as for my update it's I did this refactor of like returning the the full block header last week so yeah curious to see the differences but never mind maybe we can finally hunt the buckh difference issue I just edited the spec to those

block stuff but otherwise I haven't been doing testing because the at the moment n get mind are differing a lot from each other I guess if o did those changes we can get the new version and then I could run the tests again and see what are the differences do discuss over we I had to make a decision on what to do with the base feeding but I guess we need to wait from the client clients to decide if that's difficult to do or should be diff and should we different from the e call or not I haven't read that full request yet

so maybe there's a good reason it's done that that way and that's actually P request for get so is nether mind is doing the same thing with it call I would imagine I don't remember really um are we what doing with e call sorry if you're doing e call and getting the calling a contract that returns base feed then what is that base feed going to be but get is going to return zero but I would expect it to return the correct base fee but seem like it's it's retarding zero

instead call yeah um Peter has a reasonably good argument here the normally in production gas price is by definition always larger than base fee and so if you have code in your contract that does gas price minus base fee which is not uncommon because it's that's how you find out what the priority fee of a transaction was that will be divide by zero it'll be a overflow and since I believe those are U that will revert and so by setting the base fee down you're basically guaranteeing that that code will not revert anymore so will such thing happen

currently with is call so in gu someone does an eth call and they don't specify a Bas fee which is almost always a contract that did gas price minus base fee would revert and so in November gu changed it so base fee is now always zero so those contracts do not revert um I don't know what NE mind does right now but maybe different than gu if they didn't talk to you guys about this this looks like they just did it as like fix what was that I'm checking okay so this is not a bad reason to set

the base fee to zero it's unfortunate I think it's one of the cases when you actually need it then you find out that it doesn't behave as you expect and this can cause a lot bugs because it's it's some you don't expect it to return zero no we are taking I think the uh block parameter base fee okay so so currently it sounds like then e call for nether mine and gu differ as of November since nether mine change or sorry since gas Chang their behavior in November yeah but we set it to Zero by default here so it will be zero and zero oh I see you're saying you're

saying that we already have this like special code that explicitly sets it to zero when we are in non valid in non validation mode yeah in but in E call or in E simulate or both in E simulat I see okay so currently NE mind okay this this is non validating mode I feel like maybe following e call here is the right thing to do so people don't transactions don't revert so why why G is sing into zero I sorry I missed that again too so gu is setting the base fee op code to zero if

rather than setting it to the block. base Fe the blocks base fee to to avoid uh causing a revert in contracts that do gas price minus base fee which is a very common way to identify how much priority fee a particular transaction paid Jesus that's used for things like meta transactions and stuff like that because they're both U and so subtracting would give you an yeah got it got it underflow exactly and this is why we are just using long there there's some discussing about

the blob based fee and I guess we need to decide the same thing for it what to do with it yeah I'm I'm leaning kind of towards for the nonv validating mode I'm leaning towards just setting up to zero it does feel wrong because the base fee is a block parameter and you're asking for a block parameter and so you should get the block parameter but at the same time I recognized that a lot of people's stuff is going to not work if we don't set it to zero I mean we could just say for those people go and fix your provide a provide a gas price when you're testing but then they can't do um they can't run simulations with no e that also sucks but that won't work

either they have to run the valid with validation mode ah sorry sorry I went too too soon now I see there's more Logic on that so we have a should say set base Fe okay okay now I see what we're doing if transaction gas price is above zero or transaction from if call or transaction Max fer gas is above zero or transaction Max prity fer gas is above zero then we do set the base fee otherwise we zero the base fee sorry found another line when this is being done earlier and then I just see we use the Bas fee so I thought we use the Bas fee but we modify it

earlier use a virtual base fee that could be any number of things so base fee is zero only if gas price Max fer gas and Max priority fer gas were Wen specified right if we set the base fee to zero if they were specified we set the base fee to the previous base fee that's our logic okay now I get it I see sorry is that is that compatible with what G is doing Cena is is the same like you guys only set it to zero if the user doesn't provide anything exactly okay okay so should we just go with that then sounds like we're sounds like I think when we I think we when we

have return it the base Fe we should also say to zero so that the evm and what we are returning should also agree to each other that feels even worse to me well I think it's more confusing if the EVMS different value than what the Yeah block is I understand I just hate when the lies expand out to so would we then hash the block based on the base fee of zero as well yep oh so you're saying actually make the base fee for the whole blocks here what if one transaction the block has a fees set and one doesn't currently

theod one of those transactions will have a base fee set to something non zero and another one will have a base fee set to zero I mean the default value for for base fee on non validation mode is zero and then if you said validation mode then it's calculate correctly oh you you're saying that we should just the base fee is just fixed at zero in and what what if the thing you're trying to simulate though is depend on base fee the default is zero so you can override it but then you have to calculate yourself what it what it should be I say so if you're saying in nonv validation mode if you don't give the block a base fee the Block's base fee is going to be zero yeah well or the transaction a gas

price actually but that's kind of I I think in guest for if simulate we return the actual Block Base fee in the header but for each call specifically if the gas price was Zero then the base fee is kind of set to zero right so so in in gu e simulate the header results that you return are correct not lies but the evm op code for base fee sometimes is a lie depending on contextual situation I I think so I I have to double check but that's my understanding yeah I mean I can

appreciate kari's position that having saying oh the base Fe for this block was five but then the transactions reported in the evm the Bas VI is zero is very confusing and so I definitely appreciate that argument but I really don't like lying in more places than we need to I don't I think it's just lying in one place and then being consistent about the LIE instead of lying somewhere not being consist about your lying is it lying I wouldn't call it lying it's just special case and then we do not lie by returning it right well so the question is you have two transactions and one block and one of them has a a some fees set one of

them doesn't you know always a good idea for that throw an error if if you want any of your transactions that have no base fee or no fees then all of them have no fees either all no fees or either all fees explicit that's not the that's more consist and then you're consistent actually the problem with like one transaction having actually having something set to it we just like calculated based on the fact that for a block as a whole the base fee is zero and this specific transaction had something set to it all right let's

multiply this by zero we get the zero no yeah that was I think aligns with what clar was proposing earlier is that if the user doesn't explicitly give us a base fee for a block we just set it to zero and then everything else kind of works that point no other special cases needed well I mean then if my transaction provides a gas price it'll still still work like it'll just get a base fee of zero and so it's going to do the Min of the max fee that they set and zero and get zero out I will just pay a lot'll be free simulating uh main net like on Main net

so base f is I fi right so clar and ol if I understand correctly are saying even instead of having the base fee be derived correctly it's just always zero unless the user overr it yes zero the the Block Base fee inv validation mode false yeah inv validation mode false yeah and so all transactions are free and unless the user um pays a priority fee or if the user wants to set the base feed themselves then they can pay yeah yeah they could over do an override if

they wanted to set it to something but like like they said that means the user is now going to have to manually calculate the base fee changes themselves they're not going to get accurate base fee changes yeah kind of unfortunate but it does make the system consistent and I think it's quite clear because you're also returning it and you clearly saying that it's it's zero yeah yeah I can get on board with this makes me sad but it's acceptable and I do like consistency anyone opposed I think it's quite clear

solution yeah I can get behind it it's all I can look look fine with it yeah yeah yeah okay okay I typed in chat what what I think we agreed on so let's get that in the spec and updating the clients and this problem will go away yeah so got send a free and then paid transaction at at the same time anymore they either all free or they all P you could you could pay a priority fee and uh if you want if you wanted to pay you could pay a priority fee oh yeah that's true if you really need it too yeah so you could simulate it so that you can

calculate the base fee and then set the prority fee high enough yeah Okay Hand well base fee will be zero so basically the whole fee will go to the minor right the max fee per guas becomes the priority no no the whatever the you the user sets some Max priority fee and that will go to the minor assuming that number is lower than the max fee so if they set their Max fee per gas to 100 and their Max priority fee to one they're going to pay

one the of those two yeah yeah yes Yes actually what about the blob Place Fe should we do the same thing for it yeah blobs we have in E call something like simulation of blobs or we don't I think believe so yeah really the eth call supports blobs really maybe not East call but uh I vaguely remember

having didn't we add blob version hashes or if not I think we should definitely do it yeah so I remember I was talking about blob stuff and we were talking about using it as a way to convince people to move from call to e simulate by just saying we have no plans on adding blob support to e call I don't know if that actually we agreed on that or not I remember was discussing it but actually in the that get bull request they are talking about the Block Base fee for the E call but it's just

something that they discussed that they should discuss about but I don't know if it was ever discussed no I don't I don't remember that being discussed but I'm I mean so I have code here for blob Bas Fe definitely we can I mean we have a override for blood base fee that's part of the spec and by default it's uh just calculated properly like from the parent block

yes yes and so the question is should we do the same logic where it's zero by default rather than calculated properly and user can overwrite it if they want something else to read Fe that's a good question is can the evm access blob base fee uh yes I think the Sol have support for it or maybe they have mean is there an OP code for it is the question yeah I mean there's a IP 7516 okay and this is uh deployed the CIP went out I'm I'm guessing

so oh yeah actually yeah there solid the support test Bally okay I mean just for consistency I kind of feel like we should do the same thing but do we have the situation with gas price minus base fee do we have like no I think there's only blob base fee so blobs don't have necessarily the same issue why we had to set basic to zero um I'm happy to go either way like not a strict not a strong opinion on this I

guess the question is is it common to send free blob transactions like with e call you quite often want to make kind of free call so you don't want to bother with the gas prices and I guess if blob gets popular then there would be similar kind of need I would imagine so yes sending free does seem useful nen it's very useful that you can make free E calls and you wouldn't need to bother with the all the trans gas stuff all the time yeah I'm kind of leaning towards setting it to zero just so it's consistent with um base fee and when you're validating mode like even though like the only reason to have it

zero in is because of this U underflow error I think people people aren't going to know that and so if they see one of them as zero they're going to expect the other one to also be set to zero I guess that would be my instinct as to what the default expectations of users are and so having them having them both be zero feels like the right way way to go to me yeah I think it's better do it like way but I'm also very weakly in this position not strong you don't feel strongly about

blob base fee zero or non zero no okay let's go with zero then so same behavior as base fee BL Bas fee will have the same behavior sounds good or consistent consistent not good find the GS to discuss every every week we change this pi keep feeling like we're so

close no 8020 per rule we are 80% down yeah I feel like we're now at the we're we got 80% done and uh then we got the next 80% done and then the next 80% of that done and so we're at like whatever whatever that small number is at least we are moving forward look backward 99.2% 80% 80% 80% yeah from here it is Buck fixes just

what bug fixes hopefully yes okay so we'll get the r team we'll get the spec updated and by R team I mean Kari yeah volunteering them again okay guys yeah thank you bye thank you bye bye thanks everybody