Why don't we use a straightforward approach to generate random numbers ?

[TilakMaddy]

I think I just figured out a much more straightforward way to generate random numbers !

function getRandomNumber() public view returns(uint)  {
    uint rand = uint(keccak256(abi.encodePacked(block.timestamp)));
    return rand;
}

Pros:

• You don't have to buy LINK just to create a random number
• Much smaller code size

[alwayscommit]

https://betterprogramming.pub/how-to-generate-truly-random-numbers-in-solidity-and-blockchain-9ced6472dbdf
This article explains it with block hash, block timestamp wouldn't be much different, rather easier to predict/compute maybe?

I'm not 100% sure, just did a bit of reading here and there.

Also, maybe this wouldn't work in a sharded blockchain?

[jmhickman]

When that call is made, the timestamp is a known value. The outcome of the call is deterministic, which isn't what you want in a random number call.

function getRandomNumber() public view returns(unit)  {
    uint rand = unit(keccak256(abi.encodePacked(block.timestamp)));
    return rand;
}

[TilakMaddy]

@alwayscommit What is a sharded blockchain ?

[TilakMaddy]

@jmhickman can you expand on that?

[alwayscommit]

"Sharding splits a blockchain company's entire network into smaller partitions, known as "shards." Each shard is comprised of its own data, making it distinctive and independent when compared to other shards."

If there are multiple chains, maybe an application just runs on one particular shard cluster, and then you could use the method you mentioned above, but if an application itself is sharded, then that RNG method won't work as different shards will have different blocks, therefore different timestamps and they won't be able to arrive at a deterministic value since they operate on different blocks. But in case of chainlink's VRF, the independent shards could call the same VRF.

[PatrickAlphaC]

Summary

Tagging onto @alwayscommit's great link to this article, the long and short of it is that you're using a deterministic value (and you can't have a deterministic number if you want it to be random!) and giving the power to the miners.

Here is another breakdown I did on the Meebits Exploit where someone used this insecure randomness and got hacked! This exact exploit happens WAY too often! Please be safe!

More information

Additionally specific example is also susceptible to the reroll attack (someone should write an article on that) where you just keep canceling transactions until you get a randomness value you want.

But even if you design a method to get around that, let me paint you a picture...

Scenario

You are a miner, and you just entered a lottery contract worth $1,000,000! However, the user used your method of randomness:

uint rand = uint(keccak256(abi.encodePacked(block.timestamp)));

Now, you go ahead and mine the winning block... but you notice you're not the winner... Well, as a self-interested miner, you're now incentivized to throw out the block!

Now, let's say every miner is self-interested and has entered this lottery... They will throw out every block until the block they mine is a winning block for them!! Meaning this lottery application is not fair at all.

What is MEV?

Additionally... Maybe I'm a really smart miner, and right before I mine a block I compute what the timestamp should be for me to win. On ETH you have about a 13-second window that you can fiddle with the timestamp, so you fiddle with it till you are the winner!

This is trivial for miners to do, and a lot of them do things like this! It's called Miner Extractable Value (MEV)

So... we don't want to do our randomness like this, because we are giving all our power to the miners.