2

As stated in the SWC116 (https://swcregistry.io/docs/SWC-116/) using block.timestamp and block.number in Smart Contracts under Proof of Work was problematic.

  1. Block.timestamp could be influenced by the miners up to 15s
  2. Using block.number as proxy for time is inaccurate since the time between block depended on the difficulty i.e. was not fixed.

Do those two issues still exists under Proof of Stake? If not, are there any other/new concerns about using block values as a proxy for time?

eth
  • 85,679
  • 53
  • 285
  • 406
Yleisnero
  • 21
  • 1

1 Answers1

1

Yes, generally using block values as a proxy for time is not a good idea.

The main reason is that while slots are currently every 12 seconds, it is not guaranteed that it won't decrease or change in the future.

Also, remember that slots can be empty. Proof of Stake does not guarantee a block every 12 seconds.

Here is an example of 1 empty slot, and while rarer, it is possible for consecutive slots to be empty.

https://etherscan.io/block/18552554

https://etherscan.io/block/18552555

eth
  • 85,679
  • 53
  • 285
  • 406
  • Thank you for your response! I completely agree with you if you say block.number should not be used as a proxy for time. But even if the block intervals change to a different duration in the future, I believe block.timestamp will remain accurate. This is because it is determined by the protocol itself and is not influenced by the validators, right? – Yleisnero Nov 13 '23 at 18:52
  • I answered generally and could have asked you how you are planning to use the block values, as people usually do calculations with block.timestamp. Otherwise you're right https://ethereum.stackexchange.com/questions/135445/miner-modifiability-of-block-timestamp-after-the-merge (In PoW block.timestamp just had to be greater than its parent https://ethereum.stackexchange.com/questions/5927/how-would-a-miner-cope-with-a-huge-block-time) – eth Nov 15 '23 at 16:16