block.prevrandao vs RANDAO(n) Discussion

block.prevrandao

block.prevrandao gives you the randao value from the immediate previous block with respect to whichever block the transaction executes in. The user has the freedom to revert their transaction until they calculate a beneficial block.prevrandao value. The execution of the claim of randomness cannot be divorced from the randomness value that will be used.

There is no way to escape the vulnerability through a fancy time lock delay or hashing or anything. The claimer never has to finish a function call until they get the roll or setup that they want, ensuring 100% success. With block.prevrandao you can always "choose" the roll you want.

Imagine you have a bunch of user's that paid to enter a lottery and then at block 1000 there are no more accepted bids. You declare that the lottery will be rolled at any point after block 1100, or ~30 minutes from the final bid. When block 1100 or later comes, the owner can choose to revert until they see a profitable number for them.

What if you had a section of time to claim, from block 1100 to 1150? That is still 50 blocks to claim, and what if the owner finds no beneficial number, and simply doesn't claim during that time period? The lottery is refunded and they could just game the system for that 50 block window until they drew the number they wanted.

What if there is zero window of time and you must execute the claim at exactly block 1100? Well, the owner or users can still just revert the transaction if its unfavorable, and would get refunded. If they don't get refunded this is way too dangerous because if they ever miss the execution in the exact block, or time window, they would lose their lottery bid funds.

You would need to have a trustless execution on chain that never reverts after the waiting time, at a specific time, which is impossible. The only way to do this would be with a decentralized off chain oracle system that executes transactions at a particular time for the lottery, where they are penalized if they fail to do their job. Way too much hassle and for all intents and purposes, impossible.

See block.prevrandao PoC attack and more here: https://medium.com/@alexbabits/why-block-prevrandao-is-a-useless-dangerous-trap-and-how-to-fix-it-5367ed3c6dfc

Randao(n)

In contrast, with randao(n) type of technique using an oracle, the block assigned to a user must be in the future. This means there is no way to "choose" the roll you want, because the block does not exist, has not yet been verified, and the randao value in it's header is unknown until the block is validated.

When a user requests a random number from their future block which has now passed, the oracle simply retrieves that random number from that block. The protocol should essentially freeze the user until they use their randomness value.

Why RLP encode the block header?

You cannot get a complete historical header on chain. We need to get the entire block header with all its exact elements on chain, and verify that entire state on chain. If you just gave the RANDAO value from a block header found off chain, onto the on chain smart contract, there would be no way to verify if it was truthful. By encapsulating the entire header, and extracting the RANDAO value on chain, it's trustless.