ePBS Breakout #3

Transcript

okay I think it's good to start anyways uh I have a very short uh agenda which is just informing of lack of progress I took Vacations so that delaying the the IP but I am now full steam again at it uh I am supposed to either uh one of these days uh pull up at least the open the new PR for the consensus repo everything is ready my biggest problem is that I'm rebasing on top of the latest elect and the changes on Electra are causing me trouble on on on epbs so for example the consolidations went out of the Bon block body and are now in the payload and uh well anyways changes like

this are are are like not easy to to keep track of on the way that the consensus repo works because we need to come up with a full new folder for and to make it executable uh some things are actually easier for example because of the changes in Electra we don't need to um to change process attestations we only need to change like get attested indices and that makes it I mean it's it's nicer because you don't touch process tations uh but uh so you only touch get a testing indices to not return the PTC indices but um but at the same time you

need to be keep keeping track that at any part in the in the in the repo like the from phase zero we're not calling get a testing indices and something might break because of this uh so I'm only like uh checking but it should be open soon and that's my only update um can you clarify like what like what you will be opening so let me just say so correct me if I'm wrong you have a consensus spe which consists of port chice validator P2P and then the main consensus Beacon chain one and then there's also an engine API spec as well and that will probably be a separate go ahead yeah so

I'll open so I won't even open the pr I'll open a PR in my own personal uh that it's only going to be so I'll move out some files that we kept many files in the same uh consensus for for reading purposes like if you look at the pool request number two you're going to see that like the the engine API and everything is there in that in in the consensus of my clone so that's not going to happen in the new it's going to be something that actually is going to be eventually open in the main consensus repo but I'm only going to open it there so that's going to be beon chain validator onest validator onest Builder which is a new one um and then uh P2P

changes and for choice so that's going to be very very soon like in the order of dayses uh then the next one is the engine API which I think doesn't have many changes uh we might want to add new methods but that's fine if it's not completely ready by the time we open the iip uh but I'll open anpr in the respective uh repo for the engine API uh I'm not sure what to do with the builder API I think what has to happen is that uh the engine API is going to be taking all of the Builder API methods and uh that shouldn't take that long and then the the one that is problematic because I'm not used to it

is actually open the EIP uh PR which uh which uh might from a GU already light llies already trained me uh and it seems to be easy enough but I haven't since I haven't done it before that might take slightly longer that's awesome and there's also the execution spec which I don't believe there's any changes for the execution there's no changes at all so there's no need to touch the execution spec one thing prot I noticed was that in your current uh epvs PR PR cons in your own repo uh there still mention of

uh inclusion list so is that going to stay because uh no going to go no so I'm going to open one without inclusion lists uh and uh yeah so the pull request is going to be exactly what is in my repo uh without inclusion list but then with all the elector additions so yeah so inclusion list is the biggest complication of that PR that is in my ripple if we remove inclusion list the pr becomes purely a consensus layer fork and it's a trivial Fork if ACD this size that they want to go ahead with like 7547 that's absolutely fine this this put request is this CIP is completely

compatible with that but it's fine if it's an independent uh EIP so I think it's fine not to include inclusion list in this EIP uh also because there's other methods for inclusion list and also because we might want to have I mean we keep the ability of self building so it is logically an independent VIP right right I think uh yeah it would basically make this VIP very crisp if we sort of separate them out another thing that I noticed P was that uh in the execution pad header so instead of block cash of payload can we keep the Merkle uh Merkle root of the execution

payload I mean should we have that because uh uh I mean if for example execution payload is no longer part of beacon block then basically possible it's not longer possible to sort of have a proof against the current attributes of execution payload against the beacon block I'm not sure which apps use it or are there any use cases for it uh but I mean it yeah someone should take notes for this yeah I'm taking notes go ahead and it might also be mood point if we sort of also get to stable containers but in any case yeah we should sort of

keep keep track of this at any point uh whenever this goes in uh the instead of just picking up the block cash from the execution payload if we can sort of keep track of M hash of the execution P that would be nice in the execution payload head so I don't see any reason not to uh I I'm not sure this depends I guess on on on the ux of this um if having the block hash itself makes it easier to pick up what actually was the execution block that was assciated to this uh to

