We can improve the stability of this design by requiring every block to also be attested by a committee: to build a block with parent B, one must first gather signatures from, say, at least 1/2 of a set of M validators, which is itself pseudorandomly sampled from V based on the value of R. This makes forking less likely, as it means that a relatively large number of validators need to collude to make a fork.
The “naive” version of the RANDAO beacon does have a vulnerability to attacker path selection, and only has 51% attack resilience up to α ≈ 0.36
However, this can be largely remedied by requiring a committee of notaries to verify each block (which is already a prudent idea because it reduces forking); adding an extra 4-of-4 notary committee can by itself increase resilience to α ≈ 0.455
However, going too far in this direction compromises the goal of lacking an in-protocol liveness threshold.
Adding a cryptoeconomic aggregate signature, or BLS/STARK-based aggregate signature, would make reversion attempts even more expensive
Enforcement of signature aggregation in block proposal for less fork