eth_multicall Meeting, Apr 15, 2024

Transcript

all right Shall We Begin yeah from my side I ran the old five tests with our client the main difference was the time stamp on some of the on some of the items uh looked a bit into it uh and also tried to compile the sinus fresh like fresh node uh for the five tests but somehow hi test died on me clar had you any success in there in running

it I'm not yet Cena made some fixes but I haven't tried those yet uh yeah I think um I've I've updated the P Branch maybe that I think that issue will go right now so yeah that's as for me that's basically it I don't have a lot more to update I also um I am looking into implementing the beacon route override for East call

which of course I can then used for multi um yeah I think that's you were just mentioning that with block override you could set those already so do we need to have those separately I I would say yes you can change them via the state override but I don't know I feel like I definitely feel like having the block override is more accessible for users if somebody would

wanted to do this yeah I guess then we run into issues that you set both of the overrides and then you can need to decide again what you do in that kind of case yeah I think I mean yeah I I would say B override takes priority in this case because the user exp explicitly opted into it but I'm not entirely against leaving it out and leaving it for State over right to handle um yeah it's just my my preference is that yeah because it is a Blog override like it is a field in the blog that can be overr them and it's better to support it

uh like um directly do you know some real use cases why you would need to overwrite that kind of things so I would guess the people who would use this VIP um would want to simulate it I'm guessing it's uh staking contracts mostly I wondering if it's a big use case then we could maybe make it more user friendly but if only few people use it then they probably could use the state override methods of way doing it I wonder how difficult it is to set

with the State Oral I guess just an array and then you to set the array Fields so difficult to set but but something that would be bit annoying to set to figure out that kind of things this is for the um Beacon route right yeah yeah so I think um we might want to verify but I believe because it's a circular array all you would have to the uh offsets for each of the items are well defined and known in advanc and permanent so I think it's like 8,000 item circular array and so you know exactly which 8,000 slots are like today in theory right and they will always be those same

slot numbers and so you just literally need a mapping like a hard-coded mapping of you know the item at index x n is slot address you know whatever um so so yeah so I don't think it's going to be too hard if if my understanding of the implementation is accurate I don't think it would be too hard to do a state overized yeah that's that's fine with me it's also it's also possible it's been a it's been a long time since I've looked at this in solidity but are arrays um contiguous in memory like so if you know the position of the first item in the array you can calculate the position of the nth item by just adding

n times uh word width you know that off hand yeah no not me okay um might worth looking into if that's the case that makes it even easier because then you only need one one address if they're contiguous I don't know if they're contiguous though I feel like in solidity maybe they're not contiguous but with e call you you said that you are adding the this there at the moment but with e call you don't want to add the state overage right away we do have the state so I guess whatever we decide for multi I will also apply to um so if we decide not to add the the block override for be rout to to

multiple then I will also refrain from adding it to it call because I want them to be consistent I mean I would be totally fine with not adding it to eth call but adding it to e simulate so that way people are encouraged to move but I'm also fine with just not adding it I think uh State overrides simple enough go ahead on a related note CA when we talk about the hi tests branch do you mean we shall take stuff from your multi Branch or shall we take stuff

from your like Master Branch so I merg from mer like Master into my brand and now I think the next step is that Hillary merges my Branch into his and then yeah it's possible to run those but yeah I was just wondering about the branch name is it multicol yeah it's multic yeah just against killer is Fork mhm

all right do we have any more topics for today well decide what we do with that yeah I'm I'm still thinking about it so so the um one option is that we just try a blog post how we can do it yeah so I think in this case the time stamp also should be overridden because that's how the contact works it uses the the header Tim stamp to to find the index in the ring but to store the root contract the the root

basically and and it's not it's not possible to predict the time St in advance if it's not overridden so you're saying the execution clients is gets the time stamp from the consensus client and then it uses and it gets the beacon root from the consensus client and then it uses the time stamp to calculate the essentially the slot index and then mod the size of the Ring buffer and then that's the index I think the index is simply time stamp modulo uh I would assume time

