eth_simulate Meeting, Feb 17, 2025

Transcript

we were just debugging with Cena getting the high test running again then we got all the test except one running and then we try to figure out what's wrong with that test is it seems like that test works on the main net but doesn't work in our test suit you mean it doesn't work on the simulate fork or simulate branch that should be the main brch or the master but it doesn't seem to work there but then it works on everywhere anywhere else oh I see so we've got some like leakage or something occurring in our test Suite like cross test leak or something I don't know it's also that

the the the chain that the tests are running has changed that that could have an impact on it but then that test doesn't have anything that could kind of care what is the chain underneath like some of the tests were failing because the that chain the test chain was have been changing and I'm really fan of that that all the tests are using the same test chain and then if someone is adding more stuff to it then it kind of breaks all the tests but maybe that's a good if you get it get it to merged and then it's somebody else responsibility that if they add more blocks to the chain then they should be fixing the it s like this as

well oh you're saying that the test Suite is run on top of a certain set of blocks yeah and you're say you you think that we have someone changed that set of blocks that's been run on yeah they added 10 more blocks that that broke some are those blocks Universal or is that set of blocks just like per test fixture it's for all the tests oh yeah that's bad you should have the set of blocks like scoped in some way say all these tests use these this set of blocks all these tests use that set of blocks otherwise yeah like you said every time you add a block you have to rewrite everything yeah but Ro if you have to

leave soon then let let's hear from you what's the status uh is it for me yeah okay yeah sorry uh for me I help D danu for d d is an intern NE mind he's working On th simulate and debug simulate uh yeah I helped him to write those end points and for my case uh I hav't get much of time to work on simulate but now I'm since I'm free with the other task that I have already done so I can focus on it from uh today uh so I think Ro after you I'll

also go so um yeah uh so as Rohit mentioned that I'm I just joined nether M uh uh 3 weeks back so I have released the two endpoints for uh uh debug simulate and Trace simulates which uh which basically um which basically perform the simulation on uh get like uh block Tracer and parity like block Tracer and I got some few PR comments from lukash around some more refactoring that is needed so I'll just uh do that and uh try to uh get the pr merged hopefully within this week that is from my side I guess that those end points are not running somewhere that we could try

to ous to it to test what did they look like uh they won't be on Main net yet uh yeah the the point was to get those know tested that that they can can be done and then discuss more more about them as like testing so that they weren't supposed to go to main right away but I don't know what what they have discussing about them since then we would we would prefer that the they would look the same in all of the clients I don't know if there's many parameters or kind of things that we should be deciding how they should look

like or how standardized that all that stuff is I see uh R any thoughts here so for for for testing of this stress end points yeah yeah I mean testing and checking that the the input and output are the kind of the same in the other clients that is there something that we need to decide on what they should look like or is there some kind of agreement right away that they should look like certain way like Cena probably has a lot opinions on how it should look like but I don't know if there yeah so I guess what killer is saying it would be nice

to see like this the schema for this API that you guys are building because then we could all coordinate and try to have a similar method on across the different clients uh so if you guys can just publish something about how the looks like and and um Pro possibly provide like a branch to kilari so that he can test it and see how it works sure so I can actually uh share the sample I can actually like document

the sample payload endpoints and share it with uh all of you uh but where can I share it like what's the channel or anything you can share it in telegram or in the now if you're discussing here you can share it in the chat as well okay okay right now I may not have that document ready clearly I'll just create the document and share it on telegram okay that sounds good sure thank you thank you and I guess there's two apis uh there's two apis yes one for uh parity like block Tracer and the other one for G like block Tracer okay yeah I'll share the branch and P with you uh soon on

telegram that sounds good yeah thank you I think we had some discussing the it simulat that we should [Music] decide oh yeah there was that it asking for some inner course simulation and then Cena commented that that that's probably very difficult to add and I also haven't heard of that anyone needs that kind of things before and then there was also setting some depth parameter and then make calls yeah so I guess I can go now

um uh so we were trying to debug with Kari um to fix the hive pipeline because now basically it's kind of not possible to run the tests um that should be fixed soon I I think and um yeah I still have the pr open for the issue discovered by bisu regarding the block hash and yeah this week I will try to get it merged so that's my on my agenda and something else I'm posting a PR in the chat

someone uh made a fix for Prague for a simulate so basically it's important to uh process the system calls um when doing the yeah when running isimulate plugs so we were not doing this and so I mean I it might be a similar issue in other clients that's why I'm raising it here what's the issue do what so basically with Prague we have a few new system calls one being pro to process the withdrawals um so yeah these have to be