this uh particular slot and the E keeps tracks of block has you can request only by block has not by by hashery root so I suspect that most proving is done on the El side uh so I I suspect that the consumer of this would be people that communicate with an El Bon node and with a Neil node not with a beon node so I'm not sure if it's more beneficial to have the HDR or the block hatch uh we should ask people that actually use the chain yeah yeah so again I'm also sort of not fully aware what the use cases are uh but yeah I mean there potentially could be someone on the Bridges trying to prove that this transaction was included

in this particular beon block on I mean that's what I can think of okay I took a note on that go ahead sorry yeah there's some there's some another observation regarding the the execution payload header if you noticed I removed it entirely like I transformed it to not keep track of anything like that's what is there is just the minimum information that you need to actually be

able to process the block uh uh I heard Alex Stokes complain about this that light clients might use it but then I heard people that are actually working on light clients is telling me that it's useless that there's no use for it uh so I am keeping it like this but it's good to keep note uh that there's no use currently on the of the on the execution payload header so actually I don't even understand why we keep it now we could just currently it seems to me for all the purposes that we have on the Von chain we can replace the execution payload Header by the block hash of the execution payload and everything's going to work fine so uh well anyway so that's uh

that's one extra observation that if if we can minimize it or not because if it is a blocker then we need to go back to just keep the full payload header or we can keep the Merkle root of the latest execution payload error inside instead of lat execution payload I mean that way basically whatever the attributes are you would be able to link it to the we block so there are there are a few there are a few things that we actually need to keep so we need to know the parent so we need to have something that identifies the the previous block which you're suggesting is the HDR or it could be the block hash it's fine like anything that identifies the parent block on the execution side but there's

other things that we need to keep them uh we need to keep the The Blob KC commitments we need to keep a bunch of things uh that are in that header so so it's not only we cannot really just replace it by just a a single root uh currently we can keep it by a single Ro root but on epvs I don't think we can just replace it by a single route yeah I I've had this discussion with Eon about uh regarding the light client and obviously he's one of the main people working on it because he actually asked me whether I thought that there was anything that and I wasn't I didn't think so at this point either the

pigo header as a whole um the there there were use cases around the merge um about distinguishing basically essentially there there were some checks for what what did was it was the previous block payload header the default payload header or not because default meant that you were pre- merg um but we don't care about pre merge anymore not certainly in any PVS world so it was NE it was not that it was useless from birth but it is useless now as far as I know good that's reassuring actually yeah Ethan was the one that told me that I'm sorry that I'm putting words on you Ethan I see that you're here but yes Ean was told is the one that told me

that we could remove it so so I'm happy to keep the pr as it is now I promise this meeting was going to be very very short so I'm hoping that the next one two weeks from now is going to be longer because we're going to have at least something out uh so that that's all from from me I don't know if anyone has other items I have one topic on um Beacon API which I see there's bunch of people that's working on Beacon API here so I'm curious for your feedback So currently we have this like weird asymmetry right because of the two consensus block contains the payload but you don't want to store the payload

twice so you have your consensus block with the payload on the consensus side but but on the adittion side you still have to support RPC Endo to get the execution so typically how it works is that on the consensus client we blind the payload and then if user request the Bon block we will try to get it from the execution client and then un blind it and then return it right so it's kind of annoying to do that so on the so um epbs is nice in a way that like consensus and execution are fully pipeline so by default a consensus block is always a blind block it always contains the head

header right so when you request a consensus block you don't need to unblind it anymore you just ref the consensus block as it is and now blah blah blah and now the problem is that okay um what happens if the user requests an execution payload uh um from the from the client actually let me share my screen and just look at the um let's just look at the um po spec it might be easier to go through this see okay so you can see my screen I

presume so basically in P epbs today there is this adittion payload envelope and uh you can ignore all inclusion this stuff because that will be removed right so this envelope only includes the payload the Builder index the Bitcoin block rout the block casg commitment and whether this payload was withheld okay and this attitu payload we know it can be retrieved by the addtition layer client so that's good we don't need to worry about getting this so we can all agree that we don't need to return this from consist very high right so I think the only thing that's really useful that people might want to know from the