stamp divided by 12 modular ring bux for size though maybe that works out to be the same I don't know anyways uh yeah so so and so if we have blocks that have time stamp overridden they're going to look into that ring buffer in a place that that time stamp would have shown up in a slot but now if those time stamps aren't evenly divisible by 12 which is necessary for this to work weird things may happen and stuff may

break and on top of that um there's the big question of you know they go by time step what was that so how does type this go by time stamp and not by block numbers I guess Al so the the beacon the beacon or sorry the consensus client gives the execution client time stamp and Beacon root hash and then if I understand correctly the execution client then deres the slot number effectively or rather derives the position in the ring buffer from that pair of information and the beacon route is useless so all it has to go on is the time stamp and so it uses the timestamp to figure out where in the ring buffer

the thing should go um and I'm guessing that this is predicated on the assumption that time stamps are always 12 seconds apart or it would not work properly well I guess by some constant amount and on some other networks it's other than 12 seconds yeah is it is it literally just time stamp divided by um ring buffer size or is it time stamp mod 12 divid by ring buffer size which one of those is it no it's um time stamp modulo sorry sorry time stamp modulo

ring buffer size and that's it there's no um block length in there there's no 12 seconds or 12 or anything uh there's no 12 or anything this wait but I'm youing like wait what is this basic this is this is theit code let me post it here so if if that's correct that means this this is a weird ring buffer because it doesn't insert linearly into the ring right yeah I mean this this is off top my head my math may be very wrong here but I'm kind of just doing this in my head like you're going to insert randomly into the into your ring and over time you will eventually get the

last you know 8,000 items but I don't even know if this guarantees that they don't replace each other before you hit 800 and I'd have to I'd have to do the algebra to verify but feels weird I'm also it seems also a bit strange to me honestly I I was reading the code for this contract for the first time today and I haven't fully gred it always any anyone happen to know the EIP

number for this 4788 maybe we lucky someone mentioned the rationale why actually there seem to be two ring buckers two I only see one oh wait

I say the time stamp ring buffer and the root ring yeah I hope we didn't fight a con buug I'm guessing this is pretty well tested my fa my faith in the cord Dev to actually test the consensus important things is reasonably high as as much as I Rage Against the cordev process on Twitter I'm actually reasonably confident in their processes today do we you have any other

discussions ex this I guess one discussion what about was the Phantom box what do we do with those um Phantom blocks what was the issue with Phantom block oh should we drop them or not yeah so Cena doesn't like them I'm I'm still leaning more towards dropping them with Cena I know I originally pretty strongly against dropping them

but I I'm slowly being convinced that they're just iteratively making things more and more complicated and you know after talking with um was it bant I think last time we didn't really come up with any use cases that would be significantly impacted negatively by dropping them like all the use cases should be using time stamp and the ones that use block aren't use cases where this would be a an issue they're like short time frame things like you know three blocks four blocks five blocks which in which case you can just simulate four five blocks the times when you need long range we could I I'm just not convinced there's really any good use cases for long range need

of this and so I'm tempted to leave it out like yeah just in theory with this approach say user wants to simulate 1,000 blocks he or she would just like put into the request like empty bodies and correct time stamps or what would be like the user user facing dilemma there how how he or she would need to use e simulate to do that yeah so they would just presumably they would just put in a bunch of empty empty blocks um and each block can just use the defaults for literally everything because I think we even have a default for the time stamp right I think it's increment plus something from the previous plus one plus one yeah so

user could just have defaults for literally everything so you would just need an array of a thousand empty empty blocks basically and we would autofill everything in between um but it does mean that that on the client side it would actually iterate through all thousand of those and generate a thousand blocks and you know thousand block hitters and so all the costs asso with those thousand would be incurred unlike Phantom blocks where if you did the same thing with Phantom blocks you would not actually generate any client cost for the you know 999 in between right you would just skip to the end and only generate the first and the last or something and so there is um if someone's doing this this this is why the costs now scale L linearly with number of blocks of kind of empty blocks

