ePBS Breakout #15

Transcript

[Music] Uh so welcome to I think this is uh the breakout number 15 if I'm not wrong or is it 14 uh for EPBS back from a meeting where we forgot about it. Anyways I apologize for the last meeting. Uh we have a short agenda today uh but it's uh it has a couple of interesting uh discussions that we may have. Um so the EIP hasn't changed at all and I'm hoping to change it next week or so as soon as Stefan tells me

that there is an implementation that we can actually uh test again. Uh I suggest we first start with a client implement stat implementation status. Now that Stefan is in my screen, you can tell me something about TechU perhaps. Uh yeah, so I've been running Tech locally successfully and with uh one node and then Enu helped me uh help help me test with two nodes and so on. So so we're finding a couple of issues. So fixing those.

Um but yeah, it doesn't look too bad. I think we're not we're not far off from uh providing an image. Obviously, forward syncing is to be discussed. Um but yeah, overall should be soon. Uh perfect. We haven't we haven't implemented syncing yet in pris in prism either. So uh and this we need to this is part of today's meeting. Uh but but if you if you can if you can do like gossip syncing uh as soon as you have such an image I'll put it set it up in Corttosis and then I'll give you a prism image so that you guys can test against us too.

Oh yeah that'll be good. Yeah right now there are a couple of things which we're fixing but yeah uh yeah I will let you know independently by our our image if you have something to share to run curtosis is super welcome anyway. So we can we the first that can have something could share to others. Okay. So I'll I'll uh I think Terren is here. Uh we'll we'll we'll prioritize this next week. Uh so by the end of the week I'll I I'll be working on EPBS next week and then by the end of the week we should have something that at least should start from Genesis and uh and gossip it.

a lad. There were some some situations that that we know would break us like for example uh uh a skipped slot and then the the with if with withdrawals uh that would essentially break us uh because of this issue that we talked last time uh about like recovering withdrawals because they're not uh stateful but uh but that's should be easily fixed. All right, so that's it for tech. Do we have clients from other do we have devs from other clients? I don't see well Mark is here but I don't know if you guys have implemented anything.

I mean the the block processing the separation of the payload that kind of stuff. Um haven't gotten through fork choice or networking. So that would be oh we haven't we haven't even touched for choice either. Uh what we we did touch for choice in in as much as to like dealing with missing blocks but but nothing of the fancy thing of like counting at the station protecting the builder. None of this is implemented either. Okay. Yeah, that's that's where I'm at anyway. And I I've just been trying to understand some of this research around pre-MPS and that kind of stuff in the meantime to try to understand where the road like where we might be in the next

12 months. I think you should have enough for a death net even though you don't have syncing and for choice right you can just know up the four choice part and you can just run the local death net with what you have but no can he needs the P2P though oh for the gossip yes okay he doesn't have gossip got it all right all right uh I don't see dusting or anything from uh from Nimbus so I assume that this is all from clients.

All right. Uh the next item in the agenda was Mark, but I think we probably bumped that to the end. And uh we wanted to have a discussion. I don't see the right person. Oh yeah, you are here. Um about the beacon API and how how about syncing like someone was requesting how the endpoint was going to be. do you want to lead this uh this discussion? Yep, can do. So um basically I've been working on getting the spend ops tooling ready for EPBS uh spec specifically Dora and um I've noticed there are no spec uh specified changes to the beacon API yet

and um basically there is one endpoint needed because as the execution payload is delayed and no longer part of the being block body um we need basically an API to fetch the wall execution payload or better the the execution payload evvelop from when it's ready um should be a simple API under the beacon domain um just via the block route or something and yeah to request that additionally to that um it would be also great if we add an additional topic to the event stream to notify tool links if a new execution payload is received by the clients as that's an async

process And um yeah, I think that's everything I have from the API side that's basically needed to get the toolings up and okay so with for the event stream I completely agree with and that should be very easy like we we just trigger an event for uh for the payload envelope and we keep the event for blocks as we had before. Uh for the requests I'm not really sure what's the best path. My original thought was that when we request blocks by range for example from other nodes or when we request a block by root which we do for example when we get an attestation for a block that we

