ePBS Breakout #10

Transcript

so welcome to uh the breakout room number 10 if I'm not wrong we essentially have nothing on the agenda so let's kill this meeting quickly uh there were discussions so let's get to the to the only main point which is there were discussions of moving the withdrawals uh to the payload to so that we can process withdrawals on the payload and we don't change anything but there's a problem if um so the withdrawals are of course they're deterministic on the beon state however uh if we do block auctions then with and withdrawals being

part of the block hash of the payload then the withdrawals should be that that will be included in the payload would be deterministic on the beon on the pre-state of the beacon block the beon block would Comm would commit the hash of the payload now what happens if between the payload being committed with this number with this withdrawals for the pre-state of the block and by the time that we're actually processing the withdrawals the expected withdrawals on the beacon states are different this can happen for example if the beacon block penalized or slashed one of the validators with was withdrawing in that very same

block so this seems that for Block auctions this is a problem that is very awkward to solve because either we make withdrawals being deterministic on the pre-state of the payload in which case you cannot commit the hash to the payload itself or we do slot options and I don't see any clean way out of this so my suggestion would be just to keep the spec as it is because it works um I hope that the explanation was clear on what the situation is I don't know if there's any comments

uh yeah I mean not against what you said I'm just trying to understand the scenario but I suppose I like um so the yeah I'm just trying to find follow dependencies sorry but oh the scenario is actually very simple you don't need to slash or anything like this so so the the scenario is this um uh we we are about to propose a block we call uh for bits we get a bit from a proposer the proposer has already built the block right so this proposer includes some withdrawals let's say 16 withdrawals now these are and these are what kind of

withdraw like these aren't we're not talking about withdraw requests we're just talking about yeah this is nothing to do with requests so let's say that these are partial withdrawals the next 16 validators what you're saying I want to be clear on what you were saying yeah so so let's suppose that these are partial withdrawals okay that's what I mean uh so you when you say includes withdrawals you mean including partial withdrawals like yeah withdrawals that were made as transactions no no these are withdrawals that uh that were paid in the payload to the corresponding withdrawal address the ones that are happening right now before electr the accident on top of the 32 eth

that they deposited right okay but it basically what I'm saying is it has nothing to do with the transactions that were included in the block yeah okay okay so they're just these are the special operations in the block oh the the special oper like the ones introduced in Electra the ones introduced in uh capella capella okay okay that's what you mean by special operator yeah I'm just trying to get clear on what the okay so nothing to do with the transactions just with regular withdrawals okay and then what what's the scenario so the scenario is that well this these withdrawals are there they are in this pay would owner would would actually credit if on the

execution layer to the withdrawal address of say validator one and now the block right that includes this payload exactly that validator one was a validator and it gets penalized the balance during that block of that validator changes for example the validator itself is the proposer sure so the balance of that valuator can change so now when you call Process withdrawals if we want to keep the process withdrawal just as vanil as it is process withdrawals would get the expected withdraw from the beacon State at the current

moment mhm and this expected withdrawals is now no longer the pre-state of the Bon block is the post state of the Bon block I see and it might be different than the withdrawal that actually were included in the pay right making the payload invalid exactly yeah and then I mean then that just causes a a Miss block but then but the the point is that basically the propos like either the the Builder would have to have some extra logic to make sure that this is not going to happen or I I think it's impossible right because the the or we

change the the logic on processing withdrawals but I think it's just impossible to solve with a with committing the withdrawals to the block has hat a solution would be to not include the withdrawals in the block has but I think this break sync yeah okay so yeah so I I think it's I mean we can revisit this conversation if we move to slot auctions because this is not a problem in slot auctions we can make the withdrawals being just the pre-state of the payload into slot auctions without any problem right but we wanted I mean we were leaning towards block because of that other presentation two weeks ago or at least that Julian sort of like killed

the topic so it's not really clear um there are I don't know if franches is here he doesn't seem to be here so franches is working on an alternative approach to epbs which is promising and uh we might not have these problems uh in franisco approach but I don't know it's it's very just too early to to think about this so my suggestion would be let's try to keep implementations uh as as they are now oh I see I see why the Builder okay yeah you sorry that was still turnning in my head but the Builder can't prevent this because they don't have control over what the proposer does exactly

