Possible change: block.number to block.timestamp in Governance contracts
See original GitHub issueHey 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.
…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:
- Created a year ago
- Comments:5 (3 by maintainers)
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.
Closing this as a duplicate of https://github.com/OpenZeppelin/openzeppelin-contracts/issues/3081.