Content
@
0 reply
0 recast
0 reaction
Quintus
@quintus
In the exec tickets design, do beacon blocks play any roles other than: * propagating attestations * inclusion lists Would it be feasible to completely leave them out? (hypothetical just to understand consensus implications) Cc: @mikeneuder.eth @fradamt
1 reply
0 recast
3 reactions
Francesco
@fradamt
Everything in the beacon chain works through beacon blocks. For example finality is defined by the state transition processing attestations in a particular chain, up until the state of that chain finalizes something new. Also the whole incentive system is built around on-chain inclusion of messages.
1 reply
0 recast
1 reaction
Quintus
@quintus
And the problem with moving all of this to the block coming from an exec ticket holder is that we don’t have CR/liveness guarantees from the exec ticket holders right?
1 reply
0 recast
0 reaction
Francesco
@fradamt
It would be an even more radical redesign, where stakers are really just attesters. There may be ways to do it which preserve all properties we care about, not sure. Execution tickets is already pretty radical and may or may not be the way to go, I am somewhat skeptical about something even more extreme :)
1 reply
0 recast
2 reactions
Quintus
@quintus
Ok that makes sense Was asking while thinking along the lines of the endgame. How much can we really push to a small number of highly resourced nodes? Do we get to a point where beacon block throughput holds back decentralisation because beacon leaders are sampled from validators (small nodes) instead of builders?
1 reply
0 recast
0 reaction
Francesco
@fradamt
Can you expand on "beacon block throughout holds back decentralization"?
0 reply
0 recast
0 reaction
