All Core Devs - Testing #83 (CL Breakout)

Transcript

Thank you G. >> I think we have Yeah, I think we have get proposer head and uh quick versus amplex builder API and so on. >> Jun, would you like to give an overview of the changes to get proposer head? >> Yeah, sure. Um I want to share and discuss get proposer head changes introduced in this PR. Um it's a 5348. It has three prongs. One is changing get proposer as signature in line with get head and prepare execution payload. It receives and returns fork choice node

instead of root. It also mentions to optionally use get proposer head when building a payload in golas which was under specified >> growth uh charge cost in a way. Um also this is a major rewrite. I opened an EIP >> on what the head extends. This ignores a test made in the parent slots because a testers can only vote for pending for a timely block. With this change get proposer head decides which block to extend and should build on full decides it payload status.

Uh you can find more discussion regarding this issue in this link. Last but not least, it removes each shuffling stable since flu as the proposer look ahead allows us to deprecate it. Michael said Lighthouse will be okay with removing it, but I'd like to ask what other client teams think about this. Do client teams have opinions on this?

>> I think I would ask perhaps uh I mean reorgs across the fork boundary it's not really about the shuffling. It wasn't really much about like finding the proposer or not. It's just that in general handling reorgs across the epoch boundary seems to be a stress on nodes and that's why we didn't want to include them. >> Yes, but it seems lighthouse is okay now with it and Michael wanted to ask you about like if prism is okay with it. Actually, >> I think we should handle them. Uh fine.

I'm not really sure if it's worth to add those reorgs anyways. This thing is still optional. So I don't really mind much about these changes. I've already implemented in a different way. We don't have is proposer head in the same way and we're not going to be handling it in the way that the spec is changing. So this this PR will not affect Prism at all. >> Okay. It's good to hear. And then what about other clients? And just to be clear, I don't have any strong opinion on re removing each shuffling stable.

Um, I don't mind if we decide to reserve it, but if you were to keep it, I would propose to rename it to something like it is epoch boundary or something because it's not about shuffling anymore. So, so now just just a comment on not on this specific u change that we haven't uh focused but um for sure we had a discussion internally about the implication of that. we are um

following the spec in terms of functions. So uh removing that one we will then start uh change we we will we will impact uh the the way tech is handling the the reorg in at least in in reorganizing and re and refactoring our code on the specific um shuffling and epoch boundary thing. uh don't have a clear uh vision at the moment if we would have been if we were if we are affected that

by by by that or or not. Um yeah, we should do a drill down on that. But we were in favor because I remember I think the discussion that it will be uh a cleanup on the spec anyway and and in tech at the end even if the code would need to be changed and and and and um refactored to to clean up.

>> Got it. Thank you. Um, Nico, did you want to >> What I want to know is just I'm not sure it's in the interest of the proposal to do this kind of reorg because if the block is already like if they publish the block at like 3 seconds or really late already and then uh they reorg shouldn't do this if it's late. >> No, that's not changing. We we only reorg if we are early. That's part of the >> Yeah, but even if you're early, if you do a epoch boundary rig, it depends how clients premputee the epoch transition and uh if you see the block, let's say 2 seconds, you might still not set it as head by the at the station deadline due

to whatever reason if the epoch processing is slow. So that would be my only concern if the proposals even interest or it's not in the interest of the proposal probably to do this. But depends how clients uh premputee epoch processing and transitions. But generally I think it's maybe fine like Michael said on the comment >> is loops are going to be fine if we were to remove this.

>> Oh but it's it's not really about us being fine, right? Like it's in the interest of the proposal to get >> Yeah. So his head not not reorging if even if you remove this function and we are fine if you're removing we are still going to be applying it we we aren't touching at all our code to reorg all blocks we are not using even the non paths for sending FCU and I think what Nick is saying is absolutely reasonable this is one of the reasons why we don't want to reord these blocks >> got it seems like to me we don't have a rough consensus on removing this

function even though clients have uh freedom to implement it because this is optional. So I would go for I am leaning toward uh not removing it shuffling table but I would I would going to propose renaming it to like apoch boundary or something. Uh how does it sound like? Yeah, >> I think that's the right call. We should just proceed with that. >> Okay, thank you everyone. >> Uh should we discuss quick or quick or just uh or go over 8282?

I mean I would prefer to go over 8282 but okay let me share my screen. Can you guys see this? I'm going to assume that you can see it. >> Yes. >> Okay. All right. Uh, one of the open questions is what the per payload limit should be. Right now, it's set to 16. That matches what the limit is for validator deposits. Is that sound okay?

>> Sounds a bit lower to me. Yes. The problem of turning and the problem of putting a limit is that it's very cheap for whomever is the first builder to never include other builders uh deposits. >> Okay. >> So what does that mean? that I think we really want to have. This is the problem with this general approach. We you're making an inherent tradeoff. If for Titan is cheap to put a,000 ETH and prevent any other competition for a few epochs, they'll do it.