execution payload is whether this payload is repelled right besides that I don't think there's any reason that we need to have a separate endpoint to return ation payload envelope we can just given a slot or a beacon block route we just return whether the pay was withheld or not and that's it do you guys agree with me here so you're saying that we are the beacon node will will no longer expose anything about the execution payload and it will become something you will have the header that's it yeah yeah yeah but in terms of how do you get the state

route how do you get the state route I mean there's an actual State transition out of that envelope oh okay yeah so you can return the state uh yeah so I guess you need to return the state you're right yeah yeah forgot yeah so you need St rout and then whether the pillow was withheld those two well in fact if the state Ro is different it means that the payload wasn't uh actually I don't know no both of them would change the state yeah yeah so my question is that I really don't want to have to design this in a

way that I still have to get the payload from the execution their client that's the only thing I want to avoid like I think that just annoying to do that but I don't so so I mean we are just we have a new endpoint that just Returns the execution payload envelope and it just gives you blind that it gives you the ex instead of the payload it gives you the block hatch right yeah that's you can do that you just request you can request from the the the corresponding block yeah yeah yeah yeah we can also do that as well but the question is now you you have to define a new type you have to Define this new type that's called execution payload that only contains the block hat not the payload itself so

there's this new type oh I see and then what's the problem of keeping the current functionality it wouldn't be be easier for the consumers today not that I really care about any of this but uh the consumer today doesn't it require the full blocks from the Von uh will they I mean suppose that they have some architecture where their El is hidden from the guy that is making this request but the CL is not and and then they channel the cl to the L somehow so they they request the full block currently from the CL uh wouldn't we be breaking that setup by having them expose their client to

actually call directly the Y yeah that's why I don't know that's my that's my point I mean this is not not not a technical thing but do we want to the big or not to continue being kind of a a proxy for getting all the information throughout the the El itself and maybe we could have an dedicated uh API engine API that also Force to to get the block throughout the engine apis yeah my instance here is that we we shouldn't even worry about any of this this the EIP should be put out with the simplest possible design and obviously the simplest possible design is to return the full PID all envelope not

Define anything new and I don't care about implementing this I won't even implement this at all so why yeah I wouldn't worry about this until this is decided to get in or not yeah yeah yeah yeah that was just a question so yeah so sounds like to me we can just keep things as it is and if anything we can decide later or just retrieve the payload from extion ler client right and um let's see another thing is that when you get a state can we assume that we will always return the full state if the food state is available for example say today if the slot is full you will always return the

full State I mean users shouldn't have the option to get either the full state or just the consensus state without the payLo that's process right because there are two version of the state in the middle I I don't understand so what's the call the call on the be you're talking about the beon API to get the full State the beon state to get yeah it will always so when you request the beon state right uh the state for head would be you you're going to choose full or not according to what's your head so that there's no question there the question is if you request by slot right uh then again I I'm not really worried about any of this but you could imagine that you have slot and the pair

Slot full slot not exactly yeah the question is do we need to worry about that but it's probably too early to worry about that you're right whether you both States I'm sure that if there is a need to get a stage for a particular slot then there's also a need to get both of them the full and the not full why would people be interested at if it's always if if it's full right that's that's my point it seems like to me that we should response is full when it's full and and exactly that's why we we keep both in the four choice but return what what the best of it the best is the full one yeah if is full otherwise is empty I don't see why would you have an

endpoint that actually hides information I mean when you request the state you might want to get that particular state right otherwise no way of accessing that state so you basically want to have a slot and also have a Boolean flag that basically say whether it's four empty and then or you just have two different end points like pre pre pre payload and post payload because anyways you have two states so you will have two states it doesn't matter if it's full or empty because if the payload is withheld you also will have a different state transition right right right so the question yeah so the debate here is that like is the empty useful whether we need to provide it but sounds