haven't seen or when we get a block whose parent route we haven't seen we need to request that block for that route. I was thinking originally that uh for both we would uh keep the same API. You just request a block by root and you you request a block range by slot a range by slot and we would reply back with the block and the envelope as a sidecar. So all of them together and if the envelope was missing because that block didn't have an envelope that sidecar would be just empty. Uh I think this might work for you too except that if Dora is like just requesting the

block by root uh in real time then the same request might come empty first and then later might come with a payload and you will never know if it was with the payload canonical or not until you've made this same request later. So I'm not really sure if like doing this way uh requesting the block by root and getting the the envelope with it uh if you're requesting it for the current slot or the next slot you might get different answer. I don't know if it's a good uh the right answer. Yes. Wait, sorry. Uh, ju just to intercept. I think um does Dora use P2P RPC or Dora? I

think PK is talking about the beacon API for ging execution by yeah just to just just to have one single endpoint for the beacon API to get the execution payload. That's it. Th this this has nothing to do with syncing yet. Oh, so from the Oh, this is only beacon API. Yeah, we should just have an endpoint that says give me the give me the payload envelope for this route and that's it. Exactly. Yeah. So it's much simpler what what he was saying to connect to what you are saying pus about not changing the by root and by range essentially making the changes very yeah the most simple as possible depends by

the implementation by way I was thinking that decoupling blobs and payload it opens up another situation where the node could become aware of a block without knowing anything about the block itself, all the blobs and then it just listen to the envelope. So it could request by root um blobs and the block itself uh because the envelope has the block route and also all the commitments. So you to to recover by root what you need for that slot is if you just received

the envelope you could you could do that. So it's it's an argument to have separated um at least by root uh requests for the range. Yeah, I mean we could have. So you mean you don't you don't want to get the waste? So you don't want the waste the envelope by root and it's it makes sense in some way because you are close to the head so you're following the the chain you want to be efficient in that situation.

Yeah I agree. So, and and having having an option an a boolean is it bad bad design or I mean do we want to have a separate endpoint or do we want to have like a request by root and then a parameter that says give me the payload? It's is a parameter some ah yeah it's a it's part of the request. So we could the the message so you we could add something there. Yeah, the question is we want to have two separate calls. One is payload by root and and block by root or do we want to have one call that has a parameter that says I want both of them together or not?

Uh I would like to have a separate call because then the the the ser the serialization of it will be tricky because this become dynamic based on what you're requesting. Instead, you can have a type that is ti tied to the specific request that is you get and you don't have to deal with am I requesting with blobs or not with blobs and then change the the the serialization type essentially dynamically it will be easier I think.

Okay. Does anyone disagree? I I see Terren agreeing with this. Okay. Sounds good. Uh so one more for you than range. So so by range I think we should keep the the because when you're requesting by range you're really requesting just canonical blobs. So it's fine to just but we have a separated blobs. Uh well yeah it's kind of weird that we have blobs as separated by range and then this become unified block.

uh terms of design high level design uh yeah we can discuss it this later is less important yeah yeah yeah so I do not know but yeah it's true that we're far from implementing this so we can we can first implement check how it's working and then go back and decide it opens more options if but it's more more probably more complicated to to to to orchestrate the the request uh but we already doing this with block and blobs. Uh but then yeah, you could have you might be interested to get only payloads. Is there a world where this is important?

Don't know. I don't I don't see how for for a for for a node that is syncing. I don't I don't see how. Yeah. Unless this RPC are also used by other use cases. I don't know. I don't see how. And uh but I have another one for you for the other one because we we will need this for for syncing anyways. Uh do we want to have like a call for the block, a call for the payload or do we want to have a call for the block and a call for both together?

I mean is there any any situation in which we will be requesting just the payload? I guess if we synced the block and then the Yeah, that's right. We haven't seen the payload. We sync a block and then the child comes based on the payload. Then in that situation we would want to request the payload by root. I I would keep it separated and you you just leave the decision to the client if if you're missing both is doing two two requests and just one. Yeah. Okay. Much simple.