okay all right that's that's essentially all all that that it is uh I regarding this spec um I were in the same spot I haven't rebased yet uh the the testing PR on top of Lucas's PR I just repaced prism implementation on top of Lucas spr the one that removes the the requests out of the of the payload and puts it in the Bon block body so on PBS they're going to be on the on the payload envelope and this was a nightmare for prism but I think we are the most advanced in the implementation so probably this is not that much of a

problem for you guys but if you are implementing then this might be a problem for you as well for us that rebase was was an item wh which rebase sorry well we had already implemented a bunch of the logic uh of using the requests uh being in the payload you're talking about that's all yeah and then you need to remove them from the payload and put them in the payload envelope and and that was yeah I missed I missed which PR you were talking about oh so this is Lucas's PR let me just find it

uh I think it's 38 um something uh 385 what is it 3875 perhaps yeah so it's 3875 in the in the spec repo here I put post the link there okay cool thanks and this oh the thing we were talking about on ACD

yesterday oh no so that's uh that's another thing which is uh um to remove uh when we call get payload uh the engine API would bring this request would be separated so that we the CL needs to interpret this and put them in the in the P block Val so it's yeah that that we haven't even changed we need to to see how how it works and we need to come you know we need to we need to we need to make the engine API changes perhaps uh depending on what comes out of that EIP we will need to or not need to add engine API changes I suspect that we do not require any Eng and API

changes besides the ones that you already noticed that are by range yeah yeah um where are people on their implementations of the CIP like basically I'm pretty much I mean baring these changes but I'm pretty much done with like the beacon chain changes but I'm I got to do all the fork Choice still we we have um most of the beon change changes uh not all because anything that requires uh that requires for choice we haven't implemented and we haven't implemented essentially anything on for

choice we have the P2P validations so we have all the validations coming from The Wire we have uh the state transition functions uh but and we have the committing to DB but we don't have anything that has to do with like changing head okay yeah yeah I I mean I still have to do like I mean I just what I meant by Beacon chain changes is like you know all the changes to the existing data structures plus like the new data structures and like the block processing and State Processing and that kind of stuff but I don't have like it's not all stitched together in a coherent way definitely me it seems that we are more

or less in the same situation then perhaps there are a lot of validator changes as well for example you have a new PTC Duty which I think we finish that end to end but we haven't done the proposer changes okay and how about other clients or are they around the same place or is anyone ahead um so for Teco uh yeah haven't been working on epbs for the last week but uh we had a decent progress with everything but FK Choice it was in a good stage and now I'm rebasing the lookes on top of the looks

which pus mentioned and yeah that's a bit of a nightmare as he said so yeah we'll probably spend some time on that and then yeah we still have to the F Choice which is the major change so yeah sure maybe a little further okay yeah I was just curious all right cool see Justin do you know how Tech is doing or is the person that is is the EPF uh here well so I've been I don't know if they're here actually I

can't well I can scan the participants for a moment and I don't it doesn't look like it unless they they're using a very different name and and they're not eliest to somebody I do know who they are otherwise anyway so so I don't think they're here so I guess I'll I'll address this then or I'll comment um yeah we're we're most of the way through I would say the non Fork toys part of of um so the beacon chain um I actually got a question from um from them and I um basically pointed to the comments in the Discord channel from teu and you guys a couple weeks ago about which it sounds

like still broadly true that fork Choice seems to be not mostly um broached yet um because that's what they working at next um I have pointed to them and please tell me if this was a um uh reasonable or or not thing um things like the state or the block processing or the peer-to-peer interface um the idea is things which are maybe have some independence from from Fork Choice um now as far as the Lucas's PR were sort of not as far enough long to be enormously hindered in a way uh we

actually have a slightly different issue whether that that PR and I don't know I'm actually yeah I I think it makees this a question I'm curious what other people are doing with this because I this is something Nimbus doesn't so Nimbus doesn't do feature branches very much that's the brief background here we we we kind of keep merging smallish usually bits into our development Branch all the time so here however we have a definitely a feature Branch but it's it's sort of falling it it needs it well the person doing it is in fact not reasing or merging which is who knows I'm leaving up to them for the moment but is this something that people are doing in general is this something that