So, so I think we still need to be able to process at least a thousand deposits. >> Okay. So, are you suggesting that we set the limit to,024? I don't really know how much is what clients can do without any sort of optimization but yeah whatever we can do without optimization that should be done. >> Personally I was thinking like 256 >> this doesn't have the problem of the of invalidating on the loop. So since this can actually now be checked on batches and whomever like puts an invalid one uh immediately gets caught up. I think it should be fine to be able to handle thousands of signatures there.

>> What do what do others think? >> But isn't that really expensive, right? Like spamming this on the E like filling up the 64 or 16 or whatever we have because you have the exponential fee increase or even Titan cannot fill this really for long. I Oh, so you mean the the exponential failing on the um on the contract itself? >> Yeah, exactly. >> And this just happened on Hleski. Oh no, it was on Hoodie uh as well where someone I think Yoro trained his whole hoodie balance because of consolidations. It's the same mechanism, right? You cannot doss the skew for long.

>> Yeah. >> Yeah, I agree. So with that in mind, >> yeah, it doesn't really matter like we could just keep the 16. >> I I don't think so. It's still cheap because it even if it's costly the it makes it cost for your for for for your competition as well. And it's a cost that you recover anyways because you're depositing and well you you only waste on gas.

But that's the thing. If you keep depositing 16 every block, the gas is going to just keep going up like crazy. >> Yeah. And it's just until it's not profitable for you. So we've seen that all of the transactions at the fork uh in the last uh fork we had troubles with cow swap when prison went offline and that was the whole reason of like trying to onboard builders at the fork that it causes a problem with defi anyways let's I would propose that we have a larger number here it's very cheap uh it's an addition there's no longer an attack in sending invalid signatures anymore. So, it just doesn't

make any sense. >> Would you be okay with 128 or 256? >> I suppose it's fine. >> Which one would you prefer? >> I I think the higher is the better just in case builders are nasty. I don't expect them to be nasty, but who knows? Why would you give them a chance? Okay, I can think about this more, but I have no issues with raising it to something reasonable. I I think clients can easily handle 256 signature verifications per slot.

So, let's discuss that more uh later. Okay, so going over the PR some more. Uh we add a new builder, sorry, domain builder deposit because uh you don't want to be able to replay a deposit on the validator uh deposit contract. Uh I don't know if I need to go into detail on that. Um okay, great. Uh technically the builder withdrawal prefix is only used at the fork when onboarding. Um, I feel like we're going to deprecate this afterwards and then we could allow a new validator type in the future to

use CRX03. >> why why don't we why do we go with a hack instead of like doing the right thing which is just to if we want to on board builders at the at the fork why don't we just have the contract emitting logs before as we did with the mer with the with genesis >> uh I just don't know how that works if that is a solution we could go with that >> I mean it feels like what we are arguing that we need to we need the CIP because it removes a hack but then it adds and it keeps a hack.

>> The thing is that we've somewhat confirmed that the caching before the fork for onboarding builders is somewhat manageable. >> Isn't this the exact same caching that you need for the general one? >> I think the main problem is that there is no system call before the fork. So you don't have the UNQ uh logic running through and you have no lock emitted in that that way. The locks are only emitted by the system call that calls in at every block and dquse these two items then emit emits logs for them. We don't have we're going to have to like use the same logic that we did preenesis which was

having the CL listening to the EL and that's probably more complicated. But then we have the unbound problem again that we have an unbound amount of deposits coming through. >> Yeah, that's that I don't think is a problem though. >> But yeah, listening to logs would be a bit a bigger change on CL. I would propose we just keep the same onboarding logic we have now and temporarily deal with optimizations and then delete that as soon as the fork is For the other problem that po or the solution pus mentioned, you also would

have to know the deposit epoch um to make this work right because that needs to be finalized for the builder to be active and I don't think the C the E contract would be even aware of the deposit epoch. >> It would not you would have to treat all deposit requests at the fork as finalized or whatever. >> Yeah. So Mario wrote this in the other chat before that it would work like the withdrawals and consolidation so they just stay cute until the fork happens on the builder contract.

At this stage, it sounds to me that we we just like failed for this thing that and design a lot of things for builders to be able to be active at the fork when we can probably just like remove this completely accept that builders should deposit after the fork and just self build for a while. >> I mean, I'm okay with this. I thought you were the one that was pushing for on boarded builders. No, this came from like like this came from mostly rig and the builders themselves. >> I mean this is two epochs, right, that we're talking about.

>> Assuming the fork goes smoothly. Yeah. >> Yeah. Yeah. Best case scenario, two epochs. Can we handle uh deposits if we are not finalizing >> builder? You mean like >> no >> yeah we can or >> no the deposits needs to be finalized for them to be active. >> We can handle them. It just wouldn't be applied is my understanding. [sighs and gasps] >> Yeah. So that could potentially cause some issues in case for whatever reason local block building would be messy and we would be relying fully on builders.

