eth_multicall Meeting, Dec 23, 2024

Transcript

do you guys think uh there is any use case in simulating AA transactions which transactions account abstraction so um so is that something that you can do right away well it's going to be in Petra and we we merg the pr and it's being uh kind of tested right now and I figured that we we had it we had to add it to e call and E estimate gas I I just figured that it would be useful for users to be able to simulate

these kind of transactions and so I'm not aware of that I thought those transaction are kind of like normal they meta transaction but then they are landing on chain as normal transactions right so that's 37 that's like chain kind of account obstruction but now there will be there is this EIP that M shared in the chat where you will have some of those features built into the protocol so there will be a new transaction type and it will be possible to kind of set code for EAS okay that's do typ I guess it's four I guess four five wait is it it five said

what is three blob oh yeah okay well I I thought the blops are just normal type two but I guess they're type three yeah they're type three okay well of course then we need to support the transaction type that included in the next hard work uh yes that's the plan but then is those are basically automatically included because we are including all the transaction types like what what evm is supporting or is there something else that we need to add to that so I think basically it will come

down to adding like to the arguments that we allow basically users should be able to submit the authoriz authorization list from this AP this is saying that they allow um some code to be run in their context but isn't we are including all the transactions in the specs that we are not specifying that we only allow the three transaction type we allow all of them so I think this should be included kind of automatically the spec not exactly we do need to add this

extra parameter I think which one uh it's called authorization list is it part of the transaction body though I believe it is yeah it's part of the rlp of the transaction so I think since we accept any transaction that is a valid transaction on the network that you're on this will automatically perspect will automatically picked up not exactly because we don't like the parameter is not the transaction type itself it's some version of the transaction right I'm saying the way the

spec is written I believe any transaction type that is valid on the network is valid and whatever oh I see whatever that includes gets included so we don't say like this is the AP 1559 we just say include a transaction here and it will be interpreted by the EV the way the transm inters that type of transaction gotta so any change to the spec in clients though it might require changes depending on how everybody implemented things so we still should probably make sure we have tests for it at the very least yeah yeah and it also changes the output of the it simulate because this transaction type is shown there and then we need to show those

parameters we we don't to specify like an opaque kind of transaction output goes here no we don't but I I mean in expect it doesn't change anything but in the in the client it we of bit different stuff yeah I guess wait is there do we add something to the block header when is this going to be included is there any estimates um is it ready in all the clients already I think all of the clients have this included and so the new devet is going up in a week or

two so it's quite near like but it's the de on mainnet is going to be you want yeah of course there can be issues with other stuff but yeah then it's probably it's going to be included in a half a year so earlier but yeah I um at some point where we can start doing some tests on it yeah if if the various clients already have it implemented I mean I think it seems reasonable to add some a few tests for it at least to The Hive tests well at the moment I probably

cannot generate test like this because the the get doesn't support it right away way oh I see so I can add test test but then it all kind of that that's one thing I don't like about the test pip that I cannot add that kind of test that they get the qu version doesn't support because it will fail the whole process oh interesting um so yeah the it is included it just that we have to hi specified that this test should run with the park hardwork and configured something like that something that um I can probably look

into oh so we probably have to is that like a per test configuration or do we need to put these tests in a different location from the current set of tests no basically it is per simulation so it's for all the tests together so if we activate Prague then it means that basically all of the test results are changing so I would not do it right now actually thinking about it now uh we should probably do it closer to the uh to the hardw to make sure that all the clients will still work together after plug is activated so maybe once we're into public test Nets

yes okay do is there an ETA on when people think public test Nets are going to land I'm guessing quarter one since time all that's my best guess okay any updates for the people I made the modification that the time stamp is now the 12 seconds on mayet but it also depends on the network so the other other Forks should not include 12 seconds but something else and then I wrote that blog post about how you can replace a function in in a in any contract which I think it's quite cool feature that I didn't think was possible before like when we're thinking that with mic then we thought that maybe we