This sounds good to me. Uh, does anyone want to take over like the the beacon API for for this both for the endpoint for the API and the endpoint for the RPC request? Uh, because we will need the the block one. It's just a simple change. It means you just give me back the block the become block. Actually, there's probably no change uh because the block is just a new block type and that's it. And then we need to add one RPC call for the payload by root and then one beacon API for the payload by root.

I I can do that. It's not no one is perfect. Stepping up. Okay. Okay. We took Enrico as a as a volunteer. That's great. All right. So is there and this would satisfy Dora already? Is this all you guys need? just the beacon and the and the and the and the event. Yep, that should be fine. Actually should already be uh ready in a basic uh way without showing execution payload details because right now I can't get them but the basic support should already be there. I just haven't been able to test it yet.

That's that's very good. uh we so yeah so so what would be uh because I'm I'm sure you you haven't done this if you have done this already that would be fantastic because currently the Dora would show you the block as either missing or proposed like it's either green or orange I don't remember uh but we will need a different status we will need a different color for a block that has appeared but the payload has not.

Yep, that's planned then. But I need at least the event for that to show. Right now, it will just show it as uh missed or proposed without uh information about the execution payload. But then then this this change of having a different status and a new uh and a new color for it. So, do you think it's possible? Do you think it's uh or it's going to be just too invasive? Yep. Should be relatively simple um as soon as we have the event for that. Perfect. This is this makes me very happy. Thank you. I have a question. So Dora also shorts for example orphan in a way that consist block if it's like it's not missing it's orphan actually shorts orphan right the same will go with execution payload

because you can actually reorder the execution payload right so we need to short that not sure how though could be yeah so this is a new type of orphant um okay interesting I'm not that deep into the spec set um need to check that out And yeah. Yeah. Yeah. We can probably take it offline. It's probably Yeah. Yeah. That's right. Because we're gonna So, so if we have like a separate tab for payload envelopes, then that tab can show this payload envelope was orphaned.

All right. Uh so the last topic might be the contentious one. uh Mark and I think Sean from Lighthouse were uh mentioning some incompatibilities of EPBS with uh with pre-confirmations and it'd be nice to know what's the status on that and try to understand if there's an inherent tradeoff or not. Yeah. Um so pre-confirmations, uh yeah, this has been something I've been looking into and fair warning like I'm still looking into it. It's not like I understand everything. um but just trying to understand what the basic idea is. Now the existing design of pre-confirmation is in pre-confirmations

is in an MEV boost world. Um I think it's fairly easily adaptable um to the current world. So I will let me see I'll share my screen a bit. How do I share? There it is. Okay. This shares more than just Oh, that's weird. Did it Did it really just share like a small section? Okay, hold on. Let me figure out how to go back to this zoom.

My whole Zoom window now went Oh, there we go. Stop share. Okay, now I'll try again. It just shared like one sliver of my Okay. So in the design at least under the the current like me boost regime um there's like a new entity basically a gateway which accepts uh pre-confirmations from a user and gives gives them pre-confirmations and basically what that's doing is restricting the space of building for the builders. Um, you know, in an ideal world, this gateway would actually be the proposer,

but it follows the same logic as propos proposer builder separation that you kind of need to be a sophisticated entity to be a gateway. At the minimum, you need like some kind of deo protection. Um, but I think you would also need like if you're given pre-confirmations for like a based rollup or something, you would need to have the builders for those based rollups. Um, I don't I I would think that you would need to in some sense be a builder yourself to be a gateway just because you're you're specifying like you're specifying requirements that the block must have and there's a chance that no builder bids your block. And if

no one builds your block and you've given away pre-confirmations, you have to have something to fall back on. Um otherwise you would get slashed um for not like honoring your pre-confirmation and missing the block. Um in this design at least there's this there's this additional more sophisticated part party called a gateway that users are sending their preconf requests to. Now the idea is that proposers register with these gateways ahead of time and so that like when it comes time for some proposer to have some block users know where to send the request to because

