And if it's not embarrassingly parallelizable, first, tell me why, and second, what's all this business about optimizing the algorithm in the first place?
And if it's not embarrassingly parallelizable, first, tell me why, and second, what's all this business about optimizing the algorithm in the first place?
It's a cryptographic assumption that repeated squaring in an RSA group is "inherently sequential". This assumption was first made in 1996 by Rivest, Shamir and Wagner for timelock puzzles. See https://people.csail.mit.edu/rivest/pubs/RSW96.pdf
> what's all this business about optimizing the algorithm
To link sequential computation with physical time we need the general public to evaluate the VDF at roughly the same speed as an attacker. By "roughly the same speed" we mean that the attacker (even with a huge budget) cannot build hardware that runs, say, 10x or 100x faster than a publicly available ASIC.
OK, I found this fairly informative [1]. It's designed to be an entropy source feeding into a proof-of-stake algorithm.
If you can't run it "that much" faster than everyone else, it's more likely your result is not manipulated to steer an unfair portion of the block reward your way.
I haven't read much about any of this. The point that seems to stick out most is the idea that "everyone" submits some amount of data, versus just the first to reach the difficulty target submitting.
Once you have that concept, then you need time gates to control how quickly the rounds happen, and VDF can be used to dictate the clock rate.
A conceptual piece I must still be missing is how all the submissions are aggregated, and why many/most can't just be ignored. Ah, fucking blockchain catnip.
[1] - https://ethresear.ch/t/verifiable-delay-functions-and-attack...
For a video explanation of the randomness mechanism see https://www.youtube.com/watch?v=zqL_cMlPjOI&feature=youtu.be
I think the rest of the puzzle is fairly hard to guess.