versus if we drop Phantom if we keep Phantom blocks then the cost scale are just constant for the number of actual blocks you have regardless of blocks which is why we'd basically have to constrain the number of blocks that you can include if we don't already I I believe we have a limit for that it's 256 okay so yeah basically you would not be able to simulate longer ranges than that but that is the client side specification so that somebody can override that if they want to make longer ones assuming the client in question provides configuration for that

yeah yeah I I thought that was the idea that that's a config setting yeah then the question would be do we still want to say we have this like range range limitation set on user in like 250 blocks by default or flexible set by the no Ator uh do we like generate this empty configs for the user to keep the API as it is now so that user can write block number one then block number 50 then block number 100 and we'll just silently generate empty blocks for that user or shall we like force the user to insert empty

blocks without any contents uh interesting thoughts there I have two two thoughts on it one I do like the makes the API nice and easy to use even if we are um still generating them um so that's on the positive side I like the suggestion on the negative side I do worry a little bit about user not realizing the load they're they're putting on the client whereas if the user has to explicitly include each of the blocks in a row it kind of makes it brings it to the Forefront of their mind that oh you know the client's actually doing something for every single one of these that I I send it even if it's just the defaults it's still doing work I don't know if that overrides the convenience I do like the convenience this proposal quite a b as a user do you

really care whatever does the client thinging do you just want results uh I mean depends on the user I guess if if you're the person that's also running the node then you probably care if you're not the person running the node then you probably don't care someone else cares generate anything any blocks automatically I would just then Force user to input all the blocks they want to generate so essentially we would have a hardcoded requirement that each item in the blocks array must contain a block number that is one higher than the previous item in array oh it doesn't need to contain but if you don't specify then it's

automatically incremented that that would be fine but there should be enough so you think there should should be something in each position yeah if youate 100 blocks in future then you need to have 100 blocks in the cury and to this point I I think it would make it more clear what exactly will happen in the case that there are gaps well yeah basically if there are gaps then there is some assumption to be made by the user like what Behavior will will happen for those missing blocks but when explicitly they have to provide

everything then they will know that yeah what's what's in there I'm fine with either if you whatever you you guys decide I think it is a little bit comedic that we allow user to skip nearly all parameters when they said block headers or like transaction stuff but we forc them explicitly to peel in the blocks with empty contents yeah I also wouldn't want get rid of the fun blocks but if that's what everyone wants them that's what they have to do but yeah I would also want to kind of be able to overwrite that block numbers is I don't feel it's in a way

any different setting than anything else can we have a vote on do we keep them or not I abstain I will to keep them keep Phantom blocks yep oh sorry um for that one very weekly vote to get rid of them but count my vote for like 0.1 so a tiebreaker I don't know about the complex so I cannot get vot for that but I would want to keep keep them for removing them so I guess lucash

is the F breaker uh all the power to me well to be honest I don't know uh if so I really like them but if there is uh no uh use cases then we can remove them right I like not entirely sure if they're worth it then was the compound was your case was comp was somehow I I talked to bag and the place where compounds using them isn't a place where it would be negatively impacted in a significant Way by this um by removing Phantom blocks like they don't actually need Phantom blocks to provide their use case um I don't remember what the details were

remember we looked over it and it was like eh you don't really need Phantom blocks for that you can just do this instead it's very simple and arguably better anyway um yeah the the the one use case that is there is something that annoys me which is open Zeppelin the people who make they're like an auditing firm and they make some kind of core contracts that a lot of people in ecosystem use um because they're very robust and secure well tested Etc um they actually have a timer contract that you can then has it's a timer interface that has two implementation one is block number timer and one is time stamp timer and I'm very annoyed that exists at all because as an auditing firm they should know better

than to create something that people shouldn't use um but it does mean that there may be people out there using the block number version of their timer despite you know all the Auditors and the ecosystem telling people generally not to do that but you never know you know people when you put something out there into the wild people use it for things that they're not supposed to that's the one place that I worry again just because we don't know what's out there okay so and what's what is the four removing argument that it's more complex yeah it's just as lots of small bits of complexity are added all over this feature because of phantom blocks uh there's no single thing that just makes Phantom blocks