people's epbs branches are they are are they trying to include them in some development Branch are they just leaving them kind of relatively stagnant from development figuring that only update when truly necessary are they um kind of be basing pbit like what what are what are the for for me I mean the branch is small enough that I've been rebasing um and like was but like once you have enough PRS that becomes like too painful and I'd probably like merge into but then with this recent change from Lucas seeing is how it affects a lot of

Electra is my understanding I think what I'll probably have to go do is implement this for Electra first and then rebase my my that's that's what we did that's why I I hadn't worked in Electra at all except Lucas spr that I implemented it just because I wanted to know how to rebase later okay yeah um that that's all right having said so our development is probably very different than Nimbus uh like the reason we are it's presumably very reasonable especially for us that we're kind of

convinced that it should be included that that you could have this in develop as a future fork and then it shouldn't affect at all your production code uh the problem is that I'm never going to get this past Preston uh to merge it in prism so that's why we we we cannot go that way but that way certainly would be the easiest one to maintain yeah for sure I'm sorry I um ahead goor is this this thing that was just merged from Lucas U is this for devet 4 right then yes okay good okay because I was

worried like that would be even worse if like because I don't think we've done DEET four yet and if that would be hard to merge that into unstable and then we'd have to have like a free this PR I don't know I'm just uh okay it would be worse if we had to have like some intermediate step before this PR and that I would have to like figure that out but all right but I'm excited that people

are actually advancing if if for Choice seems to be the the problem for everyone um please ping me when you guys start implementing it because that's certainly where the bad bugs are going to start appearing uh if there's any attack on this it's going to be on four choice I think yeah I don't know that I the only reason I've not started it is because I mean for one modularization just one thing at a time but the other is I my general I I generally haven't spent a lot of time modifying Fork choice in Lighthouse so like I have to wrap my

head I'll need to wrap my head around a lot of our specific implementation of fork Choice and then modify it so it's just better so Fork choice is I guess that one of the notable things with forto here is just one of the shared bits of infrastructure that um so so this is one option is to treat this as a complete Fork as it were and and we're not worried about merg ability e even eventually um and another and in that case that's easier in in a way another is is to care um but but regardless of that this Fork chice one

of the notable things about about is exactly that it's one of the first times it interacts in a fairly intricate way with u rest of the implementation networking doesn't most of the beacon chain stuff is new um Etc and and it combines that with being let's say very nuanced or subtle security properties um I've probably done a little bit more work with our Nimbus is Fork choice that it sounds like Mark has with with um with but um but not that much and even then I've seen I mean this is mostly an eon's thing really and like but getting it it's very easy to get it

wrong with um in in subtle hard to detect ways that unless they're tested for specifically like all of the unit tests will pass and everything else will pass I it always makes me a little a little wary of um changes I guess yeah you're absolutely right writing the four Choice tests for this if we ever decide to ship something like this would be a nightmare like getting all branches tested uh on for choice and creating those test vectors is going to be a nightmare and we we need them it's definitely the most subtle Point um if I mean there's since there's some light in

that uh Franchesco is trying to work out a version of PBS it's very different is without BTC uh and it has many disadvantages that I can see but a huge one is that it doesn't touch four Choice it just keeps four Choice as it is today so if that one works we might want to shift uh but it's just an early idea so far all right guys it seems that we're more

or less all of us in the same page the withdrawals issue is not really an issue I only see gajinder with the mic open I don't know if you could wanted to say something aenda yeah hey prod uh so basically in um and while we were putting up the post about split division of Spectra uh uh we basically had a small discussion about epvs because I was sort of pushing it to be included in Petra B uh so whatever is the name of the whatever be the name of the fork but I think uh so there were a few questions that were asked and I sort

of want to bring bring them out in this form and sort of want to get your opinion and the question was that right now in in P EP uh in PBS we have two builders that are mostly making the block but how will epbs basically change that in the sense that uh any Builder can basically right now even go to relay and start uh providing it payloads uh so how does epbs democratize it in the sense that even if the Builder for example has to still be a validator put up a huge bond which

