Using block.number vs block.timestamp in Governor.sol

Support Contracts
1

Hey all,

During a conversation on discord, the team discovered that there may be an opportunity to contribute to a Governance contract Governor.sol from OpenZeppelin in a way that would benefit Avalanche 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

...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. This means block production can vary depending on how many transactions are being executed on the network.

Consensys has also mentioned that using block.number may pose a security risk

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.

I'd like to understand the reason behind choosing block.number > block.timestamp in for this and other Governance contracts.

Thanks in advance

1 Like
2

I was planning to use the Governor library on an Avalanche Subnet in the near future, so I'd really like to understand this topic better as well.

2 Likes
3

They are tracking this issue here

Cheers!

1 Like