>> We should we shouldn't stop finalizing even if local block building doesn't work at all. That's the beauty of EPBS. >> Okay. Um let's discuss the onboarding stuff later. I feel like that's a bit tangental, but I agree that we need to discuss it. In 8282, there are two new containers, uh, builder deposit request and builder exit request. These, I mean, are self-explanatory, but they look very similar to, uh, like a deposit request and to a withdrawal request, I think, for the [clears throat] source address or I forget. But

moving on, we just add these two new containers or fields to execution requests. We add the two for operations handlers and apply parent execution payload. We extend get execution request list to handle the two new fields. Voluntary exits is no longer modified. >> Wait, wait, wait. You're going faster than what I can actually read. I'm sorry. Can you go back just a little bit before? Uh, yeah. So, we add this two. >> Right.

I'll scroll down some. >> Just a quick question. Why do we have to do this uh 0x03 if we have a new system contract? >> Could we just >> No. Yeah. But like why why do we reserve the 0x03? We could just do 0x0 again. No. For >> no. Then we're going to just change to builders every validator that that is a bit less valid validator now. >> Oh no no no.

>> No no no. You have >> because they are already validators. >> Yeah. I mean we don't have to use 0x03. We could do like 0x FF. Like it really doesn't matter. It's if it's temporary. Like I would keep the 0x01 23 whatever for the validators and then move this into a >> I really vote for removing completely the cache and everything if that's what we're going with this and just not on board them at the fork.

>> I mean I'm okay with that as well but it's tangental. What do other clients think? >> I think it's worth getting outside uh uh I don't know consulting like the application layer people because I know like doesn't cow swap rely on builders. >> Yeah. Function. >> Yeah. This this this breaks cow swap for like a couple books is >> I think it's three ebooks.

That's 20 minutes. That's significant. >> Yeah, I'm not sure. I think that we should discuss that. And I I would personally prefer to have onboarded builders. I I don't know. I feel that the optimizations are just so temporary, we'll do whatever clients are comfortable with and the community, of course. I I think that's the wrong way of looking at it. I think we need to figure out what we want and then we need to make the clients comfortable with that.

>> That's fair. >> Okay. Can we talk about the onboarding stuff later? >> Yeah, sure. >> All right. Pus, are you happy with me scrolling some more? All right. uh voluntary exits. The function is no longer modified because builders would exit via um the builder exit request. Uh there is a new function called is valid builder deposit signature. This is a copy paste of is deposit signature valid or whatever but with a different domain.

probably that one you want to have then a different helper that takes the domain as a as a parameter. >> I thought I thought about it but then I'd have to modify all the other instances of is valid deposit signature. >> Oh yeah, the diff is going to be worse. Yeah. >> Yeah, you could do whatever you want clientwise, but this was simpler. Uh yeah. Uh this doesn't really matter but I split up withdrawal credentials into version and execution address on this uh alert function.

stiff is so ugly. The apply deposit for builder is gone. There's a new process builder deposit request function which just uh I don't want to say handles the deposit request. If it's valid, it adds the if the pub key doesn't exist in the registry and it's a valid deposit, we add the builder to the registry. Otherwise, we just increase its balance. It's very similar to what the apply builder deposit was before.

Sorry. Uh in the previous function about the ver uh sanitary verication, you're reusing the deposit message container. >> I am indeed. Yeah. Uh I think in the previous version you define a new deposit message container just for uh the builder deposit signature. Why do you uh revert this change? >> I reverted it because I didn't want to uh change the logic for signing deposits.

So previously I wanted to split up withdrawal credentials into version and execution address but uh I feel like that would complicate changes to tooling. So we should just continue to use withdrawal credentials and because I reverted that change it was no longer necessary to introduce a new deposit uh sorry builder deposit message container. Okay, it's just for uh signing comments on process builder deposit request.

Does this generally like okay or waiting for some feedback? I mean the only question is why are we splitting up the version and the execution address there? I guess doesn't really matter, right? >> It was simpler than assigning them to variables. It was just a style. I think >> do we really want to have the the builder

uh the top apps for existing builders not verify the signature? This kind of like makes sense for staking pools, but I don't think this is a feature that builders will use and it risks losing money if an index is reused. It risks losing money if what >> if an index is reused. Let's say that for whatever reason you you you delayed your >> oh >> your your your your your top up your builder actually gets exited for whatever reason and then you sent a top up at the same time uh I mean with an invalid signature

whatever it is at the same time that someone else is sending a first deposit. Yeah. I don't know. I I don't I don't really see the reason why not to validate the signature for topups on builders. >> I think it's so that you don't have to top up with the a signing key. >> You could just send a a top up from any address. >> Yes. Uh is it a feature? Yeah, probably they will use it. I don't know.

>> It just makes it really easy to top up. You could do it from any address if >> No, I understand. It's just that >> Yeah, it worries me. >> But yeah, I agree. >> No, no, to send from any address is fine. You can always do this. >> Uh, right. >> I'm sorry. With the builder private key. >> Exactly. So, the thing is to keep the private key for the builder uh offchain. >> Yep. >> Yeah. But I I do agree that since now builder index can be reused, that's definitely a thing to >> to address.

