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

[Julian-dev28]

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.

[Amxx]

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.

[Julian-dev28]

Understandable
Thank you for the reply.

Yeah, I agree. There are some dependencies that gave me a bit of trouble when I tried to make this change locally so I get what you mean when you say it's not as easy as it may seem.

Awesome. Looking forward to it!

[frangio]

Closing this as a duplicate of #3081.

[frangio]

First, I would like to understand the logic behind using block.number > block.timestamp

The reason was to have out of the box compatibility with the tooling that was built around Compound's GovernorAlpha and GovernorBravo.

[Julian-dev28]

Thanks for the update.

Looking forward to the new implementation.