really complicated or impossible it's just lots of little things you know lots of if statements here and there for dealing with Phantom blocks and so the idea was we can get rid of it get rid of some complexity in the client's implementation do I understand correctly that basically the use of the Phantom block would be if you create a dep for example to vote in the general elections and that vote have a timer like please vote until this certain time then on the like after block at time x you want to see the votes casted and you can get results and before that you

cannot um not quite so everything you said correct except for instead of the vote being time based it's block based so the vote finishes you know in 1 million blocks rather than saying the vote finishes in one month um but even in that case you can overwrite the contract in the multic and that's what we are doing in the Interceptor that we are overriding the contract with our contract that bypasses the time time fee so we don't wouldn't need to use the multical that feature for the since we can just override the contract and I guess in the all cases where the block block number is used we could all just override the contract but that always requ that you to understand the contract

more better when you're doing the simulations yeah so so basically this situation you described o is almost exactly correct except for the switch from time stamp to block number and the place where that's particularly useful is if you want to build a tool that allows end users to um fast forward time so to speak without having to know anything about the internal implementation details of the contract they contracts you're interacting with so again using R tool Interceptor as an example user goes to adap website interacts with it and then clicks a button in our tools UI that says fast forward Time by one year and then continue interacting on the website the website will now see time has moved forward by a year and you know present things appropriately um but the user doesn't have any clue how the contract is

implemented they don't know if the the contracts implemented using time stamps or block numbers or anything else and so our tool would fast forward both the block number by you know the time one year times 12 second or divide by 12C increments and it would update the time stamp on the block by a year and whereas if we don't have Phantom blocks we would have to we could still do the same things we still have our fast forward Time by a year button in our UI user can still click it but we would only fast forward the time the block would only move forward by one and so if the contracts that the DAP is using are um expecting blocks to move forward over the course of a year by more than one then the D may not function as the user expects this is again it's kind of an

edge case of an edge case sort of and so it's questionable whether this matters that's the the gist what was the latest like complexity issue that broke the camels back I believe it was Beacon right CA Beacon Ro I think yeah we did discuss that um basically look had the idea that maybe maybe we can solve it by simply ignoring the problem and it will be fine um but that just made me think about this and question like do we really need this and um I to me it felt

like it's basically um it's it it's not intuitive how some things should work in this case for example the block hash we know that that's a um tricky thing when it comes to Phantom blocks both the block has up code and the block has in the header and then there was the Bas view where we on this call me and Micah had a different understanding of how Bas feed should um should work for for Phantom blocks like he thought that Bas feed like basically Phantom blocks are average blocks with normal number of

transactions in them whereas I thought that Phantom blocks are empty um so I just felt like there are some intuitive things about them for the user as well as like in the implementation side there what would be the main difference between the case when they are empty and when they are filled with like mean transactions so the basically if the the Phantom blocks are interpreted as empty blocks then the BP should go down by the time you reach block 100 it should be very L how however if they are average blocks then the base spe should roughly remain

same look yeah so as as you made me your leader and made me decide then let's remove Phantom blocks and let's just move move forward because uh I I agree it's like it's uh a lot things to be specified right that that could go one way or the other and it's like both are similarly intuitive so uh and if there are no use use cases that are known uh then let's just drop it and simplify things a bit so then the behavior of a phantom like not a phantom but empty block would be averaging the previous

block and we'll get to the same point that Mika had with like the block that you are actually doing any work on is the average block of the like initial block that was just before the start of e simulate uh what you're talking about for the base fee calculation yeah for the base fee for the like everything yeah it would be empty blocks right if there wouldn't be Phantom yeah yeah so if there's no Phantom blocks for the Bas Fe calculation you literally just calculate Bas Fe exactly the same as consensus rules tell you to which means look at the previous block how full was it calculate the base fee accordingly so if you did do like 200 empty blocks in a