>> I'm okay with changing this. >> How so? We're still requesting that if a builder makes a trustless payment and then this payment is still leaves uh a minimum amount or there they were still allowed to like go up to zero now >> I'm sorry what's the question >> so >> the minimum deposit >> no no the the the trustless payment when we enforce on the bid we enforce that they are left with uh with how much after >> 1/8 >> to cover so We still enforce one E.

>> probably this is safe. >> It It makes me uneasy, but but I don't see how to attack it anyway. So, I'm okay with anything here or like I both make sense to me. I agree with Sen Rico and Potus that because builder indices are re reusable like you could accidentally send a top up to something that's not your validator or your builder. But uh wouldn't you lose the deposit either way?

>> Unless you could like refund how would you know that you you should refund that money in that case? Seems like you'd lose the money either way. >> Yeah. So the the the only way would be to like actually have it on the E. But uh but people don't want to have this verification on the app. But how would it get the wrong builder pup key at wouldn't it just create a new like if you send a deposit with your pup key and the builder index got reused wouldn't it just add a new >> Yeah. Yeah. So so that's why I don't I don't I don't see how how how to attack it now. But but it makes me uneasy.

>> Oh, I see. You're actually right, Nico. It wouldn't uh add to a builder with the same index. It would add to a new builder with the same pup key as before. >> I mean, right now, someone can use your pup key and deposit to your builder without providing a valid signature. But this seems more like a donation, right, than an attack. Okay. I mean, I think this is fine. Can I move on to the next section? Oh my god. Uh, let me change the view of this.

Somehow I can't. It's right here. Oh my god, that's not even better. One second. This is line 15. Oh, sorry. 1696. Let's process. All right. So, exit.

Uh it's fairly simple. Um I don't know how much I need to explain this. I mean if the builder is active proceed if the builder's sorry if the request source address like the address that submitted builder execution exit matches the execution address of the builder proceed. If the builder doesn't have anything like to withdraw like pending payments or uh whatever the other stuff is proceed.

>> I believe these are the only uh necessary exit conditions. You're still keeping the certified day exit, right? >> Say that again. Certified exit. >> The 35day exit for the uh builders. >> Oh, yeah. That is still there. >> 35 or whatever the number is. It's a really long one. So I think we also keep the door open to

add partial withdrawals if we wanted that later, right? >> Uh theoretically, yeah. >> So I think at least in the contract it's a withdrawal and the amount is zero if I'm not wrong. Maybe Cayman can respond. >> No, I don't think there's an amount. just source and pup key. We could add a new execution request for withdrawals if we really wanted to later.

I think the contract is going to be easier to audit and everything if we just like keep the no amount in the message for the deposit. So that the deposit actually is a different thing. You don't send an amount. You just send what is the address and sign. So what this is uh so I didn't look that much at the contracts but uh this is a copy of the withdrawals contract. So if you set the amount of zero then it's an exit otherwise it's a >> but it's still cheaper and it's less less surface for for error if you just don't even have the parameter >> I mean

sorry >> if we never want partial builder with rods then I guess it's also fine And we could probably also reduce now the exit period. I'm not sure if we that's >> No, no, no. That's they are just to prevent the attack of like filling the queue. >> Yeah, but filling the queue is now really expensive to do this. Well, you guys were were arguing that we should do something because of a 50,000 ETH attack that was irreoverable. Now, this is something that will not cost you 50,000 ETH.

>> I'm really sure if you try to do this with EIP1559 fee increase, it will wipe your wallet pretty fast. >> Um, one thing to add to the partial withdrawals. I think we shouldn't do this because then you can flute the withdrawal queue with uh partial with builder withdrawals that are basically free and they always come first. So they basically push out the normal builder sweep withdrawals and requested builder withdrawals and it also doesn't make much sense to have partial withdrawals if you have builder reindex index reuse. So just exit the the builder. It doesn't hurt us.

Okay. Uh were there any issues with the exit handler? Did that sound sufficient? The three conditions Sorry, this function >> this seems fine to me. >> Um, how does this mechanism interact with um uh the builder exit caused by balance less than one ETH?

>> You cannot have a builder balance with less than one ETH. It's impossible. Isn't there like a mechanism right now that if the balance drops below 1/8 uh >> it cannot drop below if we enforce on the bid that it cannot drop below. >> Yes, that's correct. >> You can't do partial withdrawals. So the the bit is the only way that you can subtract balance. Okay. Uh that was the last change in beacon chain specs.

In builder specs, there's just some small cleanups regarding uh I forget. Oh. Uh, deposits won't be made to the deposit contract anymore. They'll be made to the deposit request contract or sorry, the builder deposit request contract. It's pretty similar. And there's still a note here about onboarding, but if we decide not to do this, we can remove that. How does this sound?