is basically held up in uh in the beacon chain uh then the problem is that it increases quite uh it increases the barrier quite a bit to be a builder and I don't see how what's the what's the increase in so so the fact that you have to have at least 16 e to to state y uh I I don't see this as a big barrier like the if anything the current Builders all have much more and they will be staked anyways uh so I don't see how can it be worse no no it's not going to be worse but the question is how it's How do we

make it better so yes yes so for it's it's it's unclear at all I don't I don't see epbs in any way make uh a team that doesn't have the private over order flow suddenly bat these builders that have the transactions that no one else sees so I think it's going to be very hard that any any player in any system that you can come up with Will bit someone that has transactions that you don't have so so I think it's quite naive to think that uh that we're going to ever be in a in a situation in which the transactions are all private and then suddenly

out of like thin air we can beat them uh however uh what this does is that it raises the floor to be a safer a a a a more uh balanced auction uh Prismatic Labs will just have a vanilla client posting bids any validator any hom steaker can just set a flag on their own on their own home home staking house build r and just submit bids every slot so that means that at the very least Builders will have to bid more than uh honest validators uh bidding uh all of them not just uh my

own house but all of them right so I think this makes it more easier I basically gave arguments on the similar line that anyone would be able to be a builder but again the question arises that how would one person How would that person become effective against or become uh you know very competitive against the builders that are out there and as you mentioned the private order flow is one of the issues uh but maybe I think what we can also do is not require Builder to have 16 each St and when the Builder is for example uh when when anyone could be a builder as long as they

uh their Builder bid contains a transaction uh which is which can be which can basically uh be applied on the El State uh and yeah this is one way can be directed from the execution but this doesn't give this doesn't give any better status to a builder so and it makes it much more complicated to us so what you're proposing is to make the payment UPF front on the El uh which which is viable we can do this however uh to make that payment you still need to have that money locked up

you cannot come up with that money out of the block itself which would be the dream situation for a Searcher soon to be Builder you find a block that is worth 45 e you submit the bid for 45 e and uh for say 44 .9 uh if and you include a transaction in the blog that pays however that transaction needs to come with the money at the top of the state so that means that you already needed to have this 4040 you cannot produce 404 in your block and pay because we're no way nowhere near to like having ZK proofs that you will pay in a block so I think I think it doesn't solve the issue of

like having the money up front and it makes it incredibly more complicated for us to build because it requires now the El to be to be to be with us shipping this so bid is not going to be 44 e bid is going to be I mean most of the times in the1 or 2 e kind of a uh kind kind of a range but my my thinking was that if for example I uh I am a person who wants to not get my trans action sandwiched uh so I'm thinking what what can what kind of use cases can be solved with this so for example if I am a

person who don't want his transaction to get sandved so I can use my own Bono to sort of transmit this bid and if it's included then obviously I I will I can also transmit my payload and when I'm transmitting when I doing the bid I can use my local Elm pool to create a bundle with my transaction included or it could just be that person's transaction as long as obviously it's paying more uh to the proposer it sort of gets accepted and then I can get my uh my transaction included and the point is that I don't have to be a a builder in the sense of

staking some e on Beacon chain and if it's open to everyone who can do it at any time then I see for example many people or many Veals at least using this particular feature uh to safeguard their transactions sure what you're describing is inherently better than forcing the builders to be stayed and it's inherently much more complicated so enforcing the payment is something that is trivial in our design and it's highly non-trivial in your design it involves like bringing five

extra teams having the the logic checking synchronizing the CL with the El in the fact that the payment was made uh and so forth yeah so when we um I mean it could be easy for example when the bid is applied uh when the bid is received so you send it to El to sort of validate it and if it gets applied then you get a state root back on which you can further build uh or um so Bas yeah but it is a bit more complicated uh but even if for example we leave this proposition because that was something that came to my mind when I was trying to come up with the reasons why epvs will make things better so what are the

other areas of impact that you think that epvs will have and I was I was also reading about execution tickets and I think you might have mentioned it earlier and uh at some point we might need to do multiple proposals or execution tickets and how all that will sort of uh fix into this puzzle so if you can sort of jumping all over the place so so the big the the one reason to push forbs perhaps in fusaka would be because it SS all of the discussion that were seeing today about blobs being included or not uh it solves the latency problem on