like yeah I don't think we're coming to agreement in this meeting and I don't think going yeah but also also I'm talking and I said two things that are actually wrong uh when the payload is withheld the state TR is kind of irrelevant right yeah so uh when the payload is withheld the the the the state rout is is kind of irrelevant and then you don't process the I mean when the ba load is withheld the Builder is hoping that the block is going to be reor anyways so we don't really care about that State Post withheld payload yeah exactly to me this is an internal complexity that could be high

hidden through the API and we could have the bug and point like which historically is today to dump everything and still the bug so we could have the bug GRE to point or this information could be dumped through our end point that dumps the fork Choice um um tree and we could we could we could uh expose this information this internal for Choice information throughout that that that end point and hide this this complexity through the apis okay that's all my questions I mean yeah but probably too early to really go

over this in detail one small net if I can just point out maybe we can use optional for the execution payload over there instead of having a payload held if it's n then obviously the payload was withheld [Music] and oh definitely do we have optional already in ssz I don't want to to make this EIP contingent having something else being included in the in the spec yeah I mean it's not right so if it's there then it's an easy change to add it and and then I'm happy to add it but I don't think we

have optional in our yeah it's there in the sense that stable container uh EIP uses optional and uh yeah and it's supposed to go to yeah but we don't have this yet so then I I don't I don't I I won't be able to have a proof of concept I'm I'm happy to add it and and yeah so we should take note that it's better to have the optional for the withheld payload U yeah we can go with the Union kind of a thing right Union man with a a union type no but it's fine if it's optional because if it's there for in the stable container we can have

it and and then the Builder that is actually withholding may just not send anything in any case the Builder can always just build crap and just send frap in that execution payload because the payload is completely ignored yeah or just can a default value nothing to build at all yeah so yeah the way I was going to implement this in the proof of concept is that for the withheld the Builder was going to build a a sort of like an empty block like an empty object that satisfies the serialization but yeah I agree that optional is is better it's definitely better right uh I'll agree with that but

I also want to point out with a with Union un Union is one of these things that technically exists sort of maybe in in the ssse spec it is not used it has never been used and I would actually very much like to keep it that way because right now we still have the opportunity to get rid of it with to actually simply remove it because we've because we have ever used it except for like three Alpha releases in 1.3.0 or something like this and and um because an opt is better uh for for generally speaking so um so I'd like really specifically for this not to be a trojan horse for for a union is personally uh anyway

all right uh I'm done Terren seems to be done you guys have any questions this is a good time otherwise we can close it in less than half an hour which is a very good thing and in two weeks I hope that so for the next meeting I hope that the E is either out or or at least every component is already public one thing I want to clarify is that if the payload is invalid is the corresponding weon block valid or that becomes invalid so so when you so the Bon block has a uh completely independent state transition

function and it requires that the execution payload header is valid so if the execution payload header which is signed by the Builder uh is valid then the beon block will actually be sync and all of the changes will be committed to the beon state whatever happens later is completely irrelevant so if the if the payload comes in and is invalid then that payload will not be uh will not be synced so the state transition will just not be touched by that payload but the Builder already has paid the value when we synced the execution p header so the that block is going to appear as

something that we're calling empty so it's not skipped and but it's empty got it got it so basically it won't get any withhold boost it will so yeah so so the the the Builder boost are applied only to payloads that are uh valid or uh valid withheld messages that on top of that the PTC has achieved some consensus so PTC only applies to give you this boost so what what you do is when you're syncing something you check okay so I have this payload I've checked it uh and

you only need to do this at attestation time so when you're attesting which is like about in the happy case it should be around 10 seconds after you received the payload so only then you check well I received this payload I don't care if I received it timely or not I just have this payload is valid and the PTC told me that it was timing so in that case I say okay so it has a boost so we are in the world where PTC votes only for timing and not doing the validation yeah so I think this is the biggest gain of the CIP so it's even better than than epbs itself okay yeah so it's perfectly exact exactly the same as withheld in terms of