cannot do that stuff at all but then we figure out that kind of proxy pattern where you can replace a single function in a in a contract it's a kind of very cool feature of each simp agree it was a cool trick um as for me I not all lowed to report so I guess now I will post the pr for changing the time stamp to uh 12 seconds does Rohit have updates yeah hi everyone uh yes I do uh for other uh errors that I was getting I

fixed it uh right now I am working on actually I can see that all of the blogs number that I'm getting in the response start starts from 1 for my case but for the test side starts from 21 or in hexad decimal it's 0x15 so I don't know I'm figuring out why it happens and also uh there is some uh mismatching block numbers as well from from our case so I'm fixing that okay have we been getting more block hases to m match I guess in the block number or the time step is different and probably explain a lot of

the bugs but yeah probably that case uh because of the different blog numbers the blog hases are blog will not match anyway yeah yeah so I yeah first I'll fix this um numbers mismatch yeah do you have any any reason why the test for test the blocks starts from 015 0x15 that's because the there's specification for the what is the kind

of the which what are the uh in the high you can specify what is the network that the tests are run and then there's a couple of blocks and some test data initially there so then you can test again against that so the tests are not starting from the Genesis but well you have even then you have to specify that what is the Genesis block then run test against that yeah for for Genesis block number is I mean Genesis is going to always zero but from where NE mind Sol starts I think it hi there like 10 blocks and then then the test start from that I think CA pull that the testing at I don't remember where you could get

that but there's there's a specification of what's in the blockchain try to find it so basically the U blocks one through n are essentially kind of filling up some initial state in the blockchain and then our tests are built on top of those yeah that's right and where I can find the spec of these states and initial States I mean the config dists do you remember where watch that yes final link but somehow in our case when when

we are trying to find the first or the base block we are always ending up getting Genesis block with block number zero are you running the test with the hive or how yeah the Ty so your your code is looking for Block 15 or whatever or 0x15 um but it's not able to find that and so it falls back to zero is that correct probably let me see the where is it yeah it for it SS for blog even in the block parameter or you are some for some reason you are using the wrong the

Genesis St yeah might be so two two things one um definitely we need to figure out why you're not finding the the right block um two if the RPC call queries for a block and that block does not exist you should be returning an error do we have a test for that if not we probably should create one test for what if just a test where someone tries to call the RPC method with a block that doesn't exist and we get the same error back from all clients the blog I mean the blog parameter the base blog from where we start yeah yeah yeah so you basically say I want to simulate this on

top of block you know 4,000 but block 4,000 doesn't exists and so you should get an error and so we should make sure that all the clients are returning the same error in that case so we should have like one test for that we don't have any check for that in our dentation uh I think NE might gener just crashes at that and throws some very weird error for that right which is why we should get a test to make sure that we are all returning the same Json RPC eror it's about some road is not found or something like that yeah so so we should we should make sure we get a test especially if um NE mind is returning some obscure stack Overflow no it's no State available for

Block is it a Jon RPC ER the get are just invalid request and then code no they're different okay so we should create a hive test and just decide what code you should return in that case and agree on it and make sure both are doing that hopefully that's a very easy test to write before my case I'll check uh for the block perameters why I'm is getting zero and even if we are getting the correct plug parameter in the request or not yeah my best guess is there's something that's causing to fall back

like if maybe if nether mine can't find the Block it's falling back to zero or it could be second best guess would be that um just the code is kind of ignoring the base block parameter entirely and always using Genesis no so for search for the base block through block finder we have implementation of block finder but always might be falls back to the default one I see so your block finder class maybe has a fall back yes I see okay so you'll need to check to make sure the block you found matches the block you asked for if not return an appropriate error it seems easy enough to fix [Music] hopefully okay that would explain all L

hash is if you if using the block zero instead of the latest yeah that's why I'm always getting the parent has mismatch as well for every blog and let me just fix this we are also getting errors related to gas fees or a trans probably also related if you're using different parent block then I would imagine that the gas fees are different or the base fees is probably different from okay I'll try to fix it yeah that's my