they can look up which gateway that proposer is registered to and they can send the requests. Um and wallets would do that. The idea is wallets would kind of do that in the background. Um and yeah so the idea is basically like proposer has their has their gateway. Now there are some designs too where there's an auction to become your gateway. Um so basically like some ahead of time auction like gateways basically bid for the proposer to select them and the proposer would like in some way select a gateway. Um then uh when it comes time like like

users will start sending their their requests to it in the slot before these these restrictions on the block are communicated with builders and proposer still has the final say on which builder ends up winning their block. Um this can be like adapted in in the current EPBS design. Uh basically it still requires some off-chain entity to be a gateway. Um but in some way the proposer will have to have committed to a gateway because like the only the thing about a gateway is it kind of has the right to specify like

the proposer has delegated it the right to specify the conditions on the block and it needs that otherwise like your pre-confirmations are useless. Um so what I what I don't understand of this is uh in EPBS the box that is there that says relay becomes the builder itself. Yeah, the builder becomes a relay and I would say I don't understand why why this market of like the proposer committing to a particular gateway or not. Why cannot be the fact that the proposer is committing to having his blog being built by this or that or that whatever whitelisted

builder is. So I am a based rollup and I want to have preconfirmations for my rollup and uh and I say whomever is a proposer for my blocks in this in this space rollup needs to be using this white listed set of builders those whitelisted set of builders are this relays and they are slashable of protocol in their in this base rollup they are slashable if they don't honor per confirmations they need to build their blocks from whatever this rollup gateway is. And the rollup just sets up the gateway as an entity, whatever.

That's just fine. Like um you could I mean you you just have a gateway. You wouldn't have a relay, but you I mean it kind of makes it simpler if there's a gateway. know if there's just a whitelisted set and they all have to like there needs to be some entity that's given out pre-confirmations anyway you yeah just the the gate I cannot get away from the way gateway my point is that real is that this market is just between the builders and the gateway this is still the same thing it's just that some needs to be given out pre-confirmations and then the proposer needs to select from a set of builders that are honoring those

pre-confirmations. Exactly. And so it's it's fine for the relay to go away here, but you still have a gateway, but that's fine. Yeah, that's correct. So I don't I haven't seen yet uh something that is sort of like a blocker, nor why would a pre-MP team be unhappy with this. But you mentioned something that is an inherent trade-off, which is the gateway cannot be given breakoff during the time of the slot. Well, so the the issue is like the reason that the proposer has to delegate a certain gateway um is that the only one who can give pre-confirmations is someone who has like the the actual rights to build a

block. So like like I said, ideally it would be just the proposer directly, but um yeah, we don't want them to be sophisticated. Um, but all of this kind of off-chain gateway infra infrastructure is to do with the fact that we don't ahead of time give like a specific builder the right to build a block. Um, and this is what gets into the trade-offs. Now, there are obviously designs like execution tickets that do that do give a builder the right to build a block ahead of time. The problem with this is that once you start giving

once you know ahead of time that like a specific builder is going to build something, you enable multi-lot me. Um, and that's like a centralizing force it. You know, it's more profitable to have more than one slot to to the math works out that optimizing your MEV for multiple slots if you have them is going to be more profitable than the sum of your optimized individual slots.

So Mark, I'll stop you there. I think execution tickets or whatever sort of slot auctions or anything in advance, I mean, this is one of the problems that we have, but we have plenty of problems. We do not know how to implement any of this. There's pro choice problems. There's a lot of research into trying to implement this. I think this just probably is out of scope for an EPBS call. Uh execution tickets are far away from being implementable in protocol. Okay. Yeah. Um well, okay. So, but that that was one of the the issues. And so like the trade-off that I was mentioning is any construction in which you know multiple slots ahead of time you you end up with

this multi-lot MV which is not well understood and which we know is a more centralizing force than what we have now. But like knowing things well ahead of time is really great for execution tickets because everybody knows exactly where to send the request to. Um, and so like if you want to get rid of multi-lotme, you need a kind of just in time auction. And actually, ideally what you need is right after the payload for the previous slot is revealed or committed to in some way, the auction for the next slot or like the yeah, the builder for the next slot is decided.

