ePBS Breakout #20

Transcript

[Music] to start the streaming. Thank you. All right. So, welcome to the breakout number 20. I might not be completely in focus. Uh hopefully Terren can take over. Uh we have a few things to discuss. I called this meeting mostly

because after talking with some external teams, I mean not the usual round of people that I talked to, not core devs but affected teams like mostly people from Lido and Flashboards, even people from Monad. uh I realized that there's a bunch of things that uh kept people being either against TPBS or weary about it because they felt that they were going to be affected deeply. And it turns out that often times we can find like very large mitigations with small changes to the protocol. So I want to start with one that we had agreed a long time ago uh on this breakout to move into a system in which payments from the builder to the

proposer would be uh processed not immediately by balance transfer. We knew that we had to do this anyways because of security reasons. We don't want to have large effective balances transferring from one validator to another one. So we knew that we had to turn that payment and Franchesco's proposal that I'll get into detail later on the second point but Franchesco's proposal that we wanted to switch anyways to for choice uh used this payment channels in which the we would turn but at least to the end of the next epoch the payment to decide even if the builder would pay the for the block would pay the proposal or not. Now

talking to external teams, it seems that the major ask they had uh had nothing to do with the usual discussions we've been having here or like the way we thought teams would be affected. Most at least most of the teams I talked to, they were very worried about the infrastructure changes that they will need. Most of them come around the fact that they need to monitor this um these payments. Even worse, it gets even worse when these payments need to be monitored on chain because it requires rewriting of of contracts, auditing of constructs, and we're talking about like probably millions of dollars by the time that this EIP is implemented.

And uh this had the breaking change was this thing of like moving the payments from the EL to the CL. So now there's this simple compromise that I want to propose. There are two versions of them and talking to the people that are affected it seems that it does represent a lot of savings to them. One is that instead of paying by just a simple balance transfer to the validator, we set a withdrawal in the queue. So we get the benefits of turning the payments and we get the benefit of uh sending this payment to the EL by the usual withdraw as by usual withdrawal and then these teams can just

keep tracking in whatever contract they were receiving money uh the payment. So this will still require changes on the tracking contracts but it's not so deep as to go and check what's happening on the CL. They can still monitor the EL. Now the two different flavors are we could do just a simple withdrawals as that's it. That's that's a very trivial change but then this would be this would imply that payments would go directly to the withdrawal address and this is something that we have no control. This can actually affect deeply and even in worst case to some teams that set the withdrawal address for example to be owned by an operator instead of like the protocol. So the other option would be

that we keep the same sort of registration as we do today with builders where the validator sends a fee recipient to the builder and then when we affect the payment we effect we add a withdrawal to a particular address instead of just to a random address uh instead of to the withdrawal address uh in the in the queue. And my proposal would be unless you guys feel that this is going to be more complicated. This is definitely more complicated than just setting a withdrawal to the standard withdrawal address. But I feel like we already have the mechanics in change in place to set a fee recipient and setting a withdrawal to a particular fee

recipient does not seem to be complicated in any way. Uh yes and recipient would just be part of the beacon block essentially that they sign when they select a bid. So when they select a bit yeah exactly so the bid would come with a fee recipient. I think I'm I'm not following exactly. So if you're saying a standard withdrawal, so the the money goes to the withdrawal address associated to the account of the builder. So no no a withdrawal would would go to the account of the proposer and it but the balance affected balance will be the

builder account. That's correct. So it uh so this affects only but but we we can deduct immediately. So the way this works is that we deduct immediately the builder. So we deduct immediately the builder and by the end of epoch transition we set up we we just set that money into a withdrawal that we put on the queue is a second step. So the it goes to the balance of the proposer on the CL and then there will be a corresponding withdrawal.

Well, we don't want to send it immediately to the balance of the CL. The same reason as before. We're just going to process this by the end of EPO transition. So we need an extra queue anyways because we need to count at the stations. I'm going to get that to that that system. But this is the system that we discussed like many months ago. Yeah, we need to count at the stations to decide whether or not the builder should be charged. If the block is actually weak, then we return the money to the builder and if the block is not weak, then we actually enforce the payment and we send it to the proposal. The question is how? And now I'm just only discussing the latter part which is where does this money get credited?

Yeah I you but when you send it to the um proposer are you sending it in the CL or in the EL because you send it through the EL you will be go through some sort of engine API call right it's on the on the CL so the builder still gets deducted on the on the CL and F you're asking about the delay yes it's it's going to be delayed it's not going to be immediately in the same block but actually it's it has to be delayed anyways because if you pay 32 ETH We do not want to be removing 32 ETH uh immediately from the from one validator and accrediting another one and also because now we have this process in place to allow the builder to not pay a blog if the blog was weak. So this kind

of check we need to do anyways at Epoch Transition. So, so the basic process if we go with the the fee recipient method is that a proposer selects a bid. They include the fee recipient in their beacon block and then um assuming the happy case everything's canonical. What happens is basically an entry gets added to the queue to a queue on the beacon state for the amount of the bid and the and like the fee recipient maybe and then during epoch transition we process that queue and those transfers get taken from the builder's like balance. No. So

the money I think it's already taken from the builder. we probably want to refund the builder because otherwise the builder can be slashed. So then the queue, right, that makes sense. So So they get deducted immediately but put onto that Q and so then the Q is just the raw balance and the and the address and then and during epoch transition those those that Q basically becomes withdrawals. That's correct. That's that's the proposal. The only thing that it wasn't clear in your message, but I want to clarify just in case, is not that the proposer will put the fee recipient in the block. The proposer should register with the builder the exact same way that they do today and the bid should come with the field

recipient. So the proposer should check that the bit that the bid comes with the recipient that he wanted because the builder needs to sign the bid. But for staking pools, this still require they to rewrite their current contract because the because because oh this is happening on the CL not on the EO, right? So yeah, but the money they will need to check this and because mostly because of timing more more than the F here can probably explain this better than I do. But my understanding is that since the money anyways is going to appear in the exact same contract that they receive it today. Right. So then the the changes are much less

invasive than if we than if the money appears as balance in the validator. That's correct. So uh in the case of Lido it would just go to our rewards vault on the eel uh through the withdrawal. So that doesn't really impact us as much as the uh original um uh specification which really impacted us. I would say that from the external not considering all these things having the balance updated on the CL side would be nicer because you have compounding because now there is a weird case that most of the things go to the CL balance

but there's still some me stuff that goes to the withdrawal of the fee recipient which is kind of weird instead of having a full compounding thing. I agree. I think this is the problem of like the fact the the the sad situation is that we already have this large production system that started before the final game was designed and they are affected but uh but I agree that the cleanest system is what we had already that is happening only on the CL and let me get to the different point which is anyways we need to keep that system because there are validators there are BLS validators we cannot assume that every validator sure would have a with even a withdrawal

