All Core Devs - Testing #78 (BAL Breakout)

Transcript

Okay, hello, hello. We only have like two things to discuss today. The first one is the recent spec changes of moving from unsigned integers 16 to 64. This is because if we do 29 2780 plus moving to a 300 million gas limit, then we could face uh the situation where we actually have like more than 65k transactions per block. So, I think it should be fine. Um most clients agreed. Some clients didn't even need to change anything.

And for those that needed changes, I saw that some changed it already. I see there is a question, why not um 32? I think it doesn't matter too much if we go to 32 versus 64 because in RLP um 64 wouldn't pretty use larger objects. So, 64 might be just as fine as 32. And there was an argument by some people that 64 is faster to compute. Um yeah. So, is there a strong opinion against moving from 16 to 64?

Yeah, I had the same I had the same idea um as uh FLCL, but um yeah, I was also convinced it doesn't make matter in RLP and um we use in the gas code base, we use uint64 almost exclusively, so it's very nice for us. Lukasz, yeah? Uh wouldn't 32 make sense? It still saves a bit of memory, but maybe not.

In RLP, it shouldn't, right? Because in RLP encoding, it doesn't matter if it's 32 or 64. >> Yeah, but we need to keep it in memory for some time. I see. Yeah, but the don't we all use 64-bit CPUs anyway? Yeah, but you can use smaller variables, right? It's, you know, Yeah. memory in memory. I don't know.

>> Dragon is not um Dragon is also right here. Um as long as we can't hit the 32 limit, you could you could also go with um 64 in theory. So, we shouldn't run into any consensus issues there. But I I think it would be great if we all end up um using 64 there. Well, I'm not also not sure if we in the end can uh use any SIMD on this. Uh if yes, then smaller the uh the variable the better, right? Because you can process more. But I think it's not applicable here.

I see from the Yeah, go ahead, Dragon. point to to bigger value, but implementation can use smaller because it's not possible to have it. Yeah, I can see that, too. So, for the specs, it's also we haven't used um UIN16. So, UIN64 is basically commonly used, so it's also just cleaner to use the 64 there. Um I see from the base of site, there's also the okay to use 64. So, I think that's fine now. In the ERP, I will just keep it at 64, same for the specs for now.

Is there any any opinion against it. The only problem is Sorry, go ahead. Are we expecting more than 4 billion? I could just use 32. No, we shouldn't. At least not in near future. We can't can't see a scenario where we would hit either 32 or 64. The problem is that uh it it it someone will for sure try to use 32 bits for optimizations because you have

less less cache hits in CPU rate. Uh and at some point it may lead to NLP deserialization issues when someone can deserialize some weird stuff and someone cannot. Uh that's why I mentioned that types should be the same across clients and it's a bit inconvenient to have very long like integer that could not be used and you will always want to optimize it.

So that's it. Yeah, I'm fine with that, too. In that case um um I will change the AP in the specs again. Is there anyone against now moving to 32? This means every client would need to change because 32 wasn't implemented at any client. So, is there anyone against? Then please speak up. Yeah, I don't I just don't care enough.

Um I think 64 would be the right thing, but I I don't care enough. Yeah, same for me. I don't have a strong opinion on it. I would just go with the majority opinion here. Then let's do the 32. Is that fine? For people?

Uh just to just to qualify on on sign Yeah, exactly. I will then update the EIP and the specs and post a quick summary taking the club EL devs um in the Discord just to just to confirm that. Perfect. Okay. Yeah, we are already at time. Um Dragon brought up in the ball Discord that we should also discuss the ball item ordering. Um we won't have time today in the call, but in this case I would please invite

everyone who has an opinion on that to chime in in the ball Discord and we can further discuss it there. If that's okay. Perfect. Yeah, so we are at time. And we went through the whole agenda, which is great. Perfect. Then thanks everyone and have a good day. Thank you, Danny.