eth_multicall Meeting, Apr 29, 2024

Transcript

hello hey so the last issue for me is the ESC sender I'll fix it soon and deploy it to you with empty blocks F in yeah you're feeling that with the block time stamp with one I guess mhm yeah let's see if others are joining M

said that he cannot join this time but let's see the others just wondering if in theory we want to make it dynamic oh this is not really needed for V1 yeah I would imagine if there could be some constant parameter that is that is the what is the time stamp then I think should come from those mhm but but I know where the 12 seconds come from I don't know if the evm even knows about it and so there's probably they might not be a variable mhm all right have you been able to run the test sh

locally so that you are getting the differences to the get uh not yet I was mainly focusing on fixing the main issues with the okay merge conflict that I had and the little things that you've sent to me yeah like I checked the trailer I think all of those well there was the has thing but other than those I think everything was fixed there and I think the getting the hash match should be in the way the last thing that when everything else matches and hash doesn't match then you should look what's wrong with

it but I think in many places it's all or matches and there's some inputs where it doesn't do we have really cases where the matches I think yeah perfect but not always there's some differences with the time stamps for example and those are some weird I know why the time stamps are somehow different and that's something that I wouldn't expect the time stamp to be different I think NE mind is getting somewhere for the 12 seconds thing and then get this using 1 second or something like

that but it didn't happen every time so no that's why I wasn't really able to figure out where it comes from that's strange we actually like tried to force plus one in timings but I'll take a look yeah hey guys he hello uh sorry for missing out last time I was traveling and um I don't really have a lot to report for this

week but yeah I'm planning to look into the things that kimy found and also do the refactor for yeah and you as asked about that test that I'm simulating it not latest and I have been I have that test like that already there so it should overwrite the boxs the future blocks with that okay and I think that has been working with both net and [Music] G hey lash he hey then I think we have everyone my gu is

not joining today I don't think we have much to discuss I as asked about that that when we are doing the filling then what should we add to the time stamp and I think it would be logical in main that add 12 seconds between the blocks but then we have agreed before had that we always add one and I wonder if that can be confusing for the users but is there any way how we could get the kind of the blocks what is the general the time stamp difference between the blocks go ahead go uh so we have um I think a

configurable parameter because on some networks we have a different slot time so for example onos this chains we have 5 Seconds uh blocks um but yeah we can generally uh use it very easily so it's fine for us to add for example 12 seconds or 5 seconds or whatever is on the actual chain I think we can even potentially add a um parameter to the config object like default Tim stamp that's the default diff time St or

that I think there was some other place that when you generate new blocks that's also that we add one second to those and before we agre one second because that would work on all of the chains but I don't know if it's complex to make it depend on some variable instead of always being one second no I think it should be straightforward but should it be config variable or is there already some known variable that we could use for that some kind of client config that they they're already setting somewhere that you could utilize the same thing gu doesn't have something like

this that's why I'm also suggesting potentially adding into the method if you want to have this feature as standard that every client implements it but yeah I'm not a strong position yeah that's something that I'm worrying about about that then then we add new variable there if it doesn't exist already and but I'm bit surprised it doesn't exist already I know where the 12 seconds come from is that that's not in the evm I guess but I guess then we should keep it at

one second but I can imagine that people will have issues with that so 12 seconds comes from C layer currently this is how it's configured that every 12 seconds there's a slot um there sometimes are missed slots and this results in longer uh PES for E more than 12 seconds but 12 seconds is default and most of blocks come every 12 seconds just wondering what happens to a transactional contract when for example we had like intervals one one one and then we would get something like a thousand because a user can specify any

time in his block and so he could specify like time number one and then time number one million would it be all right it will it will happen whatever will be programmed in the contract right so MH the just the AVM can just ask for the time stamp and then it can be whatever depends on the contract does it break or not but but it should work yeah but by default I would use the default block time for the network yeah that that's just the problem where do we get that information if it if you make new config parameter then it can be

it's kind of more broad that someone forgets to change it but you know like I said never mind it's already there in the config for the network because we need it for something I don't what we using it for but we need it here and there so we it's already there I wonder why get doesn't have it then well we don't explicitly support other chains and I think if the other chains were because usually they have a fork of gu and they could override this variable let's say so yeah I'm I'm kind of okay with

Lucas's suggestion to to use 12 seconds and then for other chains somehow they they need to figure it out that should be when we are filling blocks then we 12 seconds and also when the user is adding more blocks but they don't spe specifi time stamp then I think we should set the time stamp as as the parent plus 12 seconds so do we agree on doing that then but yeah I feel get should make it so it's somehow that some cons that that can be easily modified okay so which would be our default time

the time of current Network 12 seconds meaning for now yeah 12 seconds but then you should ask from Lucas if there's a variable where you should fetch it so that you are not Harding it data from the variable but as I remember currently in the protocol we have something like specified it to be 1 second so we are changing that yes yeah I think everywhere we using that one second then we said 12 seconds instead mhm perect there's two places there's when we are filling the blocks and then there when the user hadn't set the time stamp then the default will be 12

seconds okay do have anything else not from my side I guess everything is clear there's still some amount of failing tests and then hopefully though will those will be going down so we can then release finally y I guess first it go up when we

do the refractor and then they will go down yeah do you know when you get that done so I can start looking that and I haven't modified any of the tests so then I'm expecting a lot of the of the tests failing and then I can see if I should modify them or some of them I probably keep as as as they are so they test think that it doesn't behave like it used used to behave yeah I mean if I um get better now I'm hoping in a few days yeah I I started on on Friday but yeah so it still feel feel

straightforward to implement uh um yeah there was only one small Nuance I remember because when we are generating the blocks in the Gap then we cannot do it like fill all the fields in advance because for parent has we need to First execute the parent block and then fill it but that's um that's the only one I faced right now yeah you have to do it sequentially I guess that's that's a problem that you always have to generate one block and then you can only after that you can generate the next block yeah

so I think what I'm going to do is just like do a first pass and fill in as much as I can and then start executing the blocks and then fill in the parentes the base Fe also is dependent on the previous blocks though if they're empty you can the calculation is pretty simple uh true yes well but for wait wait for ah yeah yeah we can't even fill them for empty blocks right because uh we need the parent gas used yes yeah so I guess if your empty box blocks are at the beginning then you can

pre-fill them if there's like empty block empty block filled block empty block then that last empty block you can't pre-calculate until after you run the fill block but why are you even feeling some of the fields wouldn't you just over generate one block and then then you run the evm and everything and then you anot block like one by one um so this was for a preparation phase basically like there's some validations being done for example that the block number is increasing and so on and I use

this chance to some details but yeah I mean I was actually thinking about your suggestion also to just do the minimal thing only the validation in the first pass and fill in everything up um during execution I'm going to yeah I guess you want it to fail as fast fast as possible if the what input is incorrect yeah yeah the validation I I I insist it should happen in the beginning and fail as fast as possible but like the everything else can come later but there can be for example wrong nons and you don't know that you only know that after the

simulation yeah yeah only the things that we can know in advance yeah guesse you could precompute all the nons before beforehand but then I'm not sure if it's worth the complexity to do it beforehand and then you calculate it again anyway later on yeah I'm I I would start with something simple and then um add in optimizations if it was necessary yeah does mik have anything to discuss

about is everything clear I don't have anything else I don't think then we can continue next week sorry was l no worries we already made decisions that you don't agree yeah okay talk to you later bye thanks guys bye thanks everybody bye