credential nor a fee recipient or anything. So I think we might want to allow a special situation in which the fee recipient and even for self building. I'm gonna be self-building and I would like my that money to not get out of the CL because of compounding as you say. I think we should allow a few recipient of something like zero to mean just give it on on the on the CL. But I don't know about this. We need to think about the design for those. I mean I I I think it's this is actually quite elegant just because like we already had a problem where we can't like the only time it goes to the CL is on 0x0 credentials and in that specific

case is the only time we actually don't have to worry about queuing the balance um for you know we don't want massive amounts of churn that we haven't accounted for and then the other thing is that um by sending it to E, we also don't have to have a whole another mechanism for queuing the balance. So, it just it kind of works out really quite nicely because I would think that if it wasn't this way, basically the time between you propo between you proposing a block and actually having the funds in some way that you can either withdraw like it becomes much longer and then we have to design extra cues or like cues that are more complex.

Basically, we don't in this case, we don't have like a like cues that depend on the size or like how much stake is in the beacon chain or anything like that. It's just, you know, it's just a simple queue. And I would think that even the accounting becomes quite simple because essentially um you know you could have this queue that gets processed like every any every epoch and then and then at every slot we just add one more withdrawal onto the and and the queue never grows and it just it just gets processed. I mean maybe the first maybe epoch transition is a little

complex. No. So actually let me correct something that I said incorrectly. Uh and this is an incorrect answer to fitty. Um in the unhappy case in which you propose a blog in which you're sending a blog to a payload to a block that is weak that it wasn't attested or was there aation or things that are not in the normal scenario then this withdrawal would be processed by the epoch transition. But in the happy case, the usual case in which the proposer submits his block timely, the builder submits his block timely and the block the payload is included in chain immediately. Then in that case when you process the payload, you immediately can

process the payment so that the payment can be turned can be put as a withdrawal immediately when you process the payload because it's canonical. You know that there has the block has enough at the stations that that's fine. If you reorg that payload in in a different place then anyways that that whole withdrawal and everything will be reordered anyways right so it still is in the queue but we can already process it is that what you're saying so what we will just take it out immediately from the queue and it will be processed immediately as a withdrawal so it will go out of the queue of payments from the builder to the proposer but it will get in the withdrawal queue and we can probably put it just the front running anybody any

withdrawal. So in every block we're going to have an extra withdrawal that is just the withdrawal for the for the for the payment of of the PBS system. Also we have to keep in mind that the blocks are increasing quite a bit. So if we increase the gas limit as people are claiming we might also want to increase the number of withdrawals from 16 to 32. That makes sense. Um, yeah. Well, okay. So, you're saying the only time that it gets on a queue for quite a while is when the the builder's block did not become canonical and then we have to figure out what happened. Okay. Exactly.

When the builder's block is canonical, then immediately you can just process payment because you know it's there. So, are there any questions about this or any I want to hear from Stefan. You are the only guy that actually implemented this outside of us. I want to know if you feel that this is doable, if you think it's going to be a pain, if it's worth it. Um, yeah, it doesn't seem like too much of a complication, I think, from implementation point of view. Um, yeah, I mean, depends how the specs look. I'm not like I can't visualize it right now exactly, but uh, yeah, from the from the way I hear it, it doesn't sound too bad.

All right. So, I'll take this as a good sign. I I also was envisioning that there wouldn't be much of an argument here. It seems like it's a hard request from a bunch of teams and it doesn't seem too complicated from from my side at least. Um, let me move on to the second point which I think this one is much more complicated and for this which is also I own. Uh, let me share also the document that I posted out. Uh, how do I do this? documents. What the hell? Screens. I don't want to share the entire screen. I want to share a window.

I hate Mac OS. Okay, let me just share a screen. God damn it. Let's see if there's a window sharing. Okay, I'll just share a screen. Let me see guys if you can actually see the um there's some keybased conversation that is actually I don't know if you guys can see this uh this document that I have now can see it okay fine perfect so let's see uh I'm just I I just want to go over this section that says problem description uh so this is an issue about for choice

and I want to describe the trade-off. I want to do this as clearly as possible and I'm not sure if we are going to get to agreement on to which if we're going to go with one or another, but I wanted for us to be on the same page as to what are the complaints and what are the possibilities. Uh we know that uh EF research particularly Franchesco was not happy with the payload boosts. Uh so he devised a different system that would minimally affect for choice but the problem of that system is that it uh relies on something which I call signaling in this document which we are not doing now. So let me describe what

are these things. Okay. So let me see if I can move how do I move this thing? Ah here. This is bothering my my screen. Okay. So if you're seeing in your screen because I can't see what you guys are seeing this diagram here this diagram the blue nodes are blocks that were produced and the payload was revealed and is included. So the new thing that for choice that EPBS forchoice needs to deal with is the existence of these orange nodes which is a block where the CL block was included but the payload was not included. So this diagram that is that you see on the screen is a diagram

in which the proposer of slot n is proposing its block reorging the payload. It's proposing the block on top of the consensus block of n minus one but without the payload of n minus one. And here's where all the problems arrive. We want a testers so we want to protect the builder in this situation where the proposer is trying to reorder the payload. Suppose that the two blue nodes are timely, they're honest, they were seen on time by the whole and they are valid. So now the propos of N decides to anyways reord the payload and a testers of N need to enforce that this doesn't happen. So an attesttor for N

needs to signal that this they are not happy with the block of N. How do they do that? There are two possible ways of doing this. The simplest of which from the point of view of specification would be when I send the attestation I send the attestation saying not only am I attesting for the beacon block of n minus one but I'm also sending you what is my e hash my my head hash or I tell you I am attesting for n minus one with its payload in okay so this is a way of saying n is not good I am voting for n minus one with the blue node. I need to say I'm voting for the blue node somehow. So either way

we do this, we need to change the attestation. That's what I meant by an invasive change that will change the transition and and I'll describe what are the changes transition in a second. But the whole point is that this attestation should signal some way that I'm voting for blue and I'm not voting for orange because the attesttor from N already knows what is the payload status in his view of the blockchain. So we could add a boolean saying the payload was there. We could add just another root saying this is my so we as usual we have a beacon block root which is the head of the consensus layer and then we add a block hash which is the head of

the execution layer and then an attessor from in this situation an attester from n would send the becom block root of n minus one and the block hash of n minus one. whether if the anester wanted to vote on orange would send the beon block route of n minus one and the block hash of n minus2. Yes, enrio. Uh just one question to complete one thing that you wrote in this document that I was reading. So you're saying that you were saying that the PTC is not you safely usable in this case because you mentioned that there might be some edge case where you are not you