break have people been trying to think of what to do with the gas estimation stuff for me it feels like the simplest would be a generate a new spec and create a gas multi gas estimation and then make that just WR the gas estimates and not modify the current version of the E simulator I'm fine with that but I would prefer to name it e simulate V2 rather than e estimate gas otherwise everything for for me I would't return anything else except the gas estimat so I I wouldn't return the all this everything that the it Sy is returning I still feel madly strongly that we should not do that because it is

so common to need the return data and the gas estimation in an app and so we want apps to make less calls to the client especially redundant ones for the client has to do the same work twice so I think I think there needs to be a at least one method that returns both the gas estimation and the results of the call such as logs and everything then I would call that V2 yeah I mean I'm okay with the V2 or calling that e estimate gas and just returning more than the gas um I have mild preference for calling it B2 but I wouldn't block on either of them I think

even even Interceptor would benefit from this significantly right because we need to estimate gas and we need to present uh call results yeah and and this probably would return us to get more accurate gas estimates like now we just do the one shot away yeah so we get more accurate gas estimates without having to double our RPC load yeah uh that would require some modification from the Interceptor but yeah would be possible yeah I mean My Hope Is is that we can basically just change if in eth call eth simulate B2 we would just change the return result basically and the return would now include a gas we

might also want to add an option to make it that you can set this false by default you can set it true that tells the client hey I would like to get that data so that way when all you're doing is a call and you don't care about the gas um gas estimation doesn't need to be done which isly expensive well I would make it so that instead of set setting the gas for the transaction you set gas to string like estimate so that you could set it to be undefined or or number or estimate string kind of like how the block tag works yeah be fine with that then you would be you would be really explicit that you want the estimate I'll be fine with that do I think doesn't go or C kind of struggle with Union types or you got something

block tag is like that already well the block tag is already like that so I don't know how it works underneath yes but is that cause pain for everybody I know that we could maybe not I thought I thought I remember one of the major clients it's difficult not impossible but difficult to do Union types where you have some parameter on an object that could be a string or a number is that true in C or or go I mean yeah we have some structure for it and it works it's probably not the most straightforward thing but yeah it's not too bad I guess okay I did want to jump in with something uh with regards to adding gas

estimation to it simulate and that's um I think it would be good to get perspective from the providers here because if they would go with a simple pricing of the high like worst casee scenario then it would mean that it Sim would be priced quite High um even even if users specify estimate guess as false like I don't know if they do it at that level did oh I see your concern here is that a RPC provider might not be able to do pricing based on whether you pass true or false to a given RPC method and so they forced to price it at the most expensive possible

that's yeah basically I would have client parameter that you could limit how many times it can it can run the estimate and then for that case you could maybe just liit one one so that then it would mean that you would just estimate the gas price for what the gas limit for one transaction at the time well it's not it's not estimating gas for one just that you have to run a transaction you're estimating gas up to up to eight times like if you're doing estimate gas on a transaction it potentially could execute that same transac action eight times yeah it would for that but it wouldn't kind of estimate for 10 transaction at the time so you could limit it to only do the estimation only once right I'm saying like for like let's say Alchemy for example wants to

do pricing and they want to price e simulate if a user can pass True to this parameter and cause their transactions to their queries to cost eight times as much as someone who C who passes false Alchemy is kind of forced to Bill eight times the cost for everybody because if they don't if they don't have a way of distinguishing between what parameters the user provided like if they can't build on parameters and so they'll have to charge everybody under the assumption that they're all going to execute everything eight times internally and so the cost for this would be high and how do are they pricing them at the moment do do they have some kind of like gas on their own or some how much

comboing power it was using or or is it each method are yeah this something I should ask I guess so that's the question I think one option maybe maybe the right option here is to actually just return the total operational gas used um as a parameter to the or as a part of the result object and so this would be a global value that includes all the gas used it does not account for any refunds so it's only uh it's increased strictly increased ining every time you do something and each time your execu transaction as part of a simulate that's all accumulated and so it just be