Okay, move on. That was the only change to builder.md and fork. Uh, it's just changing it to not use this function which was deleted. So we check to see if the deposit signature was valid the old validator deposit way. Not the is valid builder deposit >> I'm sorry. I'm sorry. Could you go go back? I was talking trying to tell something's terms.

>> Oh yeah, this part. >> No, no. No. In the current file. Uh here. Uh what is this? This is on on board builders from Bend. Okay. So this is the fork. Yeah. I think the only change here is that uh you have to apply you have to like check the builder deposit signature uh the way that you would check a validator deposit signature with the old like existing domain and not the new one.

But I mean that's the only difference. Happy to talk more about this if there are questions. Uh, one thing to note that I mean it it behaves the same as it did before, but if there is an invalid deposit signature, it does not add it to the pending deposit queue. But that's how it worked before.

So the else statement here is because there could be multiple deposits for the same builder, right? >> Correct. Yeah, we need to be able to handle topups in the onboarding as well. Annoying, but yeah. Um, one thing that just came in my mind, uh, wouldn't it be easier to just split the pending deposits Q on the consensus layer side to have a pending builder deposits Q2? So, basically just split them up. Um, if they have 0x03 credentials just Oh, no, that doesn't work. Top ups. Yeah. Okay, forget it.

>> Oh, I'm in the wrong fork. But we did explore that option and it was fairly complicated. There's a PR by Myle. Uh where is it? There's like >> also didn't that suffer the same problem that you cannot have builders right away at the fork? >> Yeah, but you can process them with like 16 builders per slot then. But yeah, it still doesn't work with topups. So, uh yeah, forget it. And >> sorry, I closed the PR.

Okay. Any other questions or comments on this section? >> Yeah, it's kind of weird that the logic of around the invalid signature is different for the fork than for the regular processing. Like I could have my tooling saying I'm going to send a deposit uh and then any subsequent deposit is going to come with a zero signature. Uh but that won't work prefork. In principle, we could just check the first signature. >> I mean, I believe this does work the same uh as like it would sorry, I believe the onboarding would work the same as it does via deposit builder deposit request. I mean, if you make a deposit

for a new builder which does not exist in the reg. >> Oh, so so you kept that. So, let's let's see. So, you spend Oh, this is just the diff. I need to look at the I need to look at the function. >> Ah, That's how I review things as well. Maybe this will help. So, we have >> I have I have the page open here. So, it's probably that. Yeah. So, that's that's my mistake. My mistake. >> Yeah. My mistake.

>> Oh, good. I I don't want to, but I mean this logic could exist in another function. It would behave exactly like this, but uh I didn't think that it was warranted because it's not reused anywhere else. >> Okay, I'm going to move on. I think >> yeah one last point on that is just to just to point out we still need to do this in is pending validator check which is kind of annoying but otherwise a builder can frontr run existing pending deposits right or validators like from pools.

>> Uh >> yeah that's the whole point of like trying to avoid on boarding to prevent that check. So that that check requires requires a cash. >> It does. Uh another question actually I I was planning on doing this afterwards but um I would like to set the builder version to zero when onboarding and not to 0x3. I can do that later in a different PR if we decide to go this route. But would that make sense to you all?

That way if we add another builder type in the future, such as a proof builder, it could be 0x01. >> Sounds good to me. >> Okay, I'll do that in a separate PR. >> Shouldn't we use maybe something else like 0x F0 or something? I mean technically they're separate registries and >> I know >> they can reuse versions. >> Yeah, I know. I know. It's just that we might be like overloading the concept and that's just a bit bad UX in my opinion.

>> Yeah, how about we discuss that more? I was actually planning on planning on using a UN 8 to match the version type in builder but uh yeah, we can do it however we want. I just think the important part is that the version starts at zero instead of three. Anyway, uh in validator we just have to update this function get execution requests which uh pretty sure just does the conversion from bytes to uh it's just a serialization function.

It's kind of long, but yeah, this is the important bit. I have a question for clients. Is do do clients have a a map from pup keys to to indices somehow? I don't think we do. I think we have two because if if you only have one then that's that might be broken now.

>> Right. Terren says that we have we have a different one. So that's were not affected. But if you have only one and then you rely on having a single pub key that that's going to be broken. >> That is true. Uh one notable thing about this PR is that you could have a builder with the same pub key as a validator. >> Yeah. I thought that this would cause havoc on clients, but at least on Prism it doesn't do anything.

Uh, and just to talk a bit more on that, it was a property, sorry, the having different pup keys for each was a property I liked, but it wasn't necessary. So, I'm I'm definitely not fighting on that anymore. It doesn't seem to be an issue at all. All right, moving on. I'll try to go a little bit faster. Uh because we added a new domain, we had to bump the domain and hes for inclusion list. Uh this is no longer an unexpected request type. I just made it the biggest 256 value for 255.

And the rest is just testing. We uh moved all of the uh deposit testing to a new file specifically for builder exit request. And that's 200 lines. We removed all of the the old stuff and stuff that's no longer possible uh from this process deposit request Parent execution payload. I mean, it's just testing. I don't know how much you guys care about that.