Um, it's like basically like as soon as the as soon as the state can be known for, you know, what the the previous slot is, you want to be able to decide who is going to build the next slot because then you have the maximum amount of time for that person or entity to give pre-MPs. Um even if like even if the state of the previous slot isn't known they could still give what are called inclusion pre-MPS which is just like I will include your transaction but there are other kinds of pre-MPs like execution pre-MPS where not only do I include commit to including your transaction I actually commit to like how your transaction will execute I provide some

kind of state commitment. So if you don't know the state of the previous block you can't give these execution commitments. So, and and it has to happen after you after that is committed to because if that decision happens before, then a builder can like presumably change their block at the last minute if they're not if it's not been committed to and then they could do multi-lot me. So, basically, it's like as soon as as soon as they've committed to some slot, then we have a decision for the next the next slot. Now, I was kind of thinking about this last

night and I had a interesting idea. Um kind of a hybrid of like execution tickets just around this now. where maybe let me see I can't really how do I move this? trying to my uh maybe I'll just I know the keyboard shortcut to switch tabs. I like I kind of can't switch tabs because my zoom banner is in the way.

There we go. Okay. Um, now I thought it would be interesting if we had a kind of slot auction decided by execution tickets. Um, and I thought maybe there's a way to do this which is also just in time because if you have it just in time then you can't then you don't have this multi- slot MV problem. So the problem with the standard exec one of the problems with the standard execution design is that you would rely on the randow to determine which execution to get one. Um and we don't have a way of doing like low latency randomness. So basically like you would effectively

know not just you would effectively know the the builders that won you know an epoch ahead of time just as you know the propos the beacon proposes an epoch ahead of time. Um like that again enables multi-lot. So that's like an issue. Um but there is like an alternative execution ticket distribution mechanism. Um it's not like super crazy, but it's just this it's called proportional all pay where you know um you let's say you're auctioning off a slot and the builders are bidding for a slot and each builder puts in a bid and all bids get

burned and basically it works out where like your odds of winning that auction are proportional to how much you paid. But even if you pay more than everybody else, it doesn't guarantee that you win. if that makes sense. It's just this proportional allpane model and it ends up actually being a little bit more fair because it doesn't mean that the the best builder necessarily always wins the slot. Um, and so the construction that I was thinking we could come up with maybe is and and this seems to work as long as as long as the proposer is known like like 32 slots ahead in in advance. But if you had this kind of proportional all pay

thing where say let's say at block n you're auctioning off a ticket or like you're you're holding an auction for the winner for the builder of slot n plus 32 and you do this proportional all pay. I do not know how to do this even if you sold whatever it is. That's why I'm really I think execution tickets approaches should be kept at a research level and not at an implementation level. We do not know how to solve poor choice for that. We just don't know how to do that. That doesn't play well with uh with FFG.

Okay. Um we do not know how to add slashing conditions. We do not know how to solve for choice. This is not even mentioned in any of these research papers on execution tickets because no one has tried to implement for choice for that. Okay. Yeah, that's I suppose that's just the part I never that's probably why I'm not aware of this because I I didn't read it in any of the the challenges. Um yeah. Well, but but I do want to talk about a trade-off that you told me which I think it is a trade-off. So uh which I think it is something that may affect TPBS. So I want to have some thoughts on this

which is the following. I I don't see any problem in having a gateway and having all of the pre-confirmation today that makes the proposer choosing something and the prop say when the payload arrives is true that you can have a pre-comfort right there and it can be chosen for the next block and I believe that it's fine if the if the builder makes that choice instead of the proposer making that choice because anyways the builder is going to be the one that is going to have to bid for the next block and it's going to uh and it's going to have uh to eventually pay the proposer for it. So it's fine if this market of like the gateway being uh auctioning auctioned out is not

between the proposer and the gateway but it's rather between the relay and the gateway which is and the reader becomes the builder in EPBS. I don't see any problems with there. However, there is a trade-off that I would want to have the people that study these things look into, which is that there there is a time between the block is being committed, which the current spec says that's going to happen at about 3 seconds and the block the payload is broadcast, which is about 6 seconds into the slot in which no one can give any preconfirmation because the block except the builder that already built that block.

