Content pfp
Content
@
0 reply
0 recast
0 reaction

Barnabé Monnot pfp
Barnabé Monnot
@barnabe
1 reply
0 recast
11 reactions

Ellie pfp
Ellie
@ellied
"Single slot finality is likely required." Why is this the case for the fork choice rule for ETs?
1 reply
0 recast
1 reaction

Barnabé Monnot pfp
Barnabé Monnot
@barnabe
I’ll ping @fradamt but I might have misled terence here, aiui PTC is not enough when the execution proposer is not chosen by the beacon proposer of that slot. SSF works but so does “two-slot PBS” with two actual attesting rounds
2 replies
0 recast
1 reaction

Francesco pfp
Francesco
@fradamt
Have to think about it more, but the rough idea is that, if an execution proposer is not chosen by the previous beacon proposer, it is even more important that they be able to deliver their block regardless of what that beacon proposer does.
1 reply
0 recast
1 reaction

Francesco pfp
Francesco
@fradamt
Another complication is that now you can't base your bid on whether the tip of the chain is stable. To help with both, we'd want the execution proposer to have its own slot and be able to ensure inclusion of its payload, i.e., two-slot PBS with reorg resilience
2 replies
0 recast
1 reaction

Francesco pfp
Francesco
@fradamt
Two-slot PBS kinda requires us to get rid of committees (SSF, essentially) for complicated LMD-GHOST security reasons. This also gives us reorg resilience, i.e., any honest proposer (execution or beacon) can ensure the success of their proposal (in fact, reorg resilience is what fixes two-slot PBS)
1 reply
0 recast
2 reactions

Ellie pfp
Ellie
@ellied
I think I understand - With ETs, we don't want beacon proposer to be able to prevent the exec proposer from proposing on time. But this means the beacon block must be attested to in a timely manner, OR the exec block must not rely on the beacon block (which breaks other assumptions). Is that right?
0 reply
0 recast
0 reaction