Block hash liveness issue

[JustinDrake]

The requirement that the block hash be from the latest 256 blocks is a liveness issue, and therefore an attack vector. (There are various strategies to get block hashes that are older than 256 blocks. One of them is to build a STARK proving that the historical block hash is valid.)

        // EVM can get block hash only for latest 256 blocks.
        require(
            blockNumber < block.number && block.number <= blockNumber + 255,
            "Block is not within the last 256 blocks."
        );

Attack scenario

Consider a $1B lottery where the attacker has $100m in the pot. If the attacker knows he is going to lose he can force a reroll by exploiting this randomness liveness issue. Even a single reroll (1 bit of bias) is sufficient for the attacker to increase his expected return by ~$100m.

The liveness issue could be triggered by DDoSing StarkWare's proving infrastructure long enough, and/or outbidding StarkWare's gas price for a sufficiently long amount of time.

[bbrandtom]

You are right. This is not a true requirement, but just something we did for simplicity in the PoC and plan to change soon. One option we have in mind is a Fact Registry (the contract same design pattern we use for our Verifier) which registers (blockNumber, blockHash) facts. Any user can register facts there, and we can make the BeaconContract check there as well.

[JustinDrake]

A fact registry would also be helpful for infrastructure like https://twitter.com/epheph/status/1275681712685678595