some number that just kind of is an indicator of how much work you put on the Node and we use since we already are accounting for that in the form of gas we should be I would hope very easy to calculate that and then if we put that in a return result then providers have this new thing that they could bill on which is just total gas spent on calls and maybe that would actually make their lives significantly easier across the board um and give allow them to do better more precise billing in general right it sounds for me quite complicate to add that to the gas calculations but I don't know I think I think the clients already one of one of the clients already does this where they

keep track of the total gas spent and it's returned somewhere I forget where maybe some receipts or something and so uh and that's like the pre-refunded amount and so I know at least one of the clients maybe all of them track pre-fund values per transaction and so I think my hopeit here is that all you have to do is aggregate that across all the executions but maybe I'm being optimistic or that's the global gas limit but I don't know how that works in the clients can you add stuff data I I think the refunds are since they are capped it's it's fine if we also just include

the refunds but um I I am just checking Alchemy stocks right now and it does seem to base be based on some kind of compute unit and I'm trying to find now how that thing works good luck anytime search figher says we we build on compute units it means we build on handwavy stuff that we're never going to be able to explain to you it might be just how long the cery took or something like that CPU time on the thread or something yeah seea how does the global gas limit work like each goal and each simulate has it and could we keep kind of adding to that Global gas when we are doing the

estimation um that's a good point I I have to check if our estimate gas is using the same Global cap as well that's something I can check when when you look into that scena if you don't mind can you also check to see if you have to run the transaction four times as part of an estimate does that accumulate four times as much gas as if you run it once or does it accumulate it once right yes I can um okay so basically they have so e call is 26 cost units oh they just flat out just say it's 26 they just say it's 26 interesting they have a throughput CU

that I think is related bandwidth is is estimate gas the same as e call in terms of CPU units e estimate gas is cheaper what be less data it used to be three times more but now they've discounted it to 20 I don't know I don't get it should be stly more yeah yeah yeah um it returns less data yeah yeah I guess if you're compute units doesn't actually mean compute units it actually means compute plus bandwidth I suppose but even that doesn't feel that

significant difference yeah which is the return data compared to the gas price or gas limit right so the trace methods are relatively cheap on compute and they're high on throughput um but interestingly so here we can kind of see it like with the trace transaction you in gas you can specify three different kinds of tracers all of which have different throughput or like bandwidth requirements and yet they are pricing it all the same so it's 1,000 cost unit for any Tracer um

so it sounds like they're just uh yoloing more or less on these gos yeah kind of and so assuming the other providers are similar maybe we we can still involve them and I'm a big fan of getting anyone involved who wants to be but if they're not interested in participating I think my vote would be to just see how hard it would be to just calculate the total accumulated gas cost over a transaction return it and that way should one of the providers in the future want to stop yoloing and actually do a culation we give them the number and they can do it and if they don't use it hopefully it's not too much code complication I mean we do have somebody from in our chat so we could just shoot a message yeah in the

telegram yeah I'm also tenderly because they do have this estimate guas bundle what about the each Sate tracing version that's Al something that could also calculate the gas I guess if if you want to make that kind of version as well and I don't know if I guess adding the gas estimation stuff to the tracing API then that would be it would be even heavier rather if you had the tracing and the gas estimation there it's depends um but yes I mean if you want to add everything to the same

method I mean doesn't sound like the best idea this basically how uh graph something works right it's everything's in one method and you just Define what you want out they have nice query language for that's true they do give you nice query language for it so clearly e simulate D3 we should yeah we should invent a query language implement it exactly that's where I was going with [Laughter] this okay you could write with with

solid you could write any code and you could run it and it would we could just add new methods to it to the solidity you can C different state of the database so we're going quer language but it's going to be solidity based yeah for graph based quering okay um anyway don't want to hug this whole thing I'm trying to find the prices off tenderly but haven't had any luck um I will continue to check but I just wanted to raise a point that this might be something um that we should take into account for deciding whether to include estimate gas in it simulate or have it as a separate method I'm I'm not totally