a user that looks at the the chain and sees that the beacon block was having a block root a payload payload HH that is not zero but never showed up no so that's different so if the if the the beon the beon block came with a commitment to a payload so to a particular Builder and you haven't seen that payload so you haven't seen a withheld message it doesn't matter if the PTC commitment PTC committee told you that that message was withheld you will just treat it as a no-show so the difference was that you got some uh you

got the vote from the PTC in that case but the so so it's not withheld but was not imported anyway right so this is this is important and and and this should be checked because I'm not really sure that I coted that correctly on the for spec but that but the intention is is exactly this that you act you give a boost or not according to the PTC but after you validated the payload so if you are going to give it a withhold boost you must have validated a payload that was a withheld message so PTC just gives you timely but the the Boost is actually on your side still after you do the full valid ation

of the execution layer of the exactly exactly so so the the PTC just tells you you should apply a boost if this is valid yeah if the PTC show up with with held you you you don't care the Boost will not will not be there anyway no no yes because so thec votes for withheld I'm sorry yeah yeah so so if it's withheld then the Boost is applied to the parent uh the Boost what so if it's withheld uh then the Boost will be applied uh to the parent that's correct the withhold boost would be applied to the parent block route but then again you need to have a

valid withheld message so you do care that you actually have a valid payload right so the PCT Miss PCT messages gives you tells you to which uh block you want to apply the Boost correct to which uh yeah so to which uh State yeah yeah the pre parent one or the current one yeah so P one other question if for example the proposer has seen the withheld message or the payload message but PTC has not seen so you don't have the threshold for PTC boards yeah uh then how then the proposal will

treat it as the proposer so a malicious proposer can actually exploit this situation this is essentially a split view on the sptc so if you're a malicious proposer you can actually exploit this by saying ah this I cannot give a boost and if if if I see that other validators also haven't seen this uh are in this situation then other validators will not boost the payload so if you're a malicious proposer and you hold a a large malicious stake then you can actually exploit this to reorder that pay that you've seen uh so that lowers the threshold of malicious state that you need to have to reor the to reort the

payload however uh the of course the Hest validator the honest proposer that has imported the the payload even without a boost that would be its head so even if the PTC hasn't achieved consensus if you're the next proposer and you sync the payload and the payload was valid that's your head so you're not going to reorder the payload I don't know if I was clear but I I can repeat slowly I mean right so basically you are saying that if even if I have not seen even if PTC has not told me that it has seen the pill I will still import it in my Fork choice and make it my head and propose

on top of it yeah so what you would not do is give it a boost because the PTC dictates what gets a boost but even without the Boost that uh that thing extends your head right okay so so the PTC V are PTC scene votes are only to give the boost for the head or for the parent if it's with held for example uh but apart from that it will not invalidate the tip it will not invalidate the tip that's correct so if if the PTC votes for

withheld and you're a malicious proposer and you anyways build on top of that uh well suppose that there's an equivocation which is even easier suppose that the PTC votes for withheld but actually the Builder has sent has sent two payloads and one of them is actually valid and the other one is the withheld one and you're a malicious proposer and you propose on top of the valid payload then that's fine uh everyone else would try to withhold it because they PTC voted for withheld but your block is still valid they will sync your block and that's that I think is fine there's no gain on this kind of

attack uh I've I've gone through all of these cases and I think there's no no attack in this scenario I think there's no attack on equivocations on the building Builder side that's why I believe that it's also easy to actually do slot auctions instead of block auctions for this okay one other question uh I saw in process attestations uh that if uh if the attesting indices were in uh belong to PTC they were not sort of being divided over there so what is the thought process behind it I'm sorry how is

it what was the question so basically I saw the pro process attestations if the testing indices belong to one that was in PTC MH they are sort of not rewarded I think yeah so what is what is the thought process behind it oh so uh again this is just for Simplicity in principle what we should we could do is remove completely this adders from the committee so when when you get get give me the beon committee to remove those from the PTC and then change everywhere in the spec uh that uses the committee so for Simplicity I went through with a