yeah you it's not it's not safe to to to consider the PTC for I don't think we should decide with the PTC because well first of all the PTC does not have information about the validity of the block. So the PTC could agree that the payload was there but then the block was not right. This was this was Yeah. Yeah. I mean you could probably go around that thing because a testers can use that information then use make it conditional to their validity view that they themselves can evaluate now. Yeah. I mean but then situation where doesn't even reach consensus the PC might be split um and so forth. It also just seems more secure to um yeah definitely if you can solve the problem without PTC is

definitely better much more secure but then be depends by how much complicated this becomes. Notice that PTC does not help I mean PTC is not really uh playing a strong role in either approach. I I'm only describing one approach which is you vote and you signal within your atestation what is the one of the two branches that you're voting for right so once that we know that then those at the station the balance of those validators from block n would only support the branch that they're voting for so if they voted for blue then they only support nodes that desends from blue and if they voted for orange then they only support nodes that desend from

orange or if they voted for men. They only support nodes that deserve men, but they're but they're still using the PTC to decide what to vote for. I mean, they so PTC allows them to know if uh for example uh the payload was available or not. So if the PTC reached consensus that the payload was not timely, that's information that they can use. If the PTC reached consensus that the block was was timely, that's information they can use. But the whole point is that if the PTC is telling them the block was actually timely and uh the proposer is trying to reorg anyways, they should

actually vote for N minus one blue. Right. Yeah. So I'm just Yeah, I was just asking that before they make this vote, they the PCC affects what their head is. Yes. Correct. Okay. Yes. Now, here's the trade-off. So, the trade-off of this, of course, is we need to change the attization type. I was very afraid of this be because I still have nightmares of 7549, but um but apparently I don't know, Mark tells me that in Lighthouse, this doesn't seem to be so bad. The people from prison told me, "Yes, this is a bad change, but

we already have the mechanism in place because we switched the attestation type to an interface." So, it might be that it's not so invasive as invasive as I thought it would be. Yeah. I mean, once we have a forked version of something where it's one way in one fork and one way in another, like changing it another fork is much much more trivial than having it had never changed across forks. Um, so I mean that's certainly our case. And then I guess the other point is that we've presum I think we've had multiple like times where it's like it's just nice, you know, if we could change the

atestation, boy, wouldn't that be nice? We could do this design to that design. So I feel like once we change if we change the the final remaining piece, we've already changed the attestation, we've already changed the index attestation. Now the only thing left is the attestation data. And if which we would have to change here and if we did we'd be prepared we I mean our code base would be in a place where we could change it later if it became there. I just want to point out to that that um piece and actually I feel like it would be clear because I think that there there are obviously impacts not just in codebase but in the attestations numbers and aggregations

because you change the attestation data the roots changes of so if you have different conflicting votes on this particular information that we are adding. So the block space will be affected because you got you have more more more different stationation that it needs to but there there's only right or what I mean by that is we've only this change has only added like one more degree of freedom that has two possibilities. So you basically Yeah, but you're twi potentially in the worst case you are doubling. Yes, that's the number of attestations. Franchesco uh Enri, I'm

sorry. It's a good thing that we actually can aggregate attestations that were meant to be uh for different branches that we aggregate them separate. So when I describe the current mechanism, the current mechanism would have two different views of the blockchain attesting for the same route. that would be aggregated actually as you say they will occupy less block space but we will be mixing votes that were meant to be for different branches on the same attestation. Yeah. Not not changing the attestation you don't you lose this information essentially. Yeah. So we are actually uh having onchain the evidence of the

votes of full and and empty blocks. Yeah. And then I mean I don't obviously it's great to not change the um yeah like not have twice as many as stationations or being able to aggregate twice as efficiently I guess how would be the way of thinking about it but we just saved like what was it a factor of 64 like you know in electra like I feel like a factor of two I mean the change we should have plenty of space for that.

So besides the space the place where this would affect I mean the the major change I think is just the fact that the attestation itself changes but then on when I mention transition it changes how we count votes because if you get an attestation for say n minus one uh with or without the payload both of them you need to count them anyways in the same exact same way for LMG ghost. So this this is an attestation for n minus one the block route and it gets head timely or target timely or source timely in exactly the same way if if it was for the payload or without the payload. So we need to count them for justification for for for finalization as if they were both an attestation for

the block route of n minus one and disregard whatever payload content is. So we need to deal with with this but besides that I think I think that the the changes on transition itself are just very minor you need to change the reward right because of now you need to make sure you votes the block root and block hash both correctly to apply the reward we can discuss this but I don't think we should I think we just should just just consider I mean this is extra information you just remove the payload hash or the payload content from the attestation and you now you treat the remaining atstation exactly the same way

that you were treating it before. So I think that's the simplest change which is disregarding for for for the blockchain part of the atestation not the for choice part but the blockchain part of attestation I think the simplest thing is just forget this extra information that you have and process the attestation exactly as you had it before. Um I so you had indicated in the post that adding this extra information this signaling way of doing this uh makes the state transition more complex. Well that's what we're discussing now. It's

this this thing that now you need to deal with in state transition you need to deal with counting for justification counting for the timing flags of the attestation and all of these things. And I think the way the easiest way of changing that is remove this extra information and treat it exactly as it was usual at the station. Yeah. Yeah. I mean that doesn't sound too bad. And honestly, like the biggest anxiety about 7732 has clearly been fork choice. Um,

and I mean I feel that I mean this is the clearest like this makes fork choice conceptually simpler and alleviates those anxieties and I feel like sets us up. The trade-off is that it's a bigger lift in this fork, but that to me just I just I just think we should just do it like you know what do you want to trade like more work up front um or or like more work in future forge when when this isn't as clear basically.

Okay, so let let me let me say what what the trade-off if the trade-off is but but you guys have already implemented this version before. So what is the current way of attesting against this block of N? So in in the current specification an attesttor from N that is not happy with the proposer that is proposing and reorging the payload since we're not changing the attestation that tester will attest for n minus one the block route of n minus one that means that that block that that attestation that balance from that validator counts for both the orange and the blue branches. We cannot distinguish between

these two branches because we only are getting a become block route. But we count against the block from n. So that an attestation from n that votes for a block route which is previous from n, we count those against the block of n. This is the biggest change and this is what makes for choice actually much more complicated and it requires a complete reanalysis of all the reorgs and so forth. Uh because now those votes that are actively against n they make the weight of n minus one or n minus or or either blue or orange higher. They vote for

these guys and against N and that makes the proposer of N plus one makes it easier for that proposer to reorg N completely entirely even if N was honest. That's the thing. When you use your attestation to attest for a previous block, then that atestation allows the next proposer to try to reorg the current block. So that kind of analysis is the analysis that the payload boosts. I think I was very thorough and I think I found all of the actual um thresholds that were resistance for but it is clearly true that it changes the way that we are counting votes and I think this is the main complaint uh of people like Franchesco

