ePBS Breakout #13

Transcript

uh okay so let me quickly tell you what what it is and then we can just discuss offline um so there are two issues one is an implementation detail um itan noticed that if you're a validator you Pro you call just to propose a block say and um you need to propose next block and then it just don't happen that the current slot you have is the empty note then you're kind of SC because the the beon state for the for the beon block I mean the beon block was uh imported you deducted the withdrawals and you cannot obtain those withdrawals anymore because on the state we record

only the we record only the root of the withdrawals and the beon state is already changed so the withdrawals might be different so either the implementations need to cach the withdrawals or we need to make it part of consensus and then instead of keeping the roots we keep all of the withdrawals that we executed last time so both are solutions I'm not sure if we should make it if we should leave it as as an implementation detail and everyone should cash it or if we put them in the state and then we have them available there so so we avoid like caching problems so it's an issue of like having either implementation bugs

or having uh or having consensus bugs so I kind of believe that implementation bus is probably better but I'm not sure uh that's that's the one thing uh and yeah so I'm I'm not sure what's what the people are going to to prefer but that's one thing to think and I am not changing it for the time being I'm only going to change to use Francesco's algorithm uh in the in the next few weeks so so that's not there's no no urgency on this but but this is something to think about because I believe and prison for example is broken prison doesn't doesn't do either now so

if we have an empty blog we're not with withdrawals we're going to be kind of screwed in the next uh in the next slot um then uh what else um the issue with the staking puts so if we allow any validator to be a builder then and uh that's going to break like the CSM for Lio for example because I would just deposit one e and then withraw 32 by just sending all of my my my validator to another validator of my own so of course there's an easy solution which is just add a new withdrawal prefix and then staking pools will not allow those uh validators to be Builders

but the problem with this is that now we no longer can have builders that are just normal validators I was hoping to get like normal validators being sending P2P bits but now we're going to have to like have uh these special Builders to be sending these P2P bits and that's centralizing so I've been talking to people in Lio to see if they can come up with a scheme to allow CSM validators to be Builders and I think I have an idea to solve this but it would require uh it would require more thinking they they are on board and they they they want to help on this uh which is very good

because in that case we will have a a very decentralized way of having builders that can actually build with one e in a decentralized and trustless manner which is something that they cannot do today today they need to be blacklisted by the relay so so the idea would be that we put a limit so one way for example could be that uh either the withdrawal credential decides uh the withdrawal credential decides what is the maximum bid that uh the Builder can actually bid for and that's not so bad we could we could handle that situation we could handle it by having a new request for

example on the El signed by the withdrawal credential and then we keep on the validator structure we add something that says I mean for this new validator that have this new with our prefix we add this condition of like how how much is the maximum bid that it's allowed I'm not so Keen with this because I I'm not happy of changing the validator structure and and also like having something that you need to cash on every validator is complicated uh but perhaps it's not so hard the other solution that I think it bet it might be better is if we don't if we only allow to bid for the excess balance so so in that situation since anyways we're going to have to have

these special validators that are like this Builder validator we can make those validators to be by default Max CB and then in that case uh lier would allow validators to like say deposit one B bond for one e they will deposit 33 e they are not partially withdrawn because they're maxb validators and then they are only allowed to bid for up to one year because that's the excess balance I think this works uh this requires that the pools will periodically need to send withrawal partial withdrawal requests because uh otherwise they're going to be accumulating the earnings and and the

eventually the Builder can steal them but uh but I think this this is a good uh a good compromise and and Lio would would allow it um but anyway so th those are the the topics that that I wanted to mention that were that I'm thinking about uh how to how to deal with the fact that it seems unavoidable that we need to add a new prefix for Builders and that's it that's all that that I have on on my end for the withdraw thing I realize we did not update the epbs validators spe to mention that for the payow attribute we need to somehow get a withdraw so

that part is missing I just realized that yeah we're not even doing it in our in our proof of concept right right but that's also not in a spec either yeah yeah but that's irrelevant I I think it shouldn't be in the spec but for the but for the compella it's actually in the spec right in in the capella in the capella valid spec yeah but that's there's no change you only put in the spec the things that you're changing uh it's true that's right yeah you're right I mean we can add a a comment that the the expected withdrawals are the ones

that are either in the state if we keep them in the state or you you need to cash them but I'm not sure what's better I mean I don't know if people have an opinion on this I think it's fine I don't think we we need to do anything because in the spec it says that just C get X just code get exp ptic withdraw the helper you pass in your state and then you get a withdraw so that should still work for EPS right no it doesn't that's the thing if you're building on top of an empty on an empty blog if you do that sending the wrong withdrawals yeah yeah no that's right that's right okay then so I think PR is our proof of concept is broken in that sense

which is the since we we never had withdrawals then that's never going to be a problem yeah I then I think the spec does need to mention that part because that part is changed right yeah yeah if if it says explicitly to call get expected withdrawal then yes yeah for Teo I think caching would be more simple and it would avoid changing the spec I mean like changing the state to changing the state C this yeah um no I mean uh we would prefer to cash rather than changing the state yeah okay it would be simp at least for now I I I also think it's simpler for us so so

I'm happy to leave it as an implementation detail uh I think Ean uh wasn't happy with having it as an implementation detail but but but I think it's fine for now anyways uh and regarding the other issues I I don't not I don't not know it would be nice to to to have some fresh eyes on it how close are you guys from having an interrup uh well now that uh it was mentioned that FK Choice need doesn't need to be implemented fully then for Teco I think um yeah I need to revert few changes and uh uh yeah should not be too far from an

interrupt oh great but but there's no need to revert things side there I suspect because um I mean whatever Fortress you have it it it won't really make make us break in any way but also like the hardest part is the the thing that you need to implement which is having to deal with empty blocks so that's already quite hard the rest is sort of like simple yeah yeah I I mean I I started implementing all these boosts and uh oh yeah I I would prefer to yeah I would prefer to have it cleaner yeah yeah so I I still I think we still have them I'm not sure if in

the branch if in the interrupt Branch we remove them uh but yeah I need to remove them as well all right so if we're soon to it that's that's that's fantastic news I'll I'll try to to start merging our intro branch all right actually uh so it's going to be rebased on top of DEET five or what's the uh what's the actual plan like uh rebased on top of what we are rebasing our branch on top of the velop uh which I'm not sure what's following do know

turns yeah that should be on top of that F5 eventually but F5 were pending EIP 7742 so yes I think we will be based on top of death F5 okay yeah sounds good all right that's it really it's a short call all right guys I'll see you then in a couple of weeks for the next one two weeks bye byebye cool bye byebye