design that is hacky so perhaps we can change that which is the committee doesn't change it's just that the last few members are PTC members and so when you call to get the PTC what you do is you call the committee you get the committee and just take the last few members so that that's that was the easiest way of getting the PTC committee without like having new helpers from the state driving a new shuffling or whatever it is to get this members so now the problem is that the PTC members are also committee members by definition therefore they could in principle attest and not send PTC votes but the

PTC reward is only an attestation so then that that gives you bad incentives in the sense that you can just attest not do anything for the PTC not care not even listen for payloads and you're going to be rewarded so the idea was well we're not going to include any attestation from the PTC member so they don't get the reward they get a missed attestation by default unless they send the PTC vote so when you process the PTC vote then you reward them the attestation uh honest clients like vanilla clients should not allow PTC members to attest understood thanks thanks a lot I I have a a question we've we've

started getting um about uh questions about pre pre comps and and and that's a broadly different topic I understand not but epbs obviously has potential attractions with this and what my question here is as we Nimbus start hearing from people about prec comps and what and I I personally want to make sure that that Nimbus doesn't actually sort of uh start you know uh aligning with anything that pushes against epbs because I want epbs to happen so what are the the characteristics of pre comps that work with epbs and and don't to to to I

posted I posted something on E research uh I don't know if you've seen it dusting uh but it's not something which is uh of precom itself so the things that clash with epbs are things that on protocol require the payload uh to be present at the time when you process the beon block that's by definition something that would break epbs so if you require the payload to be present then that's that's really really bad and we cannot get away against that so anything would require the payload at the time that the Bon block is pres is processed uh completely breaks epvs uh yeah so I I'll find the link in

a in a second uh but but with regard to your particular question the uh it depends on what you want from epbs and I think that the biggest selling point that we have for people that don't care about epvs but care about other things uh one of the biggest uh improvements that the CIP brings is this thing of like the validation time being much longer so instead of having two seconds to validate everything you now have like N9 seconds to validate the payload or data availability for Pras for example so if you don't want to break that then you don't want to overload the beom

block because the beon block happens to be now the critical time beon block has only like one to two seconds to be to be validated and if your precom is in protocol namely a force inclusion list like many of this uh many of these uh uh mechanisms rely on something like 7547 overloaded they say we're we're going to have a market for inclusion lists and that's going to be the pre- confer is going to force the proposer that is participating in putting transactions in the inclusion list and then the problem is that for that you need a big block a big consensus block because you need to validate the inclusion list with the consensus block so anything like this

which are in protocol precom that overload the Bon block and it makes it larger and it makes it that now you need to actually execute on the Bon block as well then that that breaks that's in contention with DBS uh so if you need to validate some something from the execution client at the time that you're validating the consensus block that is really a contentious uh this is contentious with epbs but it's also contentious today like without epvs is also bad like if we send now an inclusion list that is like an entire block then you need to like validate two things with the block okay so so that's I think is the

biggest thing however I believe that the best designs so I've been pushing for this but I haven't been vocal about this because I also don't want to legitimize proms in protocol PR proms are an by nature of protocol design and I think it's fine if we keep them off protocol but I think epbs makes them easier because you can enforce the precom uh you can enforce the precom uh satisfaction on the Builder instead of the proposer so if the Builder is State this should make the people that are working today on proms happier uh so that's my take on pre but

it's Justin uh Drake does not uh does not um share interesting um all right right well I mean that they said they had actually spoken with you specifically um and and that about and basically said that they reported a a claim of compatibility and it sounds like for for these particular for the and they were one of the people with a not in protocol version um that was one selling point so I've only said this personally to one team which is the team I think it's chainbound uh the prf

team that uh that have a restate version yeah anything that is restate is completely compatible with epvs okay okay so they're the people were kind of uh who who kind of f first approached us um and so okay that's that's all right good so I haven't I haven't read the way they enforce them because if they require from the proposer uh to to actually sign the payload then that's also but I think it what they have I think is compatible with with the PBS in in any form right well what they have is an oracle ultimately and and and they have other problems with their design but I mean like that that's a sort of separate