uh if we don't do that if we do signal on the attestation then the weight count we still have this complication that we need to deal with the two branches whether today there's only one branch But that besides that the weight counting is exactly as today we don't we do not need to be running for choice slot by slot checking where this attestation happened or not. So that is the main trade-off is we don't change the the the code base regarding attestation type at the cost of changing conceptually and how we run for choice to to count the weights or we don't change how we count the weights at

all. We keep exactly what it is today. We use we use PTC though as as a signal to say which which branch you should attest for but we don't change how we count votes on the weights on the nodes. Uh and I think it's clear that for becomes simpler. Um so that's that is a trade-off. I think Mark already made a point of what his position is here. I would count also Franchesco as making a don't know about the rest.

Um, so in like a I think telling conversation you mentioned something about specifically wanting to do payload route versus bit for reasons of like faster lookups or something like that. Can you say more about that? To me it's just not obvious like why would we I mean it's not a big deal. Again the space is like whatever. is just 32 bytes and it's not a big increase to a decision side but it just wasn't obvious like why we would need the full hash root instead of a bit it's it's fine if it's a bit I don't have any particular preference Francesca is mentioning this thing that this extra information could be just a boolean the payload was or was not there and when you get such an attestation then you would get a block

route you will have to like look up the block route Then suppose that the bit the boolean was set. Once you have that block route you need to check where is the hash check if you have the hash for that uh for that block so that the attestation can actually be processed because now you have all the this attestation is for a block for a node in for choice that you already have that you've processed. If the attestation had both roots then you can just quick the root just check the root. So you pick up from the block route. We we already have maps in for choice that quickly give us a node by either sending a block route or a payload hash. And these maps become very I think it's they they become uh

necessary on EPBS to have this fast access to a four choice node coming either from a block route or from a payload hash. But it's it's minor. I don't uh it's not that I feel strongly about one or the other one. I think this is just a minor detail. Yeah, Mark. Well, there's a lot of things in the chat. Let me stop sharing because I I can't see this chat until Does this choice affect like the time for when a builder feels safe at all? No. No. uh the the this timing games of when the builder the delay between choosing the

bid and releasing the the payload is going to be there. EPBS makes it onchain explicitly on the protocol. Today is there offchain. The relay has the delay. This thing is about like not being unbundled and this will exist in whatever design you have. All right. So that that is a status I think everyone said. So uh this is a very small group and people have their I I don't feel I'm being

biasing too much uh by running this this way. But I do believe that if if this is worth it, we should switch to s the signaling approach. It it makes our life easier. It is honestly simpler in for choice. I believe that the current for choice works and it's correct and it's all of the reorgs I've analyzed them in absolute detail. So I'm I'm actually confident on the current for choice. But I do believe that it's true that for choice is much simpler. It is less of an invasive change uh conceptually to the protocol if we do switch to signaling on the attestation.

All right. So the last topic which is part of the same one uh that I needed to discuss which is this thing of the payment. So today we do this. Uh so we have proposer boost to give the proposer some safety that if the proposer is honest its block is going to be canonical. We have reveal boost currently which is exactly the same as just the PTC enforcement and then putting reveal boost to infinity in Franchesco's approach. Uh that means if the payload was timely then you enfor you you attest for the payload. you

enforce that the payload is there. So that's called reveal boost in uh in in the current implementation and that doesn't really change between the two you the with with the signaling approach we get for free that we can put the reveal boost to be infinity without any problem. but then there's also the withholding boost. The withholding boost is about like the builder when the builder wants needs to withhold its payload because the block was weak or because it felt like the payload would not be canonical and it honestly felt like this he could not submit the payload and we wanted to give that right to the builder. So we want that's part of the safeties that we

need to guarantee to the builder. The way the current mechanism works is by giving a boost to the previous block. Since we have this thing that attestations may count for previous blocks and that count against the current block, then we wanted to boost the previous block so that the next proposer can reorgate. Now the rest of the document that I that I pro that I wrote uh and I I was sharing just now was about a mixed scenario in which we sh we switch to Franchesco's system where we just count at the stations. So the builder will just count at the stations when it reach a particular threshold. It might be 40%

if we do the signaling approach. It might be 50% if we continue on this block slot mechanism. U but whatever it is the builder just counts at the station whenever it's safe that the block cannot be reordered by this next proposer then it just submits the the payload. That approach is what since we now are counting at stations and attestations might come in later than the block than the pay the slot itself. That's what makes us that we need to have this queue for enforcing payments. This queue for enforcing payments is about that is the with the builder withheld its payload.

The block appeared the payload well was never included because the builder withheld it and then we later on to decide whether or not the builder had to pay for that for withholding the payload or not. We count at the stations by the end of the epoch and if certain threshold was achieved like 60% is in Franchesco proposal it could be 70% if we keep block slot then we need to pay the the proposal and if it didn't reach that threshold then we return the money to the builder I believe and this was clear many months ago that we agreed that this system would be would have to be in place anyways regardless of like the safety for the builder. We want to have this

system in place anyways to not allow large transfers from validators. So I think this is clear that we're going to go with a payment queue. And the question is do we want to if we're going to go with a payment Q and we want to keep block slot that's how I why I produced this um why I produced this uh this document that explains why block slot remains with the same uh thresholds for um for reorgs. So the same safety assumptions are in the block slot mechanism with this way of enforcing withholding safety or we just to switch completely to signaling and uh we keep the current for choice.

Okay. So that's all we had along for choice. It seems only Mark expressed opinion regarding uh whether or not to switch to the signaling. I don't know about Enrio and Stefan or any other clients. I think anything that simplifies fork choice is a better option. So yeah, I think for us changing data stations also is since we did for electro now it's easier I think. So yeah.

All right. It's a is a cleaner solution. but again I'm not super sure that this change will be completely transparent from the downstream effects of the attestations. As I mentioned before, I will say that there is a nuance like in in electro we did not change the attestation data but yes we would be changing the attestation data but you know thing is that if you change the attestation data the majority of the work I would it's seems to me would be the attestation and the index attestation and we have changed those and so

like I I think like this would be a much much bigger iss like Lyft. If we hadn't done Electra at least for that even though we're changing something we haven't changed before but Electra like made it a lot easier. Yeah, we decided to to maintain the committee index there made it to zero on propose to simplify everything. So I mean for cleanliness I would think like we will probably implement a type of attestation data for Electra where that's like hardcoded to zero as its own type because that's the way our stuff

works. I mean if we end up doing this it's just like we backport it end up being the same. But um what else did I ask? Uh I don't remember now. Let me think about it. So we have also a presentation from Tony here. I wanted to just reply. So there seems to have been a long discussion on the on the chat. Well, I couldn't read it. So I think it's Sanskar who's asking about uh Yeah. So the the issue of um of uh the unconditional payment, why we have it? Um so the