opposed to doing a separate method as long as the separate method also returns all the results that e called us and so then providers could charge more for because it's I mean my intuition was that SM G is much more expensive and should cost more like I'm totally surprised Now by seeing this uh thing from Alchemy but then like if we have the more expensive like we are already doing the computation in estimate gas and we might as well just return all the results so that's fair for me The Annoying Thing that if you're calling estimate gas something then it actually RS everything so then people then it's in a way kind of just Superior method than than e simulate one is sounds kind of like

conflicting or kind of confusing yeah I guess it would be like is simulate and po man's version of is simulate I think I agree it's it's a strictly Superior method if you are cost agnostic if you are not cost agnostic then simulate without the gas is actually cheaper like if you're running your and paying for it but that's not true you can as a user you can still kind of it it would be cost exct the same if you're not using the gas estimate ability yeah because Alchemy you'll lose with their pricing no no I I mean if you are just calling it normally and you are not

never using the gas estimation it it would cost the same and it would operate exactly the same as well it's just kind of it's just a feature no know I'm saying if we made it so eth simulate estimate gas returned all the results that e simulate did plus the gas estimate versus eth simulate um V1 or V2 or whatever only Returns the results and no estimate gas each simulate would be computation computationally less expensive to execute because it doesn't have to do the gas estimation process which is very expensive to the on the server and so if you are uh evalent to the cost of your queries then you're right e estimate gas is is better but if you care about performance or you're

running your own server so you're paying for your own Hardware or whatever or you're um you actually care about you know how much load you're putting in the server then not estimating gas in situations where you don't need the estimate is superior but you are just limiting the user in this because if the user kind of if you're using your own node in a way and you you know what kind of ques you are making to to it then you should always use the the estimate gas because it's just more powerful method yes the same if you running no no no it doesn't cost the same that's what I'm saying it cost the same if you if you're the estimation no no if you if you're not using if you call eth estimate gas in

this hypothetical where we make a new method if you call the E simulate estimate it would actually do gas estimation so it would you know run the transaction multiple times if you call E simulate it would only run the transaction once and so the computational cost on the server is lower for E simulate than it is for E estimate gas but are you saying that you cannot use the estimate it estimate without specifying the gas limits oh I'm I'm suggesting if we split the methods I feel like e e simulate should always simulate because it's literally in the name there should not be an option for turning it off you will get simulations no matter what or sorry you'll get estimations no matter what if we put them both in the same method like e simulate 2 or something then I do think

we should have an option for turning it on or off oh I wouldn't do it like that because if you want if you have transaction stack of three transaction yeah and you only want to estimate the last transaction then I wouldn't estimate all of those three because it then it will modify those initial two transs I see so you're saying like in our case for Interceptor for example we're adding things to the stack iteratively and so we generally only need to estimate the most recent one and then we save that to client side and we don't want to estimate all the other ones every time yeah and I would imagine many other cases as well you might have transaction that you cannot modify yourself yeah that's fair okay and so you're saying if we if we made it per transaction gas estimat so when you do e

simulate estimate you would say which transactions you want to estimate and you could give it an empty set in which case it is now just e simulate P1 exactly yeah that's why I'm saying it it kind of it's super Method All Around yeah yeah okay that's a good point user consider that I am convinced to be in back in the camp e simulate B2 and if the not provide I also think that we should just add it to the each simulate and then add it to the gas the global gas calculation so then it shouldn't be making the method any heavier because it would be always

limited by the gas amount of course it maybe you would generate kind of more gas heavy transaction but it would be always limited by the the global gas limit yeah be fine with that like I said I'd have a preference for returning the total amount of gas used across the whole simulation um just if that's easy in the clients so that way providers have a way to build on it if they want but then if you make a V2 method and and it's heavier for the providers then it's bit I know that people would be contining to the V1 and V2 and it's in a way V2 wouldn't be exactly Superior to V1 in that sense if you if the