Are there any questions about the specs? I think the biggest question is the uh on boarding before. It' be nice to remove that that complication, remove that attack and then and I agree that we we might need to do something about it. Uh perhaps we

can cook up something some way of on boarding them without uh without keeping this change on the CL side. I am unsure. Um, could one of you like ask the community or whatever like figure out if it's necessary to onboard builders like truly necessary and look into alternatives for onboarding?

>> I think uh protocol support could help with this to [sighs] reach out. I I mean we've already done this. This this was something that we've already asked and this was a request from them and Julian was the one that was uh strongly in favor of this. Uh I think all of Rig wanted this and of course builders wanted this. I mean, personally, I'd feel much better about leaving the onboarding just so it's not like really a question or so it's not a concern we have. I I I really don't think that it's going to be attacked.

>> This is this is not something that you can I Yeah, I I don't think this is this will be attacked. This is this won't be attacked at all as it was in the other case as all as well. But if the argument is to remove these kind of codes from clients, uh well, we should do it. We should do the whole thing now. Now we have a we have a we have a way of doing this. Um we got a green light from ACD that they are happy to delay the for so we should do the right thing. >> I'm not sure this is the right thing. It's just this is temporary.

>> No, you you can't you can't just duplicate. We we are going to have to keep this code. Uh >> can someone else weigh in? I Why would you have to keep the onboarding code? because we are going to continue doing the forks. I mean we we are barely be able now to remove phase zero from our clients like all of end to end it it creeps up in tooling. It crips up in caches it crips up in a lot of places until we manage to get genesis post glowas and start testing post glowas that's going to take some time. >> Are you trying for other chains?

>> Sorry. >> Yes. So I mean we need to keep this change this upgrade to gloss or whatever but we do not need to keep the optimizations to do the signature verification right >> sure >> because this is really just to handle the attack >> but then attaching that would scare me more than just keeping it knowing that it's not going to be executed. I I we need someone else's help on this.

I we can't make a decision on that today. I think >> no, we shouldn't probably we should not remove it completely, but perhaps we managed to find an way of on boarding them that doesn't involve keeping this this function which is attackable at the fork. Maybe a stupid question, but could we not activate just the uh builder system contract like three or four epochs before the fork and have them on boarded and then activate the fork or is that very very messy?

I'm thinking about this since you posted it, but then I don't think it's easy to do at all that you specs perspective is two specs. >> It's two forks. >> Yeah, two forks basically. >> And also it's dependent on it's going to be dependent on finalization. So it's No, I think that's even more complicated than just having this optimization. >> I have a really dumb suggestion. How about we have builder send uh like ETH to the burn address and then we hardcode their builder pub keys and stuff >> into the system contract.

>> Uh well hardcode it into the consensus layer. Yes. >> Yeah. But that's >> that's even worse, right? So that that requires requires like a consensus and community consensus on what's the list. I know. I'm saying it's a bad idea. >> No, no, no, no, no. >> Okay. Okay. >> Yeah. Okay. I don't have any solution that is doesn't involve like deploying the contract before that emits logs and somehow we keep the logs on the CL side and compute a hash and agree on the hash.

uh as as we did for Genesis. >> Okay. U any other questions on 8282 specifically? We're like 40 minutes over. I feel pretty bad about continuing this. >> Wait, isn't it just 10 minutes? Uh the call is only an hour instead of an hour and a half. >> Oh, >> the problem we have with onboarding builders at the fork is that the deposits are not finalized yet, right?

So what if we store the uh the block number where the deposit was actually made on the EVM side when the the deposit was encued on the EVM side inside the queue and use that as a finalization marker because the deposit transaction was made in the finalized range then and that could be already finalized at the for boundary. So we could directly start onboarding them. What if the first uh builder for actually I'm sorry what if the first builder doesn't include builder execution request or is that possible?

>> No no no those are going to be coming uh I mean the the statement is if we record where the when the deposit was actually included and if that thing was finalized then we're fine. >> But uh and and but aren't we already doing this. >> No, we are not storing the block number in the queue right now. We are not knowing when the deposit was made. We are just uncuing what is in the queue. >> And we could even remove this in the next fork, I guess.

>> Oh, no. You can't change the contract anymore once it's deployed. >> Would this work for the very first slot of gloss? >> Not for the very first because execution requests are always uh processed in the next for slot. But it would work for the second slot of laws. >> I think that's much much better than three bucks to be honest. >> But I don't understand. I mean I'm I'm not following uh PK. We are storing the slot number, the deposit slot number.

>> not on the EVM side. >> Not on the EVM side. That's fine. But what's the problem? I mean, >> yeah, I'm I'm not following what's what the suggestion is. The the deposit gets included in the in the CL side before the fork and we store that slot. >> No, it doesn't get included on the CL side before the flock before the fork. Yeah, it is in the pending queue. >> Not with the new contract. It can't be the pending queue. >> Oh, no. I'm talking about the deposit the the usual deposit flow that we are upgrading at the fork. So, you're suggesting something different.