removing unconditional payment but keeping the separation that the big win of 7732 is separating the broadcast of the payload and the block completely separating the broadcast of the payload and the block and maximizing it maximizing broadcast time up to the PTC at the station. There is no way of doing this um without this like having this PTC attization being very light. This has nothing to do with unconditional payment or not. There are versions of EPBS without this unconditional payment but they don't achieve this maximal broadcast uh mechanism. I think this is the the main way the main way uh the

adding or not the PTC is trivial. It's not a complication of the of the protocol. Forchoice gets complicated because of not because of PTC but for choice gets complicated because of these extra trees that you need to now deal with blues and orange nodes. That is the complication of forchoice and has nothing to do with the fact that the PTC exists. Uh yes, you have your hands up as you can just speak up. Yeah. Yeah. I was basically so so the position I'm in is that like I mean I wasn't super actively involved in this old execution work over at the F but basically I came into and I was also a bit uh confused about the differences between the proposals and I've definitely come around and I think

EPBS has many elements that I like and I'm still trying to figure out whether I like all of it or just some elements basically. So that's where I'm at right now. And in particular, yeah, I to me personally just like I'm not yet sold on this point of the unconditional payments because it feels like it's very prescriptive on the kind of type of architecture or like kind of infrastructure situation it tries to achieve, but then there's no guarantee that actually anything will change in practice. So it feels like there's just like it feels a little like that part part I just don't quite understand why it's in the end. And I I agree with what you just said that basically even if we were to completely ignore that point that like any design would have to kind of look like this. In principle I think

I agree but then I would still like to basically explore these variants of EPBS that for example just do the same thing but without the unconditional payment or they um basically for example I'm not 100% sure whether by the way you do need this PTC. I know there was some some some alternative variants that still do the full at astation back at the end of the slot and basically just that's what we'll hear now which is Tony Tony will describe now this this design where the a PTC and the testers are the same thing. Yeah, exactly. Maybe we can just go into that. Basically where I'm at is I feel like EPBS really kind of has a lot of these benefits that that that we've talked about in the past. I just feel like for now I would want to like still understand do we actually want to

do exactly EPBS or more like one of those variants of this EPBS style approach. Yeah, that's all I want to say. All right, so I think this is this covers everything. Uh I guess I can answer Franchesco later. Um Tony, if you're there you wanted to share. Yes. Um I don't really have a presentation or anything and Ansa already kind of introduced the topic a little bit. I think we I also don't want to rehash the whole conversation we had at the introp. I think this design that we ended up with in the morning is definitely kind of worse than eps was and I think we agree on that. But I think it might still be worth to kind of look at the whole design space and then

keep the pipelining and the unconditional payment kind of separate. Um I think by now everyone agrees that EPBS gives you kind of nice properties when it comes to the pipelining. It just feels like some of the pork chest complexity also comes with the unconditional payment and the PTC. And it feels like there might be ways where we can still get rid of the unconditional payment and the PTC without actually sacrificing most of the nice things we get from EPBS. And thinking of the unconditional payments, my main concerns there are that we just stack up a lot of complexity coming from stake builders.

The PTC is required. We need the PTC to have um builder safety. Then we need the PTC to ensure that the next proposal knows um that the payload he received is actually available or that the blobs in that payload were actually all available. And yeah, so not trying to kind of open the box of Pandora here, but I think it might be worth to yeah, step make one step back and kind of think through a a reasonable design that might get rid of a lot of the complexity from exactly those two things, the uncondition payment and the PTC, while still giving us all the the

nice um pipelining designs, the pipelining benefit. Well, I mean, I don't know what you have in mind there exactly, but I would I feel like the the nice pipelining results of of EPBS are a function of the fact that like it forces is you you know you can force a testers or you can force proposers to choose very early in the slot and then the addition of this extra

PTC which is entirely for like making builders happy you know allows you to remove the aggregation from the critical path and that allows you not only to use the entire slot for broadcast but also to get shorter slots than any other proposal. Um I I just I don't know what it would look like where you could get the same like almost the full slot for bandwidth utilization and be able to reduce the slot possibly basically down to the time for aggregation.

and not have like builder safety Yes. So I think builder safety wouldn't be a problem because we would just um rely on the the same mechanism that we use today where we would still have map boost. The builders would still need to trust the relay. The proposal would need to trust um the relay for the payment. So what we could do for example is just having something like um I mean we it's basically the design we discussed with Yas in the morning if you remember but just we would have for example some beacon observation deadline that is early in the slot so that the proposer has to commit to the payload publish um

the beacon header committing to the payload um attesters attest to it later in the slot. So at the end you would still need some aggregation here but then we could already um take the unconditional payment and the PTC out of out of the picture. I I I want to repeat that PTC is really a minor part. taking the PTC out. Whatever people keep saying here as as if this was desirable, I don't really understand why uh nor nor I don't nor I do understand why taking the unconditional payment while leaving the the property that this is compatible with the current mechanism. Uh, I don't

see why this is desirable except if you gain something along the pipelining or along the complexity. Taking the PTC out does not make for choice less complex. Uh, it's true. You're going to have you you need to look at the PTC to decide whether or not you're going to defend the payload or not. Honest validators should vote anyways for the payload regardless uh regardless of PTC. You don't even need to listen to PTC for that. uh PTC does not make for choice at all simpler. PTC is not part part of the complex part of 7732. The complex part of 7732 is the separation of the of the payload and the block is the engineering part around the engine API is the engineering about

actually implementing this. The PTC is really a minor part of the implementation. And I wanted to point out that once we have fos fossil like it can be combined with the the inclusion list committee and fossil. So like we're I mean we already kind of have that committee and giving it two functions and and then also just like we if we were just designing Ethereum today I don't think we would like look at it and be like well we can get rid of these this committee we have if we replace it with this off-chain component of this like re offchain relay thing and then think that that's like

less complex. Um, you know, like if we didn't already have relays, we wouldn't be thinking that having relays is less complex. I would at least that's that's basically how I look at it. Like I feel like you kind of look at the total system as the total complexity. Yeah, I can I can totally see your point there and I would agree. I think I think we should maybe also do the same way maybe with EPBS here and think of the pipelining and the and the unconditional payment separately because EPBS could still like live in a world where we

don't have the unconditional payment and not saying that the unconditional payment is a bad feature or anything. I think it's a it's a nice feature but I think it's separate and maybe we should just separate. That's why we disagree. I think I want to make very very clear this unconditional payment is not something that PTC is tied with. So forget agree about unconditional payments the we get the good pipelining properties today of EPS that people kept saying that is good is because this existence of these light attestations so PTC today guarantees the best pipelining that we know today. This I think is what was broadly agreed and that's why we discarded this option during interrupt