Topic in a lot of ways um but but I mean I I want but as far as um all right I but at least understanding that that that and will be the post all right yeah I actually think that unless they come up with different the thing is that they they're forking me boost so if we remove me boost uh if we remove me boost from clients they're going to have to come up with a different way of of of getting the proposer to interact with their system um but I claim that uh that we can do this all within the beon API or the engine API within epbs without any dramatic

changes so I don't think this is the biggest a big problem unless people want to have in in protocol preons which is what Justin wants like there's a bunch of people that actually want in protocol precon and that I think is bad that that I think is not compatible with anything right I mean there's a sort of set of broader questions here which I actually sort of deliberately been trying to kind of not get too too too much into but but about skepticism about pre- comps along the lines of Mev is sort of Mev part two Etc in terms of rest of the world wants it is it good for L1 etc etc but these are all sort of questions that are not but

but right I I I'm not personally inclined to like love free comps in L L1 and any intrinsic way um but I I I don't have strong views yet on it either way I just want I mainly want to in this context sort of ascertain about the the compatibility put it this way whatever one there's a big maybe maybe to try to keep it on topic here and and relevant there there's a there's a broad uh design um space for for pre comps uh there are many people suggesting there's whole whole periodic tables of of of precom designs and then you know all being systematically explored all right that's fine that's great um and

and what the but also as a result it's still a sort of very much researchy space as you say Mev command Etc the are ways of either deferring the need to standardize or it's very clear standardization is a ways away there's no EIP coming anytime soon it's not going there's nothing like that so if we want some anything in protocol um it is anytime soon it is not going to be precom one way or the other whatever Justin TR wants um and so and and EPS has is both a much more concrete near term and specifically L1 advantageous set of changes um and and that and so in terms of the prioritization that I'm

looking at is sort of pre-com out there I'm willing to engage with them and look at them and I just want to make sure that it doesn't kind of undermine like something that can concretely help ethereum much sooner um so the the fear my but this is a personal fear the fear is I mean these are all VC backed companies that are competing among themselves like to to come up with with a particular design that wins the market so what they want they're all in cap their business is in capturing proposals so if if it so happens that one of them actually wins and there's a very large and this is going to happen fast because they're all competing among each other

so so they have an incentive to ship this immediately and they don't need to go through ACD nor to go through anything they can just ship it they are already testing on devet and there are some people that are actually shipping blocks on mainnet with with prons so so this will happen in the next few months and if we see one such protocol that takes a large part of the validator set then this undermines epvs in the sense that we will probably break it uh if we if we break their setup if we ship clients that lose uh this me boost uh the interaction if they lose uh the support from clients to how to

interact with this me boosts then we're gonna see a backlash we're gonna see the community say no we don't want this so that's my personal fear but this is just more politics than actual protocol design so I don't really care about this for for the time being right although it it does suggest do you do you think from that perspective there's a relevant timeline difference in terms of um pectra or or or fstar uh and I mean I mean pectra is kind of a um a long shot anyway but but like there there are some proposals and I I know there have been discussions on the SSD side of saying there's something that are like well if we don't get in

now fstar is going to be a really really hard push to to get in um because of fle well on the El side for example is there are is this something that you're concerned where there's a decent chance that it could pectra is soon enough but that if it waits till fstar then that's it it's probably going to be too late because of this that's that's my biggest fear uh I'm not sure I mean I would have I would be in a very completely different situation if every client already had branches and they were working on AAL concept but as today I think only prism has a branch that is working on coding upvs so so it's useless to be talking about Forks without the clients implementing anything if we are in a situation where

every CL client this is only a CL Fork so if we have a situation say a few months from now that every CL client has a proof of concept then the talk is going to be different but as of today it looks to me like a rise on time uh but also I claim that for pre-conference module of this fact that you capture a market the best design actually is easier and better with epvs than without it so so I'm hoping that they recognize this it's just that they are now building on top of a non-bs word and I understand them right because well they they don't they they they need to build for now and there's no epvs now so if they if they were

building on top of PS I think their design would be more robust I'm hoping that in a few weeks when we get clients with branches out then the talk is going to be different yeah actually and Prim was telling me that from their perspective that they actually agreed with you on this point that they thought a PBS uh world is better for them specifically which is not to say necessarily for all the pre confer but but they specifically would would I think yeah so so that they are design is would be so the design that I posted on E research is very much

