5

Immutable contracts that need to have a time system for handling their functions process are mostly based on block.number system. They assume there is about 15seconds between each block and thus calculate a number of block that amounts to the time they want. But with introduction of proof of stake Ethereum 2.0 will likely change the 15 seconds block time.

So does it mean most smart contracts will become obsolete when Ethereum 2.0 comes ? And how do you recommend one should deal with this issue to release a smart contract that will survive the 2.0 update ? Also is it even sure 2.0 will impact the 15s ?

P.S: For moment the best option I found is to have a function that can modify a a NUMBER_OF_BLOCKS state variable and increase it or decrease it when 2.0 comes. This function could be limited by only being able to call it once or twice in order to prevent abuse.

Improve this question
3

1 Answer 1

Reset to default
3

The 15s block time is false assumption, making your question invalid. Ethereum was ticking 12s block times 2 years ago. It is not standard and fluctuates a lot of over longer period of time.

You should not connect time based conditions to block numbers.

Improve this answer
4
  • I think most contracts chose this option and accepted to expose themselves to the fluctuation because it is better than block.timestamp as miners can change timestamp. So what's your alternative ?
    – Kevin Wad
    Commented Jun 7, 2019 at 9:03
  • 1
    @KevinWad Miners can influence block.timestamp, but only by a few seconds up and down. It's not like they can make the timestamp 12 hours in the future, or 12 hours in the past. block.timestamp is a lot better for time-dependent code than block.number
    – Jesbus
    Commented Jun 7, 2019 at 9:21
  • @JesseBusman thanks. In fact I always read "block number is a much better substitute for time-dependent computation" but I did not realize it was only for applications that are relying on under 30 seconds margin. For anyone dealing with this dilema you can check medium.com/@phillipgoldberg/… " a general rule of thumb is your contract can tolerate a 30-second timestamp variation and maintain integrity, then it is safe to use a timestamp."
    – Kevin Wad
    Commented Jun 7, 2019 at 9:36
  • @KevinWad It is a common misunderstanding. Please mark the answer correct if you think this has solved your issue.
    – Mikko Ohtamaa
    Commented Jun 7, 2019 at 10:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.