So the builder that already built that block has the block. He can give preconfirmations for the next slot and no one else can. So in principle that gives an advantage for the UX and that might be a centralizing force for builders. So we want to minimize that time. Yes. Like so any so any just in time mechanism is going to have that kind of dark period between when the last payload is revealed and when the builder of the next slot is chosen. And in that period um that's not that's not the period that

I'm that I'm mentioning. The period that I'm mentioning is between the because we're not even doing a slot auction just in time. The period that I'm mentioning is between the block has been committed in the the the payload has been committed in the beacon block and that payload is available. That is the time in which a single entity has power over the next has knowledge of the next slot which no one else does. Yes. And the question is how much that knowledge is valuable. When I talked to builders, they told me that that wasn't valuable because they can simulate a block immediately. However, if we put pre-MPS into the into the into the game,

that knowledge might be valuable because that person can actually give preformation that no one else can. And moreover, it might even entice the builder to delay the broadcast of the payload. Yes. Yeah. I was just speaking in general terms and like I was agreeing with you but I was trying to speak in general terms I guess because as you pointed out this exists in me boost and this exists in the current EPBS design correct and and I would want to understand exactly what is the time difference because me boost seems to be better for this than EPBS is one of those things in which EPBS would make it

really worse. Yeah. And it like I said I was trying trying to quantify the the time period. The time period is between when the when the um when the payload for the the previous slot is decided and when the next builder is chosen or the next gateway or whatever. so in in let's say EPBS let's say we consider that so if you're the gateway for some slot n minus one and you um you know you've been chosen or whatever

you know what pre-MPS you've given. Now granted these could be made public in some way but if the once the the payload is chosen um see how do I how do I put this there's basically a hard deadline in between when when the block is chosen and that's like the attestation deadline which is 4 seconds in the the EPBS or in in me boost.

Yes, in EPBS um thatation deadline is currently set to 9 seconds, but it could be moved a lot closer to like 6 seconds for when the PCC committee's deadline is. Yeah. and the issue is like if you're the builder who's one this and you know that you're competing in a slot auction or you're about to compete again to I if if the builder and the gateway are in in like the same entity and they're about to compete again to win the next um to be like

let's say the next gateway. If you're the gateway that has the previous block, then you have information on what the state is that no one else has. And so you can give out those execution pre-confirmations in that little that dark period. and as far as I can tell, the gap here, the relevant gap is just the attistation deadline of the PTC committee versus the attistation deadline of the regular block and me boost. um which appears to be about 2 seconds.

So if if we move the PTC to six, yes, it's it it can it's going to be about 3 seconds of the dark period because the payload is going to be committed at three and it's going to be revealed maximum by about four. Uh about five, I'm sorry. So it's about two seconds. Does this does involve like several assumptions like that the builder and the gateway are the same party you know for the protocol it has to be the same it doesn't matter how it goes because the the the builder and the gateway will have to have a deal either with me it's it's it's a deal that they already have

on uh commit boost it's a deal that they have on any design that I know of pre-confirmation the gateway needs to provide those transactions to the builder and they they have a trusted system in which the builder commits to to having those transactions. So that part I think it's no change. But I mean it's it's okay if other builders also have some idea of what the state will be. But it's just if if you're incentivized to hide it from them so that even if they won the auction, if there's another gateway, actually really if there's another gateway that would like to win the auction, but he doesn't know the block for the previous slot because it hasn't been revealed yet, then he can't give execution pre-confirmations

because he doesn't know what the state will be. And I think that's the question. I think that's precisely the question. Is this really a centralizing course or not? Do we have the black the black of like this this black box of two seconds in which only one entity can be given execution uh confirmations. Is it really a blocker? Is it something important? This is the thing that I think we need to be quantifying uh on map boost that time I think it's about two seconds today. So that's why I'm not that worried because on MEB boost the same we have actually two seconds now the relay sends the block

uh has the block at about two seconds and the deadline is four. So I think it's not changing much. That's why I'm not that worried. But it would be nice to have this from like EF research or or people here than to have to have this quantified. Well, right. But I think it's the problem became kind of clear. I don't know. We've been talking the two of us, but I don't know if other people here have comments over this that there seems to be something that will change. There's this black period of time where only one entity in protocol now has information that no one else does.