>> I am talking about the new deposit the uh the new builder deposit flow. >> So, builders are depositing to that new deposit contract and it's queued in there. It's not leaving the uh execution side till the fork. at the fork we are starting uncuing them at a fixed rate of two two deposits per slot and then we are saying okay these deposits were uncued at that specific slot and then we are waiting for finality of that slot but I'm saying waiting for finality of that slot where the deposit is uncued is actually not necessary we can just enforce the deposit was cued in a slot that is uh finalized >> yeah so so we give the block number because we can't really give the slot

number at that time because we we're still going to be before the fork. >> Exactly. Yeah. >> But that requires deploying the contract earlier >> which we would do >> which we will do. Yeah. >> We can even store the slot number because we have the slot slot number in the EVM already. So we could store the >> but I don't understand. So how does the Y deal with this? I I have no clue how they deal with this request then. I mean this contract is going to be at the for it's going to be deployed before the fork. How do they know which request to send after the fork? >> It's cued inside the storage. It's in in the EVM storage and then there is a system call starting from the fork that uncues always two two items from that uh storage queue.

>> Oh, I see. >> So any deposit made before the fork just goes to the EVM storage and cues up there. Oh, that's why it it has to become very expensive, I guess, because that contract gets large and then data. >> Exactly. That's the exponential fee that's coming going on top. >> I think I like this solution. I mean, there would be one epoch where you'd have to self build. That's the only constraint. >> Two slots. >> I'm sorry. One >> one or two slots. I'm sorry. You're right. That's what I meant.

Uh question. Is it necess Sorry. Is it required or mandatory for builders to include uh like builder ex builder deposit requests in a block or could they just leave it empty if they wanted to? >> I mean not to for sale they they're not forced to do anything, right? >> So a builder could theoretically like not include deposits for other builders temporarily. The is static. There is a system call.

It's it's a must. Yeah, >> there is a system call at every uh slot that uncues the items that are in the queue. There's nothing that could prevent the blocked if it's >> Yeah, I don't think you can put anything uh Oh, I don't know. I I'm not m you cannot put anything on the execution request. We validate that the execution requests are the are the expected ones. >> Okay, perfect. Sorry, I was just misunderstood then. That's good. >> But how do you force builders to include it in the block >> for the fork or >> pay for the fork?

>> Well, that's usual transaction uh market. I guess you pay enough fee transaction will be included. But so theoretically, Titan could basically just say, "Yeah, we're not going to include any other builders uh deposits before the fork. So we going to make sure that at the fork we are the only ones alive." >> But is it that would say anywhere, right? Anyone that can censor will continue censoring. I I don't understand.

>> Yeah, you still have self safe self-built blocks that don't censor. shouldn't censor. Yeah. No. Okay. >> But won't there be a race to fill up the spots on the contract? Cuz if we are not dqing the queue uh in the builder contract, then once the queue is full, it will be really expensive, right? >> But it's still a better race than the race for on board, isn't it? >> Oh, no. Because we're going to an unbounded in an unbounded way. Yeah, exactly.

>> It's just to unbot them faster. Yeah, there's still there's still a race to get the first slots in the queue, I guess. but if you're going to be including 256 of them in the first slot already. Oh, but how how big is this queue going to get? Uh, if you're assuming thousands of builders trying to be online on the first slot, >> I don't think there'll be thousands of builders the first slot. It's going to be match 10. And I I I mean, if there's a thousand, then of course is a builder that is attacking the other builders.

>> I'm happy with this. I think this is the cleanest solution, at least for us. It doesn't include all of this on boarding thing. It doesn't add the 003. It doesn't seem to add any any logic, any extra logic to the to the to the L. They only need to record on the deposit the block number, the block height uh but it does give us a problem on the CL side.

I I don't I don't think we can do this in a clean manner on the CL spec because you're going to tide block height to valid. It's currently just black byes to us. They're blind byes. We don't we don't we don't need to >> PK PK are saying that the slot number is available >> slot number should how is it the slot number available >> last slot number available in the M was a recent fork that introduced the OP code for that >> no this is in this is in glow >> yeah that's a damn okay yeah sorry >> I mean we could use time stamp but uh >> we could put the slot what if you miss that slot

Well, it doesn't matter, right? So, the time stamp we know we we can match a time stamp to an epoch that was that was finalized. But again, it would and even in block we could manage block height as well. But the problem is that both of them would require us to to to to validate those not not really validate them but just even read them. I think at least time stamp we do need to read because we need to check that the time stamp is the expected time stamp. So time stamp would be better than block height.

>> Yeah, I agree on the block head on the time stamp thing that you can easily convert to a slot number. >> Yeah, we'll >> I don't like it as much. I much preferred it when it was just a slot. But >> quick question, could we not do a fork for the slot number only before glamsterdam so that we would have this [laughter] available?