because the best pipelining we get it because of PTC. Now PTC also gives us unconditional payment but it's on top of the fact that we already get the pipelining because of it. Removing PTC makes a trade-off which is slight complexity less very slight. The PTC is the trivial part of the implementation and we lose the best part of broadcasting. So I want to be very clear about this. When people say they tie it with unconditional payment, this is not about removing or not unconditional payment. Removing PTC removes the pipelining benefits.

The chat history be tricky but I I don't know u the people from cat herders are here they might know if this is going to be available. Yeah. So it seems that we are split along the same lines that we were at interrupt regarding removing uh the PTC and then changing the pipelining. I mean, well, Francesca had a point that if we were designing Ethereum today, we probably would also not want to have a two rounds of voting or basically two committees, but like we still have

fossils. I guess they wouldn't vote, I guess. So, the way Fossil is interacts with with 7732 um this doesn't require PTC. So Franchesco's design used it on used the PTC for fossil but it's unnecessary. We can just include uh we can just optimistically have that testers of the previous slot vote on the consensus block that uh commits to a in the bid to what are the fossil includers that are uh satisfied in the payload and then validity of the payload is tied to those includers actually being there. So I think PTC probably is useless for fossil.

We need to think more about this but but I I believe that we can remove the inclusion list uh part of the PTC in like in Franchesco's design and just move it to a testers. But again, I I I strongly believe that the feature that we get of broadcasting up to the very last second is because we don't need to aggregate BTC attestations. Yes. So would you would it then be a trade-off between okay we don't get the um atestation aggregation out of the

critical part but instead have like um a few seconds reserved for at the station aggregation but on the on the other side of the trade-off we would get uh PTC out of the picture together with which is not payment that's the whole thing I I agree with you that is the trade-off we lose the seconds that we have for broadcasting in exchange change for a trivial part of the implementation which is the PTC. That's that's really the whole point. You keep exactly the same complexity of APBS which is four choice complexity. You keep all of the complexity of APBS and you lose the broadcasting in terms of a very little game which is removing the PTC which at this point it sounds to me that it's just purely out of I don't know I don't

really know why. Yeah. And I mean, seconds doesn't sound like much, but it that becomes more of the slot as we shorten slots. So like, yeah, I agree. I think we're all on the same page, you know. Um, it just these I am still not super comfortable with um this stacked up complexity with all the things that are then changing. Um, not saying that it's not worth it. It might be worth it. And the pipelining is definitely a feature we want. Um yeah, I I agree that okay, we if we want to get

um even more scale by removing that station aggregation out of the critical path, then there might be no way around the PPC. Um yeah, just not super comfortable with all the complexity. Also like the things we just discussed with the we discussed earlier in the call with the signaling versus counting at the stations for two branches, it's just all a lot of complexity that is kind of scary. Yeah, with the signaling versus counting annotations, I completely agree. This is a big change that that is a big change in in in portraits.

Uh I haven't followed the agenda. Did anyone Pety, you had questions? I'm not sure if you added them to the agenda. Yes, you did. I don't know if this topic if we can actually squeeze something more about this topic of PTC versus not BTC. Can we move on to P's question? Seems that we can Can you ask away, Py? Yeah, it's just there something uh I think uh it was it I'm sorry I have to open the the page. Yeah.

So, there's an EIP782 that just got like an hour ago, released an hour ago. And then the question I had was it seems that uh Ethereum researchers think that you could you can reduce uh slot times uh and then this is going to be something that is independent of whether you uh delay execution or improve slot efficiency or not. Is this my is this is this correct or is this uh is this absolutely correct? We could we could just implement that the slot is now 6 seconds instead of 12 or whatever it's deemed to be safe and that can be done without EPBS or without 7886 or without any other system. This can be done so

much time you get so much less. Sorry, can you repeat? I missed out. Right. You we only get onethird of the slot right now. I mean we could just shorten the end of the slot and then get I don't know. you get to like 50% maybe utilization for broadcast and and execution. But if we do these changes and then shorten the slot, we leave like it's like if we shorten the slot first, we leave a ton of time on the table where we can't do broadcast execution. If we do this for structuring first and then say in the next fork shorten slots, we can use like not only can we shorten slots more, but we can use more of the slot for the time critical things.

Uh I I'm trying to I'm trying to gro it. So you said the right approach should be that we do slot optimization first and then shortening slots. Is that correct? Correct. Yeah. Because we can't do both in the same fork. That's too much complexity. No, but my understanding was that they think it's independent. Doesn't really matter what the order is. Uh Oh, no. The order does matter. Okay. uh the so if we squeeze the slot to something that is incompatible with changing uh the the pipeline I mean some pipelines are incompatible with certain size of the slot and uh because you require this

interactions you require like to wait for this event to happen like the I the inclusion list uh should be available at this time the the the PTC should be at this other time whatever design you have might be incompatible with particular slot types. So some people believe I I am among those that it's better to just f first agree what is the slot structure and then reduce it and then one way of agreeing would be we don't include EPBS we don't include 786 we don't include any of these pipeline in PRs but we just twe what are the deadlines that we have today on the slot we make slot attesting longer or shorter actually DCIP is kind of weird that it makes it shorter but

anyways So typically the the the approach we would want without changing anything on the slot today would be to make the attestation deadline as much larger as a larger part of the slot and then the aggregation deadline being shorter and then the last part of the slot being shorter and just make the whole slot shorter. This is something that is possible to do. Uh what it's not clear is that if we do this before then I think we are already agreeing on the shape of the slot. We're already agreeing on what kind of pipelining we we want of the slot if we change the slot time. Now, so by that by that definition, you mean to say that this has to EPBS has to go first because there you if we if we want

EPBS, then it has to be first before changing the slot time in my in my opinion. If we don't want TPBS, then we can just sh change the slow time. But I suspect that changing the slot time would kill the PBS and would also kill 7886. I think I believe right. So then there is some clarification needed with the CIP because they seem to think that well verbatim verbatim I will try to read out the sentence that confused me. It would be worthy thinking holistically about the slot in the context of proposals such as delayed execution or EPBS. But we stress that shortening slot times has independent benefits and may be realized independently. So I'm assuming

the real I think the sentence is correct. I I think the sentence is correct. What they what what I think Bernab probably wrote that and I'm not sure if he's here but the sentence is correct. you the the idea is we want to include also in the discussion when we choose the shape of a slot how does this look in a world in which the slot is also shorter which we have been discussing. Uh so this is part of the discussion like how do all possible proposals look in a world in which the slot actually is shorter because there is an independent interest in having the short the a shorter slot time regardless of slot utiliz utilization there are there are benefits to having just simply