row your base fee would drop very significantly um and if you didn't want that then you would need to specifically specify Bas Fe of something else oh poor users it would really really suck for them I think because they would expect it to be like realish but the current uh consensus is that this is not really a useful pattern to begin with yeah exactly I think they is the most the vast majority of people will probably just do like some number of blocks um in their simulation and all those blocks have content in them they're all meaningful to the user for some reason or in some way um it's we the idea here is it seems unlikely that people are

going to be or rare that people are going to want to do like big jumps in terms of number of blocks and so the the pattern where usually user provides an array of 200 empty items is in theory unlikely to be a common pattern or something that users will want to do that's that's our hope at least so I guess we agree that we are removing then then I guess we need to accreate and how does it impact on the things and then we discussed about can you still kind of Le blocks out and I would vote that then you have to specify all all of the blocks and you cannot

have gaps in there but then can you still specify some of the blocks and then leave some of the block numbers out and then we would calculate the block numbers for all of them so just one more thing I think that what we are currently doing would lead to quite scary behavior from the end users and like recalls to his call is simulate because they would need to like to simulate the thing that normal user would have it in his mind the mean block he or she would need to get the latest contents then here she would be able to create latest then content then 1,000

empty is blocks then here she would need to put into the empty block stuff here or she copied from the like latest and then here she would be able to do the real testing that really really I think that idea is that we don't expect anyone will actually do that thousand empty blocks like there's no reason no good reason to actually include empty blocks in your simulat and in case uh in case that is needed to simulate average blocks for Bas fee purposes then you can override Bas fee in the empty blocks to stay the same um as the latest point I guess yeah but as you want to cheat and

like make API to do this cost free you explicitly set to zero every of these empty like X blocks that you allowed to do and set the correct one right before the block that you are actually will be emulating to like to make it actually work for you so it would lead to quite dirty API use cases just to like bypass the absence of phantom blocks because users would want to probably think as if block were full and by the way when we test our fish currently we try to fill it not with maximum amount of transactions per block we fill it with like two or three or five or something

like that and like presume that next block will be assuming a lot of details that were in the in the base block don't we I think the idea is we would if we drop Phantom blocks we would remove all of the tests that test the Phantom block Behavior so all of our tests would turn into that common use case that I just showed there where you just have latest followed by one or more blocks that have interesting things in them and um and that's it we wouldn't maybe we have one or two tests for the empty block case just to make sure we cover it but presumably that's

the it's it's not not something that we think users want I guess is the argument here if if we think users want it then I think that is a strong argument for keeping Phantom blocks I'm just when we looked into it we couldn't find any good use cases for that at all my main problem is that as soon as we start to think that like blocks in the middle are empty at all like to simulate that they are fi we would need to fill them with some random like fast stuff uh it makes this API much more complicated for use what uh maybe I'm not understanding why would you want to so the main issue is that as you said if the block is

empty and there is no transactions in it something goes down and it deviates from the mean case and when you simulate 100 blocks ahead you don't want to have like something deviated Too Much from the mean case you want to have that mean case like in place and if you would need to simulate to to feed it data to simulate this mean case it would be quite complicated right so the argument is is that no one wants to do that um no no one wants to sim simulate many blocks into the future the the idea is is that all use cases can be accomplished by simulating you know just one block or maybe two blocks maybe three blocks but it's very

finite and each block has a purpose and something in it and it's interesting um do do you is that the part that you disagree you think that there are use cases for people simulating um far blocks that are in the distant future or distant an hour yeah DBS DBS connected to each other every voting scenario when you can have voting like happening on a long periods of time right so all those re voting all those cases though are time stamp based and you can put the time stamp very far in the future it's only the block number that you can't so you can do like you know a year later time stamp it's just it's a year later next block like it's as if as if for some reason you had so we can see this in the E so anytime

there's a slot dismissed the E jumps forward by 24 seconds instead of 12 seconds right so the time stamp moves forward in in one block the time stamp moves forward 14 24 seconds instead of the normal 12 and so the idea is is that if you want to simulate something happening in the future you just pretend like there was you know 10 million missed slots essentially and so you know block n is time stamp X and block n plus one is time stamp X plus a million or something wouldn't this confuse like half of the potential contracts on the chain that that is that that is the risk so there is the risk that um there are