CPU and it solves the bandwidth problem on stakers uh because and this is nothing to do with epbs itself nor the auction mechanism it's just the fact that you don't need to validate da nor validate execution on the payload when you add test so if you're a proposer you're a homaker today you need to get your blobs out and they need to be distributed to everyone in less than two seconds on epbs they need to be distributed in less than 9 seconds so that's the biggest impact and we wouldn't be having this discussion of whether we need to incre in increase the blob T the target for blobs or not because bandwidth will not

be an issue or at least only average bandwidth would be an issue instead of peak bandwidth would be an issue the same for CPU so those are impacts that epvs has independ regardless of market dynamics nor me nor anything like this uh and I don't want to the other so so can we sort of quantify in some sense what the effect is going to be so that I mean for example Lotsa team wants to know what is the net positive can we quantify what is the net positive effect of epbs and maybe some write some article about it unless it's already covered and I don't

have it sorry could you repeat I don't understand I mean can we sort of articulate uh how epbs how impactful epbs is or how it's going to impact and uh create a positive staking system apart from the fact that okay you know uh we have because blobs uh again when 9 98% of the blocks are through PBS uh basically publishing blobs is not really an issue uh but as you have said that okay it will also increase the

window to import the blobs and to validate them uh so that might be a positive benefit so can we have a article that basically says that or a document that that says that we've we've produced like several documents like this Terren has been doing like Outreach essentially all of my documents like point to this pipelining um we have like very precise numerology on how all of these changes I've been tweeting about this for two years now I think this is like if it's yeah I I don't know I feel like this is highly documented already like in in the the E and in the

pr there are links to like very extensive documentation that that documentation includes this you you I I do believe that you have a ton of documentation I feel that in some sense there's so much that it's a bit overwhelming uh okay uh in the next 10 minutes I'll post a hack andd with the pipelining of what you get 10 minutes after this meeting is done I'll post I do I do think that a bullet pointed list that someone like very quick overview of the benefits in PBS would be really good at getting Buy in and like not a deep dive technical

but like yeah there are those several of those it doesn't have to be technical something like veral doino like we have for veral uh basically a site or maybe where wherever we choose to put it it just basically Al documents all that stuff and okay I'll also sort of go through what is out there and see because I was trying to explain the benefits of vpvs over what currently scenario and uh realistically I couldn't figure out how we can de democratize the Builder set

uh I think so they're they're again probably going in circles but um what itbs allows is a builder is to anyone that has the money to become a builder instead of like asking for permission from a relay uh that's the only thing and it might be zero today because relays are allowing anyone to build so this is not g relays are not gatekeeping Builders so it's not it's not a real change and I very much doubt that we will ever have any system that makes people win on the public mle versus people that have the private order

fls and I am not aiming to change that at all so it is some sort of uh protection against Monopoly of the delayers is the best argument that that is out there it is allowing someone to not have to trust an external player this is not something that we we have the capacity today if you want to construct with an external Builder you need to trust someone and that's all that we're changing on the auction and then there's a lot of benefits that come from the

pipeline okay so I mean maybe we can also lower the threshold for a builder and if the Builder has some particular e threshold then uh I mean you can't because if let's say that you have validators that have one e then you open the beon chain for a go that's the reason why validated can only have can only start with 32 e we cannot handle if we get like a million deposits of one e but also I believe that I also believe that it's not an issue like H having the the builders being sted is not really an issue if you like very small Builders

can still go through a relay like if you see someone is not a competitive build right I basically don't see current Builder set or somebody who is serious about building uh not putting up 168 I mean at least not at these prices uh that is not an issue but uh it could be issue if prices explode or uh there are people who don't want to trust any Builder to give their private transaction tool so that it gets sandwich so in that sense uh that was my earlier thinking in in which the bid itself could be checked

and deducted from execution layer before it's confirmed to be part of the beacon block and the right is given to that particular Builder to produce the block but uh yeah I understand what you're saying um I I I actually feel like perhaps what's the meta discussion is we might benefit from from a a different meeting with you pus to like pick your brain about a lot of PBS stuff um it doesn't need to be like like I don't know an office hour on PPS because you you've done so much uh work you know understanding this

