question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Possible change: block.number to block.timestamp in Governance contracts

See original GitHub issue

Hey all,

During a conversation on discord, the Avalanche team discovered that there may be an opportunity to contribute to a Governance contract from OpenZeppelin in a way that would benefit our developers.

The contract above uses block.number as a timestamp which is unsuitable for users on networks such as Avalanche due to its volatile block production.

summary here

…Avalanche nodes only work when there is work to be done. There’s no mining or polling to get new blocks. Transactions are broadcast to the wider network, who then hears them and begins voting. If there are no transactions to vote on, the nodes in the network don’t do anything except listen until new transactions are heard.

Aside from allowing our users to implement this contract into their projects, we find that using block.timestamp will benefit Open Zeppelin’s Smart Contract users by reducing the possible security risk posed by using block.number.

Consensys has stated the following regarding block.number

If the scale of your time-dependent event can vary by 15 seconds and maintain integrity, it is safe to use a block.timestamp.

Avoid using block.number as a timestamp

It is possible to estimate a time delta using the block.number property and average block time, however this is not future proof as block times may change (such as fork reorganisations and the difficulty bomb). In a sale spanning days, the 15-second rule allows one to achieve a more reliable estimate of time.

📝 Details Thank you for taking the time to read this.

First, I would like to understand the logic behind using block.number > block.timestamp in this case, and then verify that there is an opportunity to make this change.

To implement this change we would replace all block.number values with block.timestamp where applicable and with special attention to Governance related contracts.

Issue Analytics

  • State:closed
  • Created a year ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

2reactions
Amxxcommented, Jul 13, 2022

Hello @Julian-dev28

This was discussed many times, and it is on our roadmap. Unfortunatelly, its not as simple as you make it look. Changing the governor alone is not enough, you also need the voting token to move to timestamps.

Having a timestamp governor query a block.number token would be catastrophic.

I’m working on a draft ERC. I’ll try to remember to share it here so you can provide feedback.

1reaction
frangiocommented, Jul 14, 2022
Read more comments on GitHub >

github_iconTop Results From Across the Web

Using block.number vs block.timestamp in Governor.sol
I'd like to understand the reason behind choosing block.number > block.timestamp in for this and other Governance contracts. Thanks in advance.
Read more >
Smart Contract Best Practices Revisited: Block Number vs ...
In this article, we are going to explore the block number and timestamp on the EVM, how they are used to ascribe event...
Read more >
What Is a Timelock Contract? - Halborn
Block producers control timestamp values (the only rule is that the timestamp for a new block must be strictly greater than the previous...
Read more >
Can block.timestamp value change during execution?
Values such as block.timestamp and block.number are, as expected, based on the block. So one block always has the same data.
Read more >
Differences between Ethereum and Optimism - Optimism Docs
See section on Block Numbers and Timestamps for more information. ... it is possible for a user to create a contract on L1...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found