And I mean, well, that was always the case, but it's now the case that that information might be valuable. Yes, correct. So, so the question is do we want to do we we need to quantify this and we need to have an idea of what we're facing. Uh and we need to know if if we want to change it or not. Uh slot I mean remember that exactly this was what killed slot auctions. Essentially the same abstract problem is what killed just in time slot auctions. The fact what I was trying to mention by the way was essentially a just in time slot auction.

Yeah, just in time slot auction got killed because of that because the proposer would just delay and just sign for himself. Um the construction that I was trying to mention though, the proposer has no incentive to delay and can't pick himself because he can't. That's why he doesn't have his incentive. The the the this strange execution, I don't know if it still runs into your fork choice thing, but it was just a way of getting a low latency random number generator where basically the proposer has like everyone contributes to entropy.

The proposer is the last one to reveal. If he doesn't reveal, he misses his slot. But he would need to collude with all other builders. And you could even mix it with entropy from other beacon blocks so that he would have to even collude with other proposers in order to try to bias the entropies for who wins the auction. But basically his reveal also picks the winner of that of said auction from 32 slots ago. And he can't make it himself automatically. out without getting collusion with with multiple parties including every builder that has bidded on the ticket and presumably other proposers too because you could mix that entropy in there.

And you could give a slot auction because he can't like he can't pick himself. Um okay. uh we should probably bring this into it research or yeah I mentioned it discuss this at a research level I I don't I don't really know I don't know how to solve for choice and as said I don't know how to implement any any sort of auction in advance okay um like yeah I'd like to see this in more detail perhaps but yeah so It feels like

these I mean these are just ideas for um because all of these are seem to be floating around a lot right now. How do all these interact the the various mechanisms? So, so uh action action items items for us uh besides um we committed to having next week images at least prism and probably te the endpoint and Rico committed to the to to put them in the in the in the API repo. We we can actually implement them.

I'm hoping to implement them this week. Uh and regarding pre-confirmations, I think as an auction item, we can take uh either talk to pre-confirmation teams um and see uh where we're standing what what could be a possible blocker last time I contacted them. I I think I made a mistake of contacting builders who would be uh pre-confirmation gateways and for them surely there's no difference with the PBS and and these conditions. But uh a poll from Lighthouse also pointed out that it might not be good for gateways that are not builders. Uh those gateways might be

not benefited by EPBS. And I don't know if you guys have contacts of these people, but I think it's probably that's a good action item to mention this thing of the black time that Mark described and talk to them and see if there if they see a blocker for a PBS. Uh somehow so far I haven't seen it as a blocker, but I I'd like to understand it. Um I don't know if there's any other action item that you guys can think of until the next call. Also trying to get in touch with ETH research to understand more about how

these things interact and what they are or what they know about them because a lot. Yeah. So I have talked to EF research quite a bit at the design state of EPVS. uh there's a huge gap between what's research and what's implementable and at some point I decided that uh this is something we can implement in a safe manner today and it doesn't need more research.

Uh so I'm happy to implement anything that is safe. If there is a better design that is safe, I'm happy to implement it. But uh so far I haven't seen anything like if any of these if anyone does solve execution tickets this will move us closer in that direction just even just separating the payload and the block which is actually a lot of work. So correct that's that I think is my objective and if someone solves the auction mechanism in the meantime that's fine. We can just quickly change it.

Um, all right. So, if that's it, we can probably close here. And so, hopefully for next meeting, we will already have a two client Corttosis run. Is that correct? Uh, Enri Stefan. Uh, yeah, seems very possible. Yeah. Yeah, it could be. Okay, perfect. So, so that that will give us a dabet. I think this is this is good news. So, for next call we're going to do this uh yeah in in so in the next two weeks that's our objective to have a two client cortis run. Perfect. And we we might even get Dora to show us the

blogs. Perfect. All right. All right, guys. Thank you very much. Thank you all for for coming. Thank you, Mark, for describing this issue. Yep. And I'll see you in two weeks. Yeah. Bye, guys. Bye. Bye.