and um yeah it just like I feel like a lot of catchup could be done and I I do agree that um um The Wider Community is less informed about this for sure um and the only reason I uh like I mean I specifically dug into PBS myself and brought that to to Sigma prime a while ago which is why I know even as much as I do but that was several hours of research that other you know clients

haven't done and um and even I'm behind on a lot of the things so I don't know we could use time even digesting some of the research and piing your brain on stuff is my thought I'm I'm I'm happy to to talk in how much time you guys want uh any day you can just Bing me on onbs on the EBS Channel I'm the most invested terance as well on on shipping something like this so I'm happy to talk as much as you want I mean as I sort of mentioned on chat that lowance is a good thing and I mean trust is definitely good uh but uh

if we I mean if we think in terms of low latency and that effect could be multiplied if we sort of have SL auctions then blog auctions yeah unless you guys know how to solve the problem that Julian wrote uh I yeah I don't know how to I don't know how to solve that I mean because yeah the problem that Julian had said last time was correct me if I'm wrong but slot auctions just much more likely to create a secondary market and people to go

around enshrined PBS system and do offchain relays and things like that yeah a pretty clear yeah the relay is going to be the Builder and it's going to be one person winning every slot yeah and then but the but we have a DA problem with block auctions still yes that uh that we need to think about and we need to gauge whether or not is dangerous and I think one of the directions that we thought of to maybe head that off was like adjusting the penalties so that they're not linked I

forgot exactly what it was it was something along the lines of like yeah so we could we could slash for an invalid payload that has the right hash we could charge right there uh on inclusion we can charge the the Builder uh but it's it adds complication it's easy to implement but it adds complication that's why I would rather not certainly not do it at this stage where we're talking about like an early implementation right yeah and I guess to Dustin's point about how much is getting merged in since we talking about early implementation like I have been treating the the lighthouse implementation as more or less prototype

code like it's not it's not terrible code but it's not like like I I expect to have whatever final implementation to be a complete rewrite but having gained the experience of how to implement it through this but yeah so I I I basically could not understand why slau auctions have that problem of secondary Market uh but yeah I'll go through it and maybe come back because I think if we can substantially change the latency game or the time that Builder has to build the blocks

then it would be pretty nice direct benefit that can be easily explained that okay you know it is making the entire blockchain economically efficient so I think we should try to see and I'll try to understand what the issue is with the slot options the issue is very simple is that in this delayed options it's been measured that you you get higher bids for just in time than than a bid of what the value of the

block will be 6 seconds per now because whomever is bidding is going to discount from that bid the risk of the market going against in the next six seconds so that means that for the validator the rational decision would be to never auction now but rather defer the auction to six seconds from now and by the way to do this is to sign the block with the relays address and then the relay runs the the auction 6 seconds from now in the future the relay pays you off Market off chain or I'm not off chain I'm sorry off protocol and it's hard to argue against

that yeah one of the other things that came up though that gu brought up was having the I believe what you were talking about earlier was having the payment basically not be or like the stake being being in the execution layer rather than the the beacon yeah this is certainly implementable and we can iterate over this we could we could easily it right over this but uh but this adds a lot of complexity it adds complexity on rears it add complexity on on for Choice it it's I have thought about it and it's much more complex and it gives very little benefits I claim because it's

unlikely that small Builders uh would would ever win like small Builders like occasional builders that are not able to stake 16 e in any reasonable Manner and at any chain there's at any in any case there's a market for that you can still go through a relay oh yeah I I guess I wasn't I don't yeah I thought there were benefits besides small stakers that that design would have accured but um it's it's it's also it opens also the it's it's it's it opens complexity on every level like currently it's

already a do for us the fact that any validator can send a bid if we open it to anyone with a NE account being able to send a bid it's a different order of magnitude oh yeah yeah um so yeah actually that was something is is it the is that how we handle like bid uh dosing on the P2P layer right now is via VIA you having to be staked well it's that's part of it but still remember that when we went to Capella we were worried that we were going to be dossed by BLS to EXA changes right so still need to heavily stop

