2

This question has been asked previously by someone else but the answers weren't quite sufficient.

I want to write a simple contract that will yield an immutable 'random' number after a period of time.

My thought is to write it with reference to the hash of a future block of some chain. So contract will only complete if block height N is available. If the block is available, the contract will use the bits of the specified block hash to return the outcome of the dice roll.

I'm solidity noob, so wondering if this is a worked example by now...

Richard Boland
  • 21
  • 1

1 Answers1

2

There is a fundamental problem with this approach: the concept of "contract that will yield...after a period of time". All actions in smart contracts are triggered with a transaction. Contracts never do anything "by themselves". So somebody has to send a transaction a point X in time to the contract and then the contract can check "is the current block above block N". But it can't "wait" for the right block.

The contract can for example collect data from "previous" blocks if somebody triggers it with a transaction. So for example three separate transactions are required which have at least 10 blocks between each other and some (pseudo)random bits are collected in each of the transaction.

However there are some projects which let you "pretend" that you can activate functions at a later date. Here are some references: How can a contract run itself at a later time?

Lauri Peltonen
  • 29,391
  • 3
  • 20
  • 57
  • So technically speaking, this dude needs call his die-rolling function randomly every once in a while (or grant that privilege to some external service, like Oraclize, and pay them to do it for him). But if that's the case, then he doesn't need to generate a random number inside the contract to begin with, as he can simply generate it off-chain and pass it to the contract function whenever it is called. – goodvibration Feb 10 '19 at 10:29
  • Yes, but the passed number cannot be trusted. On the other side, if the number comes from the hash of the block X, it can be verified that this is, in fact, the case.

    Also, I wonder why everyone keeps sending people to Ethereum Alarm Clock exclusively. In a previous answer I made a list of available systems with pros and cons.

     – Jaime Feb 10 '19 at 10:50
  • Yes, I agree that if the random number generated on-chain, then the level of transparency (and subsequently the level of community confidence) is much higher. So it's definitely better to do it this way. With regards to your other notion - I never head of Ethereum Alarm Clock to be honest, but I do know that Oraclize is often mentioned. I guess that they provide similar services...? – goodvibration Feb 10 '19 at 11:39
  • 1
    Thanks Jaime, remembered someone had given such an answer but couldn't find it. Edited my answer now. – Lauri Peltonen Feb 10 '19 at 15:59