a shorter slot time even in a word of EPBS or 7886 uh there there's benefits that neither EPBS nor 7886 give you that shortened slot time does do give you. So I think it's fair to say that we need to discuss this uh together. I can share my screen. I have a diagram just for this like uh that I happen to be working on. So like uh can you guys see my screen moving? I don't know. Can you guys hear me?

Yeah. Yeah. Can hear you. Can see you good. Okay. So like if we shorten slots, either we shorten slots or we push the attestation deadline, we end up with this picture here. Like it's just we've either pushed a forward so that like we can make the slot just longer than the time it takes to get enough aggregates or we chop off the end of the slot and we keep a in the same place. That's the same picture of a slot, right? So like if we shorten slots today, it'll look something like this.

if we do just EPBS um we get this nice picture which is what we've been talking about and if we do EPBS first and then shorten slots we can push the PTC all the way back to sometime around aggregation and we can get this picture. So like the point of doing it in that order is rather than like you know chopping it off and we lose more probably more than half the slot to just doing none of these time critical things. If we do it in this order we first get the full use the full slot then we shorten things we get shorter slots. We have not only do we get shorter slots well these are the same effect. We can do shorter slots

because we're doing more things at the same time in a slot. Uh so Tony, no I I I think it might kill it forever. like there are timings that might not be compatible or or we're going to if we decide later on to go with the PBS after shortening the slot time without changing the the structure then we might need to enlarger the slot time again. Who knows? I don't know.

It's hard to to to do this I mean to think about this without actually testing these things and testing shortening slot time with EPBS at the same time would be very very hard. Yeah. Well, and also like even if we did it the other way around, we would basically do a bunch of testing to determine the like optimal timings of things and then shorten slots that amount and then the next fork we would do and then the next fork we would do all the timing tests again to figure out how we would shorten slots under EPBS. So it's just yeah I think it it this is this this is one of the things that I think was a no-brainer that everyone agreed we need to decide first what is the shape of slot and if we just include

the CIP to instam it means that we've already made a decision on what is the shape of the slot which is keep it as it is today which is fine it's it's a viable option but it is a decision um is the problem here just that we have two rounds of walking or and the latency that comes with that. I I don't know. So there are some parts of the slots that are variable and some parts of the slots that have a lower bound. Uh I don't know exactly what is going to be the exact interaction with inclusion list includers.

uh the part of the atestation unaggregated attestations that the builder needs to check the part of uh aggregation itself um seems to be fixed. So all of those little pieces play different in how you can shorten the slot on EPBS than without EPBS. And something similar happens with delayed execution. It just to me doesn't I don't know why we would prioritize in this direction because this is the best we get if we do like the picture that's on screen is the best you get if you shorten slots in this board. I don't know why we do that. Yeah, it's it's clear that I don't know for me it's a

no-brainer. So again when when things are a no-brainer I don't understand why people push in different ways. All right. So, I think that was the last of the agenda. We're almost out of time. Could Could you share that document, Mark, or did you post it already somewhere? Like a draft. Um, but I can share it with you. Uh, I could use some more. It'd be great if we can add it to the to the notes, Mark. Okay. To the meeting notes that Terrence is going to post. Okay. Yeah. and I would welcome feedback because I'm still like drafting it. But yeah.

All right. So before before we leave, I just want to have actual uh working points. It seems to me so one of the things that kept me from working on the consensus spec was the fact that there was a big opposition from EF research and clients didn't care at all. Now it seems to I'm getting some vibes that CL clients at least are completely aligned. Even E clients, the only client that actually was against was Reth and now I've gotten from them that they don't care that it seems that they get what they wanted from EPBS as well. So I I am I am feeling that clients are getting aligned on EPBS. So I can work again on the consensus block on the consensus

spec. I don't mind spending time on it. Uh so I would like to get it up to date. So what I want from clients is to signal on the channel on discord after you've discussed whether or not you support moving to the signaling approach for for choice. And if we do this whether or not you would rather see a boolean on the attestation or a hash on the attestation. So the boolean meaning I am voting for this block with a payload or I am voting uh with a block without a payload or the hash meaning I am voting for this block with this hash as head. When do we need to make that decision by uh I mean the

the earlier you do the earlier I start working on this. I think Franchesca is also working right now on this. So, I might actually use the fact that Franchesco might might make my life easier. But anyways, I rather do it myself as well just to to to see how it works. Just trying to get Devet 2 out by Monday. But then, yeah, it's it's definitely not urgent. We're talking about Glamsterdam and I'm definitely not working this weekend. I can barely hold it. I'm still in bed.

All right. Uh, are there more questions or comments? There were people that had a discussion about the auction dynamics and things like this. I'm not really sure that we are even the right people to talk about. Yalin. Oh, hi. Can you hear me? Yes. Yeah. I just wanted to clarify one thing that you just mentioned. You said that um with short uh shorter plug times and the EPBS there's a potential that they might like conflict with you. Is my understanding correctly that EPBS with EPBS with this pipelining you get really really good properties to increase throughput but at the same time you have potential that

you will give lower bound to the latency decrease that you can give or like the block time decrease that you can give. Yeah. So I I wrote something in which you would get more or less the same. I mean that was just wild speculation on my part of what I thought would be the minimum possible safe slot times and I was getting slightly larger slot time with EPBS than with solutions like 7886 for example. uh for the total slot.

However, the critical part which is broadcasting of data was larger still on EPBS. uh on the other hand even then which I think that they were more or less the same times even then there was an assumption which is unfair which is something that we have today that we will always have and I don't think I'll ever be convinced that this will not happen which is the builder needs to delay the revealing of the payload to protect itself from unbundling there is no current solution to that problem the problem now is happening offchain and EPBS makes it onchain. And that delay is exactly the delay that happened the difference between 7886 and um EPBS

at the limit in which the short go the slot time goes to zero. So I think it's very unfair not to count that delay in a world where this delay will happen anyways offchain. Um but module of that comment yes my guess is that purely talking in terms of protocol timelines I think the shortest I could get one was like 4.5 versus 4 versus 4 seconds or 4.7 versus 4 seconds something like this I see thanks um is it is it would you agree produce.

It's kind of fair to say that um 7732 would give us less time because we just have the two rounds of voting and this comes with some latency and 7886 would be like less time because we still have the aggregation. So the the voting the voting part wasn't uh is not additive to the slot. So it was completely absorbed in the aggregation plus execution time. So I think the extra voting does not add a latency. the actual extra latency that the slot has that is not utilized in 7732 uh and and 7886 doesn't have is the latency between uh block reveal and

payload reveal. So that that distance is in protocol in 7732 and and it's useless in 7732. So it's it's actually some a constant that cannot be removed from u by by making the the slot shorter. But I think that distance also is there in 7886. It's just that it's not in protocol. But even if it's not in protocol or if it's not in protocol, I assume that it can be shorter like you don't have to be this conservative as not really right because so the the deadline is