processed after running the block result are there withdraws well I mean if in the simulation block there is a withdrawal request from a smart contract then basically what will happen is like for okay so yeah it will show itself in the block hash because these will be hashed up and put in a in the block header as part of the request hash H so that's one and I guess we also might discuss whether we want to add

some more Fields like withdrawals or something but I mean I guess not I well it's certainly an option to add requests also as a as a result but since we want to maintain compatibility with the um RPC interface of of a block then probably not yeah with type for transaction we didn't decide how it should be structures so that can you bypass the the signature checks but there needs to be some kind of from or to be be delegated field I guess we didn't decide on how we should handle

those or you suest that you can even bypass so that we don't add that kind of sign through pip you can just set the code of the any to what you want so that in a way that's in a way not mandatory to be able to SPO those but I think it would be still useful that you would have been able to spoof them all the way I think this we have to raise uh on um different Channel because changing this will affect e call as well and yeah yeah but what is the right channel for this the RPC channel on e&d Discord I'd

say uh so for withdrawals and other requests we use the same code more or less to well exactly same code in in this instance to run eth simulate but the block we are building doesn't have any of them so it would work in never mind I think out of the box if we change how to create the block now I can raise that RPC issue in the channel see if anyone replies to it but I know who are the people who are working on these things I thought it was for the get side it's it's the Cena working on these things getting

the those new parameters have an opinion as well okay dictator of the CH RPC yeah um we also have here Tony Tony are you from B by any chance uh no I'm not I'm from in infra inra in oh nice oh didn't you have a question for infira Alchemy quick node Cena for what it was a couple weeks ago

gas estimation stuff the gas estimation yeah we should use this up yeah it does need a bit of context I'm trying to remember um about if you add the gas estimation simul simulation straight into each simulat or should it be a different method load on node operators I guess the issue with the gas estimat you need to run the transaction multiple times and then it can make it very gas heavy yeah

so question for you Tony if you're since you have some views I'm sure on the infrastructure side of things so when you do a g estimate gas the transaction is executed multiple times and so the op operational cost of running the transaction um is AC crude multiplying because basically the gas estimation strategy is more or less are a binary search like you run it with a certain amount of gas see if it passes if it does you run it with less see if it passes and you bisect that if it doesn't and you do this multiple times at the very least you run it twice and so this makes eth estimate gas more computationally expensive on the Json RPC node than something like eth call which only runs a transaction

once for E simulate we discussing whether we should add like a flag or something that makes it so when you call E simulate you can have it also return the gas estimation for one or more of the transactions in the simulated block or should we move that to a separate method so it' be like e simulate estimate or something or E estimate gas simulation or something I don't know what um from an infrastructure standpoint do you have any thoughts on like infrastructure people have to charge differently for each method depending on the utilization of that method does it matter to you whether it's one method that has one Json RPC method that has two different like a

parameter that makes it cost more or less or is it better to have two separate methods that can be build or charged differently to your end users um I cannot speak in I mean on that like on on the behalf of theur commercials uh uh from a user perspective I think like as a developer I would prefer to just guess get the the guess estimate as part of the PO response instead of how to call you said you would rather have it as a parameter so just like a flag you can pass to the call yeah okay I mean as a

developer right right so as as a developer You' find that useful you're not sure on like the billing side whether that makes a difference yeah exactly I can relate that and discuss that with people but yeah can yeah if you if you can ask around and find out if it would make a difference I I tend to agree with you as a developer I also like the flag method just is a little simpler having less methods having it ensures that the Syntax for them is guaranteed to always be the same otherwise um but we worried that you don't want we don't want to do this and then have you know all the um infrastructure providers be like oh my God this totally breaks our building system

absolutely so I guess we don't still have good decision on there what to do I think for the user perspective also agree would be nice that it's just parameter inter Meed I wonder if just so we don't get blocked I wonder if we should start working on inflation implementation with it as a parameter and then just before we finalize or merge Dom main on any any client we make the decision because I'm guessing either way we like the same amount of work basically needs to go into it either way and moving it from a parameter to a method I'm guessing is not going to be a big lift for any of client that sounds go

ahead yeah I wanted to say that I I don't think it makes a big difference whether like implementation complexity wise whether it's a parameter or a separate method that part is not an issue yeah well I think one thing to decide that does it consume the G gas somehow when it's running multiple times the simulation then consume that Global gas I don't know if the each simulate works like that or or I definitely think that we should so the client configured Global gas limit per Json RPC call should definitely be deducted for every execution so if you're if it you have to bisect you know six times and you have to do the six executions you have to pay