contracts out there potentially that are using block numbers when they should be using time stamp now all the professional Auditors and experienced people in the ecosystem that you know give advice to newbies and write tutorials and all that I'll say use timestamp um these days but a long time ago um people used to use block numbers as a proxy for time stamp because there was some misinformation around how accurate time stamps were on ethereum for a couple of years early on and so there are definitely are contracts out there that use block number when they really mean timestamp we don't believe any of the contracts that people use on a regular basis these days still have that problem um the ones that did have

that problem didn't generally hit off because they generally also had other problems um and and so the the theory that we're working off of or that we hope is true if we remove Phantom blocks is that anyone who cares these days is using time stamp for all those things and not block number and in theory almost no introduced block number in their contracts at all there's very little reason to aside from doing proof things and stuff we could be wrong that's that's the big risk if we're wrong on this estimation and it turns out that oh apparently everybody's using block number I don't think we're wrong on that but it's possible besides block number it was said that something diminishes when you fill in with empty blocks with like no

transactions uh in the mean case when you have Phantom blocks this something won't diminish that much question I think even right now if you fill if you Prov provided a block with some content followed by two empty blocks where you just had like an empty object in that place in the in your API call followed by a third block that had content I believe we would still diminish today even with even if we kept Phantom blocks because you are providing a block and so they're not actually Phantom blocks in that case they are now real blocks just with all defaults and the last dumb question if we change the time between two blocks

too dramatically shall that block still be validated if validation mode is on if we like don't chain yes I believe that there is no constraint in the El that consecutive blocks need to be within a certain distance to each other because the like I said earlier ultimately the CL could have you know a thousand missed slots and the El needs to be able to recover from that which means it needs to accept the next block in the chain being you know a th000 time St th 12,000 seconds in the future or whatever that number is and so I believe that for consensus reasons on Main net um the Els currently have to support unbounded increases in

time I guess the latest block number is bit difficult because if you want to specify the block numbers then it might not ex know what is the current block number but I guess we can always allow that you leave the block numbers out so you can put the latest and then you can simulate 100 blocks and you don't specify the block numbers and they would be always based on the latest look uh yeah that's my assumption is is that if you don't include the block number in any of your blocks then um in fact I mean we have two options here if we if we drop Phantom blocks we can just remove block number as an override field all um or we can leave it in but always require that it is plus one from the previous and if you leave it out then we

automatically fill it in with plus one from the previous there's no option anymore for having block numbers be not the previous block plus one if we remove I thought we already decide that we are dropping them so I would have start to move forward and that we are dropping them and how that would modify the multical behavior them and what we need to agree there yes so I don't think we have to change anything on this do you think something will require a change here other than just you know having an assertion early on that the blocks are consecutive I think we have to agree that if you can you do we need to specify all the blocks or not or do we can you leave them out and then we

generate something something there and if we generate something there then we should agree what are we generating there I see so if we leave them out if we allow for leaving them out then I believe we should just use all defaults using the defaults that we have documented already for every field and that includes block number and the default for block number should be block previous block plus one as for whether we should leave the allow them require them always should we go with Oleg suggestion earlier and allow for just um allow for missing blocks and then we just backfill them automatically I'm okay with that I'm but like I said I'm on the fence and I'm okay with you guys deciding otherwise I think that just you ual it's useful

that you could be able to specify the latest and then produce block based on the latest block number but that you would always happend on top of that and you would then need to specify the block numbers at all and if you want to specify the block numbers then I feel they should be ahead of the latest block by some amount and then we would generate between there I see yes so the first part I believe is already the case if you leave the block number out it will autogenerate or default to latest plus one or sorry previous plus one where previous for the first block in your list is latest if you don't specify um a block tag uh for the other one like I said um I don't care either way if we