providers are pricing them differently right which is kind of I think a good argument for why we should give the providers a way to price more reasonably by returning as part of the results that a total gas used I can't guarantee of course that the providers actually use it but I think it'd be nice if we at least gave them the tools I'm wondering that we don't need to do that if if we have had the gas calculations for the the simulation or the estimation part and then then I think the V2 would be kind of just better approach well so ideally providers would be charging based on

actual computational cost they wouldn't just have a flat rate for all eth calls not all eth calls are the same whatsoever there are eth calls that are extremely cheap like simple eth transfers their eth calls are extremely expensive but some of the providers at least Alchemy are charging just a flat rate and so by giving them the um total gas spent we're giving them a way to charge more reasonable fees they may not choose to use it they may still just charge a flat rate for everything because they think it's simpler they think users will like it better or whatever but at least they have the option of charging something reasonable right now they don't really have any good options like they could do things like you know monitor the CPU usage but that gets hard when you have a you know massively multi-threaded application

it's got you know 500 concurrent users it's very hard to keep track of which user is doing what at any given point in time and so this would just kind of be a mechanism that would allow them to change their pricing scheme to something better in the future kind of optimistically hoping that people take opportunity if they don't then I agree is right that if if they just continue to do flat rate then it's could be problematic but it would be interesting to find out why the current the estimation is so cheap compared to the eat call it could be that in the eat call people in generally make heavier calls than with the with the simulation and that that's

why in they have kind of her stick and that's why it works kind of that they can have discounted it oh yeah maybe there's do looking at like averages over time yeah they're kind of seeing that oh people are spending more time need eth call versus e estimate gas so let's drop the e estimate gas and that's because people are doing things like Unis swap queries quot queries which are insanely expensive using eth call but eth simulate is always like something fairly reasonable and gas optimized okay yeah I see it yeah un makes huge eat calls for example you know to C all the balance of all the pools yeah crashes are Ser every time

someone uses horse swap anyway I guess the summary here is that we should be asking not providers what they want can you see seea ask around about it uh I can ask wait and it would be interesting to know why the estimate gas is so cheap yeah I am interested I'm wondering if it also has some um yeah I mean I guess what you guys said like just probably based on statistics um but wondering also like recent changes to estimate gas made this

discount possible because the docs clearly state that it was more and then now like they strike through that number put the new number so something changed um yeah I am curious what my my guess is that they heard that go ethereum and nether mine changed their gas estimation algorithm then they went and did an evaluation they're like oh we're way overcharging for E estimate gas let's fix that but their evaluation had nothing to do with your guys's change it just had to do with the fact they probably never actually ran the statistics previously and so they ended up using statistical meth method and

they're like oh e estimate gas is always is cheaper on so we'll charge less and so all your guys' gas changes did is just caus someone to go look isn't this an Arbitrage that we should now modify all the application to use the the estimate gas and then you need to find some kind of trick how estimate the gas amount we can kind of get the same information oh that's devious so if you need so if you want to do a price quote on Unis swap what you do is you do the price quote but it's inside ofne estimate gas and the price quotes value is returned by burning gas until you reach a certain Target and

then the number that you want out is just embedded in the gas exactly so you just grind grind out huge amounts of gas on the server burning it down so you can gr get your uh save a little bit of money on that call that's that's good I like that maybe we should update horse swap to see estimate gas for everything I guess the problem is that it the estimate gas the variable is not very long but it returns like with the E call you can return quite a lot data it's 256 bits you can cram a bunch of stuff in there 32 no but but that's the global gas limit you are

hitting uh yeah I guess you had to do it in under the global gas limit that's fair which is like 100 million so I guess it only works if your number fits in 100 million or less yeah yeah I mean said it was actually sign cheaper you just run multiple times and say this is the first time give me the first first time nend bits and then run it again second end bits or a third time a third end bits and you're still cheaper than e call but it was three times cheaper so you can run it three times whatever what however much cheaper it is you can you know it's an optimization for the the golfers to to very little cheaper but still oh just a little bit okay 26 versus 20

okay but if you need kind of small only small number then it's kind of better to do it like yep do have anything else I don't not from my side does Ro have anything oh working on the number mismatch right now yeah okay well talk to you next week