bidding like you can only for example you can forward only bids that are higher or like the top two bids that you receive yeah I mean because that is another layer of complexity is is how you deal with spamming the bid topic on Gossip because I I had I had once uh there was a proposal for what is it called There's different kinds of relays it was like the V3 version of the optimistic relay where it it was basically PBS but you had a relay just to enforce the payment but

everything else took place like it was something for us to field test epbs I guess um and that was the topic that I looked at is how to prevent like spamming in the the way that I had done it at the time was like basically you you already had to have won a couple of bids via the offchain mechanism via like you know relays and stuff in order for the beacon chain to recognize the pub key of the Builder and then to to gossip bids um and that basically you'd have

this kind of rolling window of like people that have one x amount of blocks can can push bids um but with EPS you can't really do that you can do people that are staked but it seems like it would be relatively cheap to continuously I mean if all you got to do is put up 16 eth and then you can just Spam the the P2P layer layer with bids aren't going to win or something along those like we yeah I don't know yeah but I mean the

the the complexity of allowing bids on for from anyone uh that is not State as Ginder is is suggest I mean even with State even with oh even with State we can but we can heavily stop it by just saying we're only going to gossip uh one bit from each validator Max and only the top bid that we receive so you need to bid more than the current bid if you want to if you want to to goit it so so it's easy for us to stop it on the on the state side on the CL P2P but if it's open to everyone then then the point of of transactions dose handling is that when once you have a valid signature that

I've checked then I have you if this transaction gets included and I can include it you will pay gas for it and that's that's the assurance that you have that verifying the transaction is cheaper than the gas that you would pay for it otherwise we will be broken and this this doesn't hold in in G jinder's approach like the only thing is like right now with the current relay approach there's tons and tons and tons of bids and which like you would have to change the You' have to change the um the setup so you basically only you wait until just before if you're a builder you wait until just just before the you know slot and then you gossip you're only your best bid for that slot

which oh no but actually that that actually is solved uh by the current design of epvs so the reason currently there's a lot a lot of bits is because the relay has a push mechanism instead of a pull one uh I well that's a side of one but the reason is because Builders continuously push uh B to the relay because they don't know when the proposer will request them and they need to cancel bids because the market was against them or whatever it is uh this is no longer necessary for Builders because the proposer would only ask once or whenever they want to ask uh and then the Builder decides if they want to

serve or not the proposer well the proposer if they're doing the P P2P layer the proposer doesn't ask yeah but the P2P layer is kind of irrelevant for pbn the PTP layer is only there as a safeguard to keep the lowest uh bid possible the PTP layer will never win an auction in real life okay I mean if that's the logic that makes sense but [Music] um so you're saying that basically a rational Builder what they can do is like wait until some x amount of time before the slot gossip their bid just to

ensure it gets there but then they still maintain a public end point no not even that they don't gossip anything they don't want to gossip anything because they if they gossip anything that can't be included a a serious Builder will never gossip anything on the P2P side stack and will only wait for the proposer to request um that okay I mean what I was thinking that they would do is that they would gossip but then you would you would maintain the ability to like hit their hit their point and potentially get something better because you're have a lower latency but I don't understand if they don't gossip at all I don't understand why we even have a PVP layer well because I will gossip I will not open an endpoint like I I am a just

a hom steaker and we want to keep the lowest uh we want to keep liveness on the network so a few people that are altruistic will be just gossiping bits every now and then you just run your your your Lighthouse node has a flag that says uh on top of validating submit a payload every ebook submit a bit every ebook it's cheap for you it's free you're just going only going to stress your e for like 12 seconds at eok and you keep lightess and you keep the floor option I see definitely Prismatic Labs will run a builder and and your thought is that a serious Builder isn't going to gossip

because they'd be telling the other Builders what their bid is and stuff like that or or well also because it's uh it's a matter of late of of timing right so the gossip on the P2P layer needs to go 3 seconds essentially before the actual bid will be that wins the auction will happen right the bid that wins the auction is going to happen at around two seconds into the slot and the bid to be on the P2P stack needs to be at least one second before the slot in those three seconds the whole Market can go against them no serious Builder would like commit to a payload that can be included 3 seconds before uh the payload actually needs the B the auction