so what what happens is that you adjust the timeline for when the payload is the maximum time that it can be broadcasted and then you allow the builder to play timing games in like trying to reveal as late as possible. But the the there is no hard deadline to when the builder needs to reveal. The builder can reveal as soon as he knows that the payload is safe. And they can do this with EPBS or without EPBS in exactly the same way. So today what they do is they wait until they know they are safe and then they reveal and then they do this the this the tightest possible.

In EPBS the same game has to be played. It's just that now the protocol allows them that that time. I see. They're saying that even with EVBS actually builder doesn't have to delay until the the PTC deadlines. You can it doesn't have to but uh but that's that is really a fear and I think it's a real concern of EPBS is uh do we know what sort of timing games builders can play with PTC or not? And I think this is a real concern and if we decide to go with PPBS I am already talking to base rollups like Tao or like trying to talk with pre-confirmation teams. Uh we need to understand exactly what are the

timelines for PTC. These are going to be changing with gas limits because we don't want to be played by builders playing timing games during that time of the slot. I agree that this is a danger. Yeah. I guess like the question is are there incentive for the builder to have monopoly knowledge around the block for a longer time even if they can't change it? Yes, I agree and I think this is this is a good question. Uh when I talked to builders they told me this is irrelevant but then then again they are the builders. I haven't and I haven't talked to a single pref gateway. So what I talked is to pre-com teams and they told me that EPBS as it is they are supportive of it and that they believe it's uh completely compatible with base

uh preconfig. Yeah, I guess so. But like if L1 pre-confirmations actually are used, which I'm kind of skeptical of, but if it is used, then there is incentive for the gateway request providing pre- confirmation to delay the release of the block because if they have if they're the only one who have the knowledge of the block, they're the only one who can provide pre-confirmations, which means that they're the only winner and yeah, they can keep on winning. Yes. Well, data always not they can't provide pre-confirmations for the next block unless they are like in some way registered for that.

Well, okay, never mind. I guess yeah, but the monopoly creates them that they are going to be separate from the gateway basically is what we have to considering, right? Yes, data always. Yeah, I would just emphasize that at a 12 second slot, there's no advantage for builders, but if we start to push the push the slot very very short, then that sort of becomes a concern of ours. Yes, I I I completely agree. Uh this is what uh builders actually told me that given the current timelines, it's irrelevant and you can do whatever you want, but it's true that if we squeeze this to the maximum, then this this will become a problem. My hope is that we can squeeze it to a situation in which uh we force the builder to reveal immediately

because the PTC tight deadline is very tight. So that's that's my my thinking, but we we're going to have to get it correct. Just a question on this because um so uh it's milliseconds, right? That's that's what the builders need really to uh get the previous state and then calculate the next that's that's what they need for building the block to to simulate the block. But uh the the issue here is how much time do they need for broadcasting because you're broadcasting blobs and block and let's say that you need only one second to broadcast everywhere and be safe that the block will be there. then you can

broadcast one second before the PTC. And now if the PTC is at 10 seconds into the slot and at the station deadline was two seconds into the slot, you now have eight seconds to keep that block hidden from the race well 7 seconds to keep that block hidden from the rest of the world and you just keep it yourself and you have a monopoly on that information. So if we really want to schedule the PTC as close as possible so that we can squeeze out the builder from doing this from playing these games.

That's that's my guess but I again not my expertise. The ceiling is time the how much you squeeze a PTC uh at a station that's the ceiling basically right or uh yes that's the ceiling for broadcasting and then broadcasting plus execution is determined by the size of the slot right and uh so we want to squeeze the slot as much as possible let's say that the builder has a monopoly but the monopoly is transient right it shouldn't be like permanent monopoly over time it sort of goes to zero, right? Because me opportunities are not permanently there.

They just this is pre the monopoly I think is more dangerous with preconfirmations like they can become a pre-confirmation gateway and they win every auction. If the the gateway um has more information that that I think is the the the actual danger if confirmations become prominent they can win uh private order flow because private order flow would flow to them because they have more information therefore they can provide preconfirmations that others can't. So just just again just to summarize EPBS as it is not a problem for pre uh uh pre-MPS but then if you start squeezing the slot uh and there's EPBS now there is a

problem with the preconfirmations not not I wouldn't phrase it that way we don't we don't really know about this problem uh today so we are suspecting that there might be a monopoly on information that might play a role that monopoly of information does not play any role today for building for like L1 block building but it will become a problem for L1 block building if the slot is very very slow short but I don't know how the dynamics with preconfirmations of this particular problem is Tony you had your hands up for a while yeah just just to understand it I think I got it wrong here with squeeze I mean we on the one hand we want to put the

PTC as early as possible to avoid um builders kind of leveraging their monopoly and on the other hand we want to put the PTC as late as possible to allow for um as large payloads as possible. Right. Is that the correct correct so what what we want to do is to make the G phrase it in a different way. What we want to do is to put make the gas limit and the blob count as large as possible so as the PTC to be at the end of the slot and then we achieve that the PTC is as close as possible as early as possible and as late as possible at the same time. Yeah, it's it's really a question of how much you stuff in the block which is actually also a question of how much

how large the slot is. That's the other dial you can Exactly. We have these two numbers which is slot size and uh PTC place within the slot and we need to play with these two numbers so that all of the slot is used for broadcasting plus execution. So this more subtly though brings up a point in that we can cl crank up blob limits to try to make them not want to use this monopoly.

But that's only so effective if say the like the blobs are really worth more than monopolizing because you can just have less blobs that you're broadcasting in your block and then monopolize the Yeah, this is this is really something that requires its own research and um and it's going to depend on whether or not preconfirmations are mainly on roll on L2 or on L1. If you're giving preconfirmations for things that are happening on blobs or preconfirmation for things that are happening on on on L1 transactions. So I think this is just second order thinking right now.

Oh, I didn't and I didn't see Connor here. I did get a complaint uh from Connor which I haven't seen here. Well, I'll send you guys to read. So, one of the complaints is a very well-known problem which is a free option problem. Julian raised it uh and I think Max Max Resnik had raised it before which is on EPBS the builder might not reveal it has an option not to reveal the payload if it's profitable not to reveal the payload the builder has that option today as well but today the relay enforces somehow because of reputation so that's the argument so that is a complaint it's known

uh the people that know about this are not here. So probably not not at least I wanted to mention it because it is one of the complaints that I've gotten in this last few days. All right. Uh we are really out of time so let's cut this short. Well cut this long. my working uh I I'll start working on this as soon as I get some feedback from client tanks on what are your preferences with regards to choice. Um take your time and make a decision.

All right guys, going on once, going on twice, going now then. Thank you very much for coming. Thank you very much. Cheers guys. I Yeah.

Heat. Heat. Heat up here. up here.