allow people to have blank spots in the or not so yeah my main question would be when we move to the next block it appears so that there are some fields that we do not copy from parent yet yes uh yes specify those so any field that we can calculate based on as a function of the parent then we would do so so um Bas fee is an example of this the Bas fee is a function of parent blocks base fee and parent blocks fullness and so for those ones we will we can the default if you don't include a base fee override is we will just calculate it according to consensus rules so we follow all the normal main

net consensus rules um for the ones that are don't have a way to derive it from the parent or derive otherwise derive it um I'm fine with just following what we previously did oh I think I see what you're saying you're saying should we copy from the base block or copy from the previous block what is the current behavior like if you just includ okay the parent do always copy from the parent in NE mind when when we're just doing a copy feels slightly more correct to me but is there an argument

for sourcing from the base block instead I would generate empty blocks I think it would be more clear in this situation what do you mean blocks I think we're talking about if you if you use all defaults for a block so you have some block and it's just empty object in the API right so you say fill in everything for me if the current block number is 10 and I want to corrent the block number 100 then we need to generate the blocks between there I would generate empty blocks there yes so if we go with o suggestion of allowing I think we're talking about two different things here so there's two two topics we're discussing one is um

what are the default values for all of the fields and two is should we require the user to explicitly specify every single block or do we allow them to have gaps and we backfill those gaps ol suggestion was to back fill the gaps um let's let's settle on that one first um is anyone against uh back filling the gaps so if you say you know build on top of latest and the first block in your array is latest block number plus five do we just generate four empty blocks followed by block or do we give you an error I'm mly again but not not a

strong what you would you see like that would error on that case uh yeah just say number I think the block specifying block numbers becomes really useless if they always have to exactly match because the block the blockchain can move kind of forward at any time yeah sure yes that that I agree then I feel we could even remove the block number override all together and you just over build on top yes we

could I mean you can specify the starting point where you're building but you couldn't specify anything else correct we we leave it in there we could leave it in there for completeness just in so the user gets some validation that their thing they're building uh is correct maybe but you know that's questionable value well they're still returned so the user can get them as returned and they can see what were the block numbers they were built up yeah yeah true okay so sounds like o wants if I understand correctly o wants um to pretend blocks 8 through 12 in my little example in chat there exist and just

fill them in with all defaults and Cena has a very light preference to um require the user pass block 8 through 12 even if they're just empty objects and it sounds like clari you were slightly ciding with um allow missing and back fill but maybe change your mind well I think if you want to simplify the thing then I would remove the blog number overd all together and just just allow the setting where the simulation start over over so they can set latest or some other number but then all the blocks are built on top of that I think that was that would be the simplest solution I don't have strong opinions

any strong opinions Lucas nope anyone want to concede to move things forward or should we with some other mechanism of deciding like tossing coins yeah I mean I think ol was having a stronger feeling on this so I'm happy to do the back field okay let's go with that for now if it turns out that during implementation it's complicated or hard something we can reevaluate but let's just move forward um so we will if the using that example I have in chat if user passes block number seven um or sorry they say

latest block number is seven and the user the first block in the array they pass to the RPC is block number 13 then we back through backfill blocks 8 through 12 using all default values as though the user passed you know five empty objects in that array um prior to the block number 13 and we'll also still validate as well prior to that that the block number the user is providing is you know not 256 not more than whatever the uh client side limits are so um before you bother to back fill make sure you check to see this user isn't trying to back fill 10 million blocks to dos the the client um okay and then moving on

to yeah and then we come to the result when the user gets his result what does he see he sees only the ones he submitted or he sees every piece of EMP trash we've just generated I would say all the trash um for two reasons one it makes it clear to the user that what they did is actually generating blocks um so it gives a little feedback to them and two um I think I suspect this will be easier clent client implementation wise so you guys don't have to track um which of the blocks were actually provided versus which ones are um backfield that is Al something that I don't really like since you provide two

blocks and then you get 100 blocks back which is sounds quite confusing and I would expect to get two blocks back when I'm specifying two blocks I mean would if you got if you specified two blocks you got back 100 would this perhaps encourage you as a developer to stop submitting blocks with 100 100 unit gaps and just submit two blocks instead like if you only want two blocks back just submit two Block it's probably would would make me make a Google search for this and then find some mic and rep post about like