the Glo towards the global gas limit six times you don't get it for free but is is the estimate gas looking like that I never heard it would work that I would hope so but that's a good question Cena or Lucas do you know sir what was the question so you guys the clients has like a global limit on how much gas you can spend in like an e call or any method if you do an E estimate gas and you have to bisect six six times does it count the gas six times towards that limit uh what I didn't understand the question what do you mean six times for so you know when you do estimate gas you have to run the same transaction over

and over right because the B all of those yes yes yes yes the limit is the limit right no negotiable I think the same forget but I would have to confirm I would hope so and if not I I I remember I remember that we had to take this into account I remember that this was a discussion point at some point uh when designing it okay so yeah I think we should do the same thing if we do um add estimate flag or something to simulate I think it should be on the

transaction level so you can estimate multiple transaction at the same time so that's something that we need to decide what's the API for that and then I guess this would be it simulate V2 and not V1 I guess so because uh not providing the gas parameter will change its meaning well if the gas is left out then I wouldn't estimate it I think it should be more explicit from the user that they had to somehow said it that it to be estimate it's quite common that you leave it out and then you probably just mean that just consume all the gas

because you are doing a call and you don't care about how much gas it consumes well then in that case I think it's fine to just add it as a parameter to V1 my an with that is then you are you know that some rpcs support test it simulate and then you make a call and then there's kind of multiple version of each simulat and I'm not that big fan of that that I would like that if someone H simulor one then they would support the whole feature sh yeah I mean I think that that suggested no matter what we're going to have to bump the version if we want to add estimation support which I'm not opposed to I'm a

big fan of we it'll be a very long time dud until we run out of numbers so I'm totally a fan of bumping the version so be simulate B2 and then um that would have the gas estimation thing and I think we've talked about K's got a list somewhere of other things that may go in well or we can just have that and then e B3 would add something my list is s list of success that not all of them are something that we probably all agree that could be there oh sure but then I don't know about the the community would it be that we just add the it similar to V2 and then if you want want to add something else then

that becomes V3 so that we could be just Bing the versions up rapidly but I don't know what the compy feels about it the infamous hard for scoping problem exactly I would be fine with just adding the gas estimation and nothing else I don't think there's anything that as think last that I'm bling with that like I said I'm I'm a big fan of just using version numbers judiciously or not judiciously freely then minut to agree on on this

spec so do we add a new parameter that says estimate or do just for the gas limit would you pass stre that estimate that they would estimate it what would be the good API for this as a user who likes languages that have Union types I am a fan of just having um the ability to pass like the word estimate as the gas limit parameter however I recognize that not all languages have easy to use Union types and so I'm not opposed to moving it to a separate parameter instead and if we do a separate parameter it just means that we have to agree that it's going to be an error if you provide a gas limit and you say estimate or would we say if you

pass a gas limit and you say estimate then we start out with that limit and then still do the estimate or do we estimate but we cap at that amount like we have to decide which one of those if we do separate PR how got the block tag is already that's something that it's already there that can Fe all the clients have to have some kind of support for that so yes but it so all the clients can make it work the question is how painful is it and I would rather not make it ex make it very hard to write code in some clients if it's particularly difficult a global bu like I was

thinking that it's in the each transaction you can Define if it's estimate or not but that's also one way that if there's a global bullan back and then it would estimate all the missing ones that's interesting way as well I mean I don't mean Global like client wide Global just in the simulate method you pass in the that I me so when you set that to true then then all the missing ones I estimated all of the transactions that's interesting way as well yeah I like it as well what does Mea think about it okay I just pasted the four options that

I see set sorry I was only have paying attention to what your question was sign Su fifth version which is that we have the global gas flag and then if that is set then all the transaction that are missing gas limit that they are going to be estimated so it would kind of change the behavior of the missing gas depending on the TR um not a huge fan of that because I can imagine lots of situations including Interceptor where we only want to estimate gas for one of the transactions not all of them yeah but then we know the gas of those yeah I guess we've in in our particular use case we always have

estimated the previous on so we already have the gas limit and so we can just include it we don't need to estimate it yeah um yeah okay so I guess the question is is there a use case where you would want to do an estimate guas on one transac so yes there is so there are situ there are times where we want to do a transaction or we want to add a transaction to our simulation stack and then after that transaction we want to like get a balance or something like get a balance or do a call or something and it would save us round trips if we could just do the estimate at the same time so like Hey we're about to do this this um year20 transfer after the transfer we want to do some balance checks and do

the other checks so we can update a UI somewhere right we only need need to do the estimate gas for the actual call that we're going to be submitting the rest of the stuff that we're doing after that is just so we can update our UI to sell the user what changed when they did this transaction and so I do think there are use cases where you don't want to estimate everything that's missing gas with those balanced checks then we don't need to estimate gas for those we can just consume the whole block I guess you wouldn't then it would to expit set the gas to those yeah You' have to exposit set the gas and you would need to be careful not to over consume because you need to be able to do both of them so if You' got like C some balance checks or whatever you'd

