eth_multicall Meeting, Apr 22, 2024

Transcript

so I wonder do we have any page with the a that we want to throw if the user gives us like skipped or reordered blocks that we want to tell him about so is there something like specific that we uh that we want to throw at him or we just throw a generic as we want I feel like block numbers up wrong order yeah I think we should have a standardized erir code for it at least there for it oh there is okay and what do we do when the user sends to us a

range that is out of the limitation that we give him so imagine block number say 300 Z block number zero and the block number 300 what do we throw him then I guess we don't have specific error for that that case we had to create error for that there have something also I looked a bit into the way that we create hash so given that everything else would be safe same ases shall be

equal between G and that mind at least from my my understanding because we cast stuff that I was afraid of like in many places NE mind has in 604 for example and gu has un 256 and when we create hash we actually cast down to you in 266 to 64 so it shall be correct in that regards at least yeah I'm just looking at the error

question I guess I think we need to also adjust a bit the they have plock number in sequence not increase I don't think we need that kind of error anymore it just should be something about that the block numbers when it consistent or something like that and then there the block number is too high error could be other one and I also wondered karia maybe you can tell me if there are any like outstanding issues could you post them on trailer so that I would be able to manage them hopefully yeah I can take a look on that what one of the issue was that many of

the tests is at the moment wrong because they using those Phantom blocks and the Phantom blocks don't exist but then I don't have any client that is supporting non Phantom blocks mm and in general the main difference between sporting them and not supporting them is well sending to you the like the extra empty blocks and that's pretty much it here with the hashes course sorry I didn't get what you mean when we sent to you the like say you

sent to me create a block number five uh from the latest and fill it save with one transaction I send back to you four empty blocks with nothing in them uh with only hash basically uh and uh everything else copied From the Block before and then I sent to you one protest block and that's what is expected yeah is that what we decided last week that we're going to Phil probably should have written down our decisions no that that we we have feeling them yeah we we did decide

to yeah we we voted on that we are doing the filling I just didn't understand what what we what was your question about I think we agreed we voted last time on that if we doing filling or not and then the filling option one mhm so I I think we'll provide to you updated version of nether mind client later today so you'll be able to probably test it tomorrow all right yeah I guess can be there can be an error that the block numbers are also too small that you try to generate blocks that are already existing on the on the

Chain I so I guess the error needs to be block numbers are out of range so covers both of the cases could you come again uh if if the latest log is 100 and then you are say that the generate from latest and then you say that the next blog is 10 and then that 10 already exist in the current chain so it cannot be generated so we need error in that kind of case as well yes I assume that would fall just into just one category of Errors which is invalid block numbers or something and that can account for you gave us a block number that was out of order you

gave us a block number that was two before your head block you gave us a number that was uh um too far in the future like all those I would assume we could pack into one error code or do you think we should have a different error code for each yeah I'm not sure I think it could be grouped but then it would be nice that the client would then add their own information about it that they could be more specific about it but I guess the error code do need to be that specific yeah exactly so the the eror code just be like block number wrong or something and then the client would add messages to answer your question o yes I believe you describe as correct if the latest block that you're building if the block You're Building off of is is 100

and the user just passes in Block 105 then you will return an array of five blocks the first floor blocks will have no transactions in them but they'll still have all the Header information and then the fifth block would have all the Header information plus some transactions and for the transactions I would uh do an an empty array rather than missing yeah because they are valid blocks there's just no transactions and also the base fee and the Block Base fee also go down because there's no transactions yeah they just like yeah all right we'll do that do we want different error for that the block number is out of range because that is

more client specific config and it can some clients can support higher more more blocks to be generated than others so some clients could allow you generate thousand blocks do we want to have different error for that I have a question actually uh when we generate blocks that are nearly empty and are like inheriting from the parent I'm just wondering what happens to Guess

that that is inside of them so so the block say has a limit of the parent but we don't utilize anything in it when the block will be built the block limit stays the same because that's something is voted I would always take the parents limit or gas limit so also if the user overrides in one block then then stays overridden the next blocks and gas used will be zero mainly or

most but it will be zero if the if if they generate or there's no transactions here mhm did did you remove the Phantom flux logic already or is there something still need to work it's it's more it's not removal it's just adding stuff to check that uh we are given say block number five please add new blocks because in our implementation there is no real difference between absence and presence of phantom blocks so it's just adding like fill in extra blocks please now return results for every block that we've created in this request now but we have that special Logic on

how to the block has for example and I guess that's extra code that that will go away now the Phantom BL so good yeah but generally if you for example created blocks number one till 10 oh yeah yeah I get you yeah that logic can be now script was there something like special that required us to remove Phantom blocks just wondering if Phantom blocks can be a client specific feature um I think it's having a different per client I

worry is it's not the end of the world like if let's say ne mind sported Phantom BL well so there's a couple things one the behavior of what do you do when a block is missing in the user's input do you fill it with Phantoms or do you fill it with real blocks so that's one that would be a difference in output for the same input on two clients so both clients would return success and they give you different results and so that's not great um I think the other thing is um yeah I think that's really the main reason I would argue for keeping the clients the same in this regard yeah right as far as I could understand right this is a uh a lot of

specific that would have to be done here for a potentially very rare use case and on the already how to specify Json RPC method yeah I think o was just saying like could we just have this a client specific behavior so the spec would only support um filling in blocks like all of them but an individual client could go above and beyond and allow users to um leave have like gaps in their in their blocks and then instead of erroring the client to give a response and is worried that um

about that situation where so I guess I would be okay with that is I'm I generally like it when the clients agree it makes it nicer to develop and it makes it less likely that um app developers have to like end up getting tightly coupled to one client but as far as concrete things I think it's just that one issue of different behaviors when you're filling blocks that being said we could resolve that by saying uh if a user asks for blocks with a with a hole like sparse blocks we just return an error and then I would feel less bad about nether mind instead of returning an error you give something and it's just kind of undefined what you give the

dis other disadvantage there is if later on in you know simulate V2 or whatever we do want to add support phom blocks um it would be awkward if we respect it and it changed from what's nethermind or Aragon or some client did voluntarily so I still I still favor keeping things in sync I think it wouldn't be the end of the world though if NE mind went and did this but I think we should if we're going to go that route we should drop the back filling in the non- Phantom case I'm not really fan of adding that the client's Behavior more different because it's sometimes difficult when you're developing on something and and then suddenly you not notice that it doesn't work on some other client and it

would be nicer that it wouldn't work on the first case either so than you MH yeah all right we'll remove that yeah like we we do most of our development on nether mind and then we go back and test guess later and it would definitely be annoying if we did a bunch of work and then we found out later that oh guess it's different like in fact that's kind of why we test on another mind first is in the hopes that another mind will do be better at copying gu than gu is a copying another mind yeah yeah all right so Cena cannot make it today did we have something else that we didn't finish discussing last

time don't think so I think we made some decisions and at the end of the call I said if anyone wants to contest any of these decisions let's talk about it in Telegram and no one brought anything up this past week that I remember so I guess we're finalizing those decisions from last week officially um does anyone we should probably did anyone write down what those decisions were or do we have to go back and watch the recording honestly don't remember I have them up and I I didn't I made decision that I don't modify spe the spec until this meeting because I would expect it things might be changing that the people had realized that we need to do something differently because now people

have been developing those things okay um so we'll get this spe updated in this week with these decisions yeah seemed like no one had has had had disagreed with them now for for a week so I guess they will be finalized okay I didn't have anything else yeah perfect okay talk to you later bye thanks everybody bye bye