why why this method is returning 100 blocks instead of two blocks I sounds like it it's working working as intended then but yeah I feel if we doing the black filling that then we should return them but I can see that the users can be conf but I feel a little more strongly about this than the previous topic I do I do feel like that if we're going to put work on the client to generate these things um we should be letting the user know via some mechanism some some way of giving feedback to the user hey the client's doing a bunch of work here you know if you want your client to work less stop doing this and if we just sign ly do it I worry people might think that

we're doing sort of phantom block thing or virtual block thing and not actually generating them and by giving them that feedback it hopefully will encourage them to be a little nicer to their nodes and their own computer hardware if they running their own it also lowers their bandwidth cost because I mean the user has to pay half the bandwidth cost right for any RPC response and so if the user is constantly making requests for 256 items we're giving them 256 full blocks it this encourages them to hey you know if you want want to lower your bandwith cost just simulate two blocks instead of 256 blocks I feel if Unis will adapt this and start using this and then they implement it in that way that they always seting 100 blocks then the all the RPC providers they will start

optimizing the clients with with the Phantom blocks so that they don't actually generate them let's work for the cor devs right I think they would complain to core like why why this is so inefficient go talk to you SW and tell them to stop making crappy software is anyone so so I feel reasonably strongly about returning all the blocks does anyone feel um strongly opposed to that or is everybody kind of weakly opposed like like I'm only to keep fighting on this but if no one else wants to fight me then I'll just take the win I also think we should return all the

block okay let's let's let's return all the blocks then if if if someone feels strongly about it and they just don't want to fight me right now feel free to bring this back up in telegram or Discord and we can discuss more but I do want to make sure we're moving forward and we're not getting stuck on little things that people don't have strong opinions on like the last one or this one okay and then I think last thing in the last couple minutes um defaults so it sounds like maybe do we have all the default behaviors logged so if a user doesn't provide a given value um it sounds like nethermind maybe

is always using the previous block whereas uh gu might be using some from the previous block some for from the base block we should definitely make sure we are on the same page on that I pulled up um our default Behavior we are taking the coinbase difficulty and gas limit from the base block is there any reason why we shouldn't just take those from the previous BL in case they were overridden I think I did it this way for because of time Stone plugs m okay so without Phantom blocks we can just switch to always default

apparent well because um if every block is inhering from the base then these fields cannot can well we can't override them in the current API we can we actually can override them so I don't know I don't know what's the right solution here I think all of these three Fields can be [Music] overridden so my vote's just to take from the parent from default then are you okay with that yeah that's fine okay it sounds like that's what nether mind's already doing so let's let's do that so now that the Phantom blocks are gone all the

defaults are either computed like Bas fee via normal consensus rules or if there's no way to compute them then we just copy the parent where the parent may have overridden it may not have been but we just whatever was in the parent block we just copy that I wonder if there is any specific test case that can prove that there were no Phantom blocks and all the blocks are real besides Fe getting lower in between blocks like is there any externally visible difference real um no assuming that defaults copy from the

most recent non- Phantom Block in the chain which sounds like not what gu was doing previously but I mean something we could put have changed uh there's so there's the base fee there's also isn't there the new blob base fee so two base fees I guess that are both functions of the parent um the hash so all these blocks would have actual hashes like legitimate real hashes of of the block header that's probably the most noticeable difference so basically the cheapest operation would be and otherwise the cost would be just to compute the empty block hash and stick other fields with data and that's

basically yeah so you could um yeah so just see what the block hash of each return block is and um that'll tell you if it's being actually filled out with defaults it also tell us if all our defaults are the same or not like you can like basically any test can just compare the hash first and only continue to look at other things if the hashes mismatch in theory sorry Kari you lost all your battles today okay anything else sounds like FL had to go anything else yeah let's continue

s okay sounds good I am sorry that not everybody got what they want today but I'm glad that we are making good progress I think it's important at this point that we don't get too stuck on little thing disagreements here and there okay thanks guys yep see you guys next week or in chat byebye by