>> But even if we had it, it doesn't really matter. I mean the logic on the CL side is the same for time stamp or slots. It doesn't matter. Yeah, I think we should just use time time stamp then. >> I think we should just keep the onboarding via the validator deposit Yeah, if you're fine with three epochs of nonbuilders, then that's probably fine, too.

>> No, no, that's so what Justin is saying is to keep the onboarding as we have now. >> That that would mean that builders have to deposit to the existing validator deposit queue uh deposit contract, right, before the for. >> Yeah. Yeah. >> Mhm. >> It feels like a weird UX, but yeah, should work. >> I mean, these builders are not users. They are professional users. So, telling them to, hey, you want to be ready at the fork, deposit here. Then you also want to be uh like use it after the fork, then deposit there, too. Like

that's not a not a huge ask, I think. It's not very nice but >> but PK just just from my understanding so this this contract is deployed before the this is how it works also for the previous contracts the contract itself is deployed before the fork but the system uh so the system call that cues them and and dqes them and sends them in the in the in the execution request only happens at the fork and this is the the for transition on the L.

>> Yep. Exactly. >> So then this is very simple. This is a very simple change what PK is suggesting. It doesn't seem complicated. Just add the time stamp on the deposit itself and then apply deposit for builder. Instead of using that slot, it uses the time stamp that comes from the deposit. You mean to include a a UN64 in the builder deposit request >> for the time stamp >> in the deposit, right? So the deposit request would come with a slot with something that is equivalent to a slot.

>> Yeah, I think it needs a seventh storage slot for that then because right now it fits into a six storage slot. But yeah, >> wouldn't we have to Doesn't this mean that we're hard coding number of slots per epoch and uh slot time and all these other things that we that could change in the future? >> No, because No, we only need one number. We need the glow as time stamp. The gloss for time stamp. We're just comparing against that. Oh, not even that. Because the thing is that we need the time stamp of the finalized epoch, right? So, so we only need to compare the time stamp that comes from the deposit to the time stamp of our finalized epoch.

>> Yep. Exactly. Which maps to the slot of the finalized epoch. So, we're not actually going to check this. H whatever. >> Yeah. And Dustin is as Dustin is pointing. Yeah. This is completely useless after the fork. The same thing as the optimization and the same thing as the whole onboarding thing is useless after the port. >> But anyways, this is going to delay even more the whole thing. I think we are all happy with the review today. It seems that it's an easy change >> and no one found any any attacks as at

least of today's reviews. >> So what we have now it seems to work. Um I also suspect as Dustin is saying that we should be fine if we just let builders be offline for 20 20 minutes. I don't I don't think Ethereum will die if we we don't we don't have any private order flow. >> I I'm saying exactly that. Yes. I I personally don't like I guess my my overall broad take on on this whole on this discussion is that this seems like a lot of effort, a lot of um let's call it a certain kind of um cleverness and

and um aimed at a goal that seems not really worthwhile overall given the costs that it involves. I mean people people have proposed just in the last 10 20 30 minutes whatever a number of of interesting designs for sure and design trade-offs. Um [clears throat] but but they're all ramping up complexity for for what or for whom exactly again? >> The users of Ethereum >> for for an epoch or whatever, >> right? But like >> one epoch >> it's

20 minutes. >> 21 minutes. Sure. Um, okay. I'm not convinced if if the demand is strong enough. Um, I'm not incredibly opposed to these things, but this strikes me as as as just kind of a one exactly an example the kind of tech debt that Ethereum takes on again and again and again for for no long-term gain. And this would be just be one more example of it.

You're not wrong. >> Yeah, I agree with Dustin. U I think if unless there's a strong push back, we should try to did not include this. And if there's a strong push back, then let's see the numbers. >> I mean, there's one concern, right, that sophistic so we don't want the unstake builder API, right? But in theory, it's a thing that's possible and can be implemented. So you act as like a local builder, but you use a payload from a builder. And I guess that would be one concern that you have whatever Coinbase and Titan do this or some bigger entity.

So they can still build at the fork boundary or right after it and uh and could establish the standard that we have like unstake builders doing payloads which we don't want. I think >> we're reaching an hour late. Can we can we agree on what we have now? this EIP without changes seems to work and then if we want to change it when we change it later.

>> Yep. The only change I think we agreed to is raising the uh per payload limit from 16 to a bigger number such as 256. >> Okay. Can we start then implementing this so that we have it for next week? Let's talk to the EL to so that they implement the thing. We have it for next week. But please do not merge this crap in the spec. What? >> Well, we need to actually review it. Like this doesn't really count as a review. Okay, we're more confident. But please don't merge it. But now we at least we agreed that we need to be implementing as is for next week.

>> Yes. Implement it. Come back with feedback. Only then we'll merge it and make a new release. >> All right. >> All right. Um, thank you everyone for joining and staying so late. I think there's like 13 of us now. Amazing. >> We should just make it two hours long. >> Heck yeah. I'll >> see you guys on Thursday. >> Yep. See you guys then. Bye.

>> Yeah. Bye. >> Bye. Bye. Bye.