@JustinDrake thanks for taking time to address my concerns, I know you’re super-busy, I really appreciate it!
Can you elaborate on this please, how would that work? My understanding was that every validator will have to own a VDF ASIC, just like miners own rigs today?
Yep, this is really positive, leaves us with a lot of time to think everything through.
You’re probably referring to this analysis, and the Proof-of-Activity-like block notarization? IMO, this stacking of processes one on top of another might not be the best choice, because it adds complexity and expands the attack surface. If I got this all right, in order to create a random value, we will have the RANDAO process + Proof-of-Activity notarization on top of it + VDF calculation on top of it? Hmm…
I’ve read the paper, there is no mention of a 51% attack (I’m still struggling to find/understand how this would actually look like). The paper does mention that the beacon will pause if the network splits in two halves of more or less the same size (probably caused by a partition or a software bug), and automatically resume once the network reconnects (“Consistency vs availability” section, page 2). I personally really like this feature/approach (favoring consistency over availability), but it’s just me.