Content
@
https://warpcast.com/~/channel/ethrd
0 reply
0 recast
0 reaction
pintail
@pintail
On the bird app I'm setting takes that today's block production issues are an argument to prioritise ePBS for Electra. I'm curious whether there is anything appealing approaching consensus around an ePBS design.?
4 replies
0 recast
4 reactions
Barnabé Monnot
@barnabe
Imo not really, and it's not clear to me to what extent any ePBS design solves the issues we've seen today. https://www.reddit.com/r/ethereum/comments/191kke6/comment/kh7j3ig/
1 reply
0 recast
3 reactions
pintail
@pintail
I was wondering if instead a version of unconditional inclusion lists would achieve the desired result - by using the inclusion list as a fallback block in the event the builder fails to supply a valid payload.
1 reply
0 recast
1 reaction
Barnabé Monnot
@barnabe
Do you not need a block to be proposed for the list to be executed? I am not sure
1 reply
0 recast
1 reaction
pintail
@pintail
I'm not really sure either. I think since under mev-boost a proposer necessarily commits to a payload they haven't seen, they would have to prove that the payload corresponding to their commitment is invalid to allow fallback to the inclusion list. So it doesn't help if the builder/relay withholds the payload.
2 replies
0 recast
1 reaction
pintail
@pintail
The proposer would have to do all that _and_ then execute and propose their own block. I don't know if that works within the current slot time, but if so it would be a remedy to the problem of invalid payloads _if_ the revealed payload provided corresponds to the proposer's commitment. Not sure that was the case today
0 reply
0 recast
1 reaction
Barnabé Monnot
@barnabe
Yeah and I am not even sure how you would get a proof of invalidity. The best that could happen is sth like attesters and all other nodes seeing the missed slot and executing the IL on its own instead. But then without a block proposed there isn't a well-typed block root to link back to for the next proposer
1 reply
0 recast
2 reactions