like theirs uh and it becomes much easier because you only need to restate the builders so it's much easier to capture builders that participate on that so it's for them their design is very much compatible with epvs in that sense and I think for them to change it if they are the winners is easy so I don't know about others they're all centralized one way or another that's the the biggest problem they all require a relay that's preons for everyone yeah yeah I I had this discussion with with them a bit I I there there are concerns um there but uh I think in this context the main thing

is like just trying to well and this is kind of why brought this question here sort of is given that pre-ms are seem likely to happen there's a a big enough push for them whatever anybody else thinks uh same way Mev was pushed basically from the outside and and so is this and that's fine they both would happen and did happen will happen um but if what we might be able to do is try to redirect um the ecosystem towards some pre comps away from others that that that still might be uh and and if that would kind of into in a a way that leaves space open for you PPS yeah so I I'll be worri about like making protocol decisions that are based

on affecting or not these companies so so far I I think it's fine if we just have a design that we know it's not open incompatible with precom and if there's some design that is actually winning by the time that we come out with an EIP and and and and client implementations and that winning company is openly against ppvs or it's openly broken with the PVS then we may have a talk and see if we can adapt the PVS or not uh so far I haven't seen anything that is immediately except this thing of like having full inclusion lists like block inclusion list that are just of the size of the block that is

definitely against CBS but I haven't seen any any such thing being proposed at all so there's there's not even a push for inclusion lists currently on L1 so so I don't I don't see uh this being a problem for now okay yeah again I'm I'm I'm not the right person also for politics so perhaps someone else would be more qualified right right it's not it's not my my um primary strength for sure so yeah I've tried actually I've tried to do this i' I've I've pitched flashboards and I've talked to Searchers and but

yeah I'm not good at this all right but but yeah all right it's good if if if you have if you talk to these people if anyone in this call talks to the pre-conference it's good to have this this in mind like how the things that would affect the PVS is how does the proposer get the list of transactions that need to be included in the block uh can has this does it have to be enforced at the proposer level or can it be enforced at the Builder level if it can be enforced only when the payload is uh is revealed and the Builder is the one

that can be penalized instead of the proposer then this is not only not incompatible with epbs it's better for epbs to be there for them so if they insist in penalizing the proposer for something that is not the proposer fault like the Builder not revealing the right um the right transaction set then this is something that would be broken by epbs because if you penalize the proposer and then suddenly the consensus block doesn't have the information that you needed to penalize it then such a design would be broken if epbs shits and such a design would be against epbs so those are the questions that I would ask the pre pre-conference so I think no design is incompatible with the

PVS but all of the ones that I've seen would have to change with the PVS all right also if you if you do start implementing I think the one that have been looking the most to fortras is enrio so it's a question for you keep in mind slot auctions and let's try to analyze the safety of it because it seems to me that it's easier and better I think slot auctions are better than what this EP IP is and it's easier even so so the question is a safety question so if we can ship slot auctions just from the

start I think it would be would get better adoption from Builders uh oh wait we are BL what is it ah speak up I I can't even read this there's someone that is saying something about oh this is so's book perhaps no who's P new inclusion is designed for L1 soon for what is what who is this I'm in the airport so can Bly yeah so it is this thing of like we're planning to push a new I

design oh yeah so oh this is the one uh the four Choice inclusion list so was just appeared in in research yeah okay good yeah that that design is actually good um uh and that one might actually I haven't read in detail but that one might actually be compatible with PBS without a problem U because again you can only you you're looking at aaster and you can just if I understood correctly the ATT testers are the one that enforce them and you can just enforce them in the next block so that's uh that I think it's in principle that thing is probably fine for EBS yeah yeah you're not going to get an

enemy on on me uh with that design I think but I need to I need to study it I haven't I haven't started comp all right we ended up taking the full hour anyways all right guys there are no more no one has any comment we can close this on the hour and I'll see you guys in two weeks hopefully the I will be out or soon to be out okay bye guys byebye bye byby