actually happens so the they would or at least they would definitely not include any sex Arbitrage transactions which are huge yeah so they they they they they they they cannot cancel a P2P uh bid they can cancel their own bids yeah I can't canel yeah so right so basically like if the Builder was even to participate they would basically not include any of those Arbitrage transactions which would make it much less competitive in addition to also having a second or so less time than yeah okay that makes sense I mean

they could still do it just but it would be extra work for them and there's not much I mean yeah especially with block auctions maybe that's one I mean that might be one other argument for slot auctions that slot auctions like presumably all of these Arbitrage issues would be rolled into the cake with their pricing and the P2P layer could be more heavily used but I was thinking one one thing so why do you think that

the a builder won't try to send the bid over the P2P and just wait the proposer I'm thinking that maybe the proposer is not connected to the to the particular Builder and that Builder that is not being contacted says hey I have I have something bad and I think I I think I I will beat the one that the the proposer actually contacted so I want to signal to to the proposal hey I have something better why this is not apping yeah so so yeah this this was

discussed actually in Kenya so we we should include a contract or some way on chain for Builders to register that you just submit a transaction saying this is my end point and then clients can just grab uh the list of Builders from that contract yeah I I see but maybe the I understand your point and I agree like a builder that is not popular will use the PTP stack yeah let's say it's something that is someone that is is censoring like hell and uh half of the proposer don't want to do that but then he wants to say hey this is my candy do you are you sure you want to pick

this no I I agree that the P2P stack might be useful for certain cases but realistically like all of our blocks are being built by two Builders those two Builders are going to continue whatever system we we we design yeah yeah and those two Builders will have open end points so the concern was that an unscrupulous Builder would put high like high bids on the P2P layer and then win auctions is that I I didn't quite understand I I I guess I didn't see a

difference if that if I understood that correctly I didn't see a difference between the PTP versus the RPC layer because I mean presumably we could Implement like something where you have a blacklist for Pub keys for the Builder and then oh that that would definit we will definitely automatically Blacklist builders that satisfy some criteria that's one of the big advantages of epbs the validators can Blacklist Builders instead of relays but I think Enrico has a point which is there are some builders that are not known they're not being contacted by validators those Builders are kind of forced in the B2B stock oh that was the point the point is if they're if their endpoint isn't well known then the only way they can get

attention is using the PDP layer yeah well known or or or well known but uh normally not used because of some social stuff but they still want to say hey I have something and the way to contact proposer is via P2P layer yeah and I don't see that as a concern though I don't see that as it was not as concern it was a comment on poto saying that a builder won't never send a bid over P2P normally and and I see in that there are some cases where maybe he

wants to yeah yeah I and certainly like a register of end points I don't know that feels like something that would be handled offchain the way it is now but one thing that isn't done now that is like the nice thing about the PTP layer is that it's just automatic like you'll just automatically get like even if there's a builder you've never heard of if they have a good bid you would you would just be able to get access to that bid whereas like right now you have to like manually keep checking the eth

stakers GitHub list of URLs and adding them to your yeah or what if a bid contains also the Endo yeah I well to have it on chain that would be but in theory I I would think you'd have a a separate gossip topic for that just because you wouldn't you otherwise you have to have an extra data field in the in the bid and then using up these bytes that are almost all is not known but if there was a a different gossip topic for for Builders to broadcast their end points that were wasn't included on chain and you could verify their their

collateral balance easily and then limit them to like once per Epoch or something for spam prevention then that would be good but all right guys we're already over time uh I asked in the chat I don't know if there's anyone that has any concern or implementation questions uh uh or something that is not related to the the auction itself so we can probably uh allow Puja to finish the recording and and go home

and and call it for the next weeks um I will hopefully still I'm still aiming to have this working by uh by Devcon so and then next meeting that we'll have it's going to be like fairly close so in like two or three meetings I I'm hoping that uh we have already for Choice working and at least um one client uh interrup running all right I'll I promised I'll post this one bulleted list of uh of things and I'll post it in the next 10 to 15 minutes all right guys yeah bye see you

next time bye thanks bye