have to like know what the checks how much gas those checks are using um so you can set it appropriately or give them like a ridiculous amount but if you give them too much then you can't actually do both of them because you're not g to have enough gas left in the block to do the second one it just it feels like there is potential for a bunch of complexity if everybody thinks this is a great idea I'm I won't block it it just feels like there's situations where you'd want to only estimate the gas of one transaction and you doesn't mean you have the you know the gas limit for all the other transaction I mean I guess in that case the gas will be estimated also for the UI things that you mentioned and is that

really terrible I mean is operationally expensive it puts load on the Node if you're if you're paying per some sort of rate limit or whatever you're going to exceed your rate limit sooner yeah I mean I if we get some evidence of that then sure but it is much simpler in my opinion to have this like Global flag then per call yeah youi find it sounds the easiest to have kind Global limit or the up that's the simplest API for that but yeah it's not that though I updated my comment in chat with that fifth

one and now we have even more options it's more difficult there too many ways of doing this thing hey Mercy or AES I don't know which of you are transcribing see you later Cena I don't know which of you are transcribing does your transcription get chat or does chat disappear like if we type something in the chat will that make it into the transcript Mercy or either you guys know I'm taking I'm recording the I'm recording by OB and does obis record the

chat uh yeah okay so I just want to make sure it didn't get lost I copy it to the telegram as well L okay do we anything else that's something that we need to decide I guess we need to decide it but it sounds like we can discuss it in telegram yeah so I had uh wanted to ask D about sharing details about uh tracing methods but I see he was here but he's not here right now uh I don't know yeah go conflict half past no I'm not about De

Tano or he ah thank you everyone I was on my comments on my P ah okay yeah he has okay I now I see it okay uh okay there there was a question okay there was one question about the API that we can uh that I can uh maybe it will be trivial so when we are doing it simulate right uh we have uh generally what we return is that we return information about the block right and then we return internal information about each transaction in a block yep um what should be result of the back trace and Trace General should we also return uh

the information about the block like block hash block gas used whatever or should we just return the information about the traces as a list for example in a block list of lists right per block should we also include that block information that's the question my instinct is yes we should include the block information I would even take it a step further and suggest that we should include the between transaction State routes um if you're doing a trace it is it seems reasonable that you might be debugging something such as a consensus fa and being able to see the between transaction State routes may be helpful

this is I don't hold this position strongly it just seems like might be useful and if we're returning the block information anyways maybe we can also include that which is more of a block thing not a transaction thing uh okay but uh how would we return it on Trans on the trace transaction level or on the yeah just it feels like it's it's kind of metadata about the transaction so unclear exactly where you would put it and do we want to add even more additional complexity on it because that's even more complexity to be honest yeah do do clients not calculate the between transaction route no it was an AAP that uh was so long ago that we

don't there was an AAP about it that on the beginning of eum we did even on normal blocks I think it even went to receipts uh but it was change a long time ago because of it was pretty slow okay okay um yeah I'm not not oppos to ignoring that then um but yes I I do feel like we should return the block data for two reasons one I think it's nice if the return result of the API is the same between e simulate and E Trace other than e Trace has more data because it allows clients to use similar data structures and reuser data structures um also I do feel like there are many situations where you might be using the

trace API instead of simulate because you need the additional data such as for internal transaction calls and whatnot um but the work you're doing still does all the same things that you would want to do with each simulate and be nice to not have to call them both and so got all the information for in one call so we generally I think have this it's I think it's more or less working uh I'm not exactly sure if it's you know uh it still needs a bit of work but we are close to to have finalized PR to be honest so that's our current state we' had I think I even hope the would uh uh share something today like have a demo but I think we should have started

with that maybe oh yeah seems like today is everybody is Monday not a good day for people seems like we have the first time well I think he's on Pacific Time or something and it's really early for him or like you sorry not Pacific Us West Coast oh and he he stayed up for this call not yeah yeah woke up for it I see okay I have calls like that I know how he feel he was Shing the very beginning and then he was sharing yeah so uh yeah okay I mean I can do I I can do earlier um I can also do later this is kind of this is an optimal time for me but I can

move it earlier I can do both too I would prefer earlier if you move it but yeah my biggest use case for that Trace would be that when a transaction fails then you would get more debug information like where it failed and I think that's already what it should answer you can get all the traes up into the failure and then you would more information why the transaction failed yeah even just knowing what contract the failure curtain would be useful and I think it should answer that already the feature set okay so I will try to get some uh examples for next

week or earlier sharing telegram sounds good good yeah not me okay talk to you next week bye bye