Use `NoncesKeyed` in Governor for Voting by Sig

[arr00]

🧐 Motivation

Using a nonce in addition to proposal id in governor makes it hard to have a functional vote by sig service. This is because votes by sig must have a sequential nonce with no gaps or repeats--if a user decides to take one of their votes by sig on-chain, all other pending votes they have are invalidated. This isn't the desired flow and it isn't necessary.

📝 Details

openzeppelin-contracts/contracts/governance/Governor.sol

Line 583 in ca7a4e3

_hashTypedDataV4(keccak256(abi.encode(BALLOT_TYPEHASH, proposalId, support, voter, _useNonce(voter)))),

This line asserts that votes by sig have sequential nonces which isn't actually necessary. The OZ governor introduces voting by nonce as it is possible that a user would vote multiple times for a single proposal id (so the proposal id can't be the only source of entropy).

It is, however, useful to ensure that a sequence binds together votes on a specific proposal. We should use NoncesKeyed with the key being the proposal id and allow for the 0 key to continue working (no breaking changes).

[tushar994]

I would like to implement this, This is the way I think it should be implemented, based on the information in the issue.

In order to maintain backward compatibility, we will leave the castVoteBySig and the castVoteWithReasonAndParamsBySig function untouched.

We will create two new functions that use Nonces keyed by the proposal id.

• castVoteBySigWithNonceKeyedByProposalId
• castVoteWithReasonAndParamsBySigWithNonceKeyedByProposalId

we'll create two new constants

bytes32 public constant BALLOT_TYPEHASH_NONCE_KEYED_BY_PROPOSAL_ID =
        keccak256("Ballot(uint256 proposalId,uint8 support,address voter,uint256 nonceKeyedByProposalId)");
bytes32 public constant EXTENDED_BALLOT_TYPEHASH_NONCE_KEYED_BY_PROPOSAL_ID =
        keccak256(
            "ExtendedBallot(uint256 proposalId,uint8 support,address voter,uint256 nonceKeyedByProposalId,string reason,bytes params)"
        );

we'll use these as prefixes to the signature data for our two new functions.

we'll replace Nonces with NoncesKeyed in the contract, and use 0 keys in the legacy functions, and the proposal id as the key in the new functions.

please let me know if that sounds good, ill make a PR if it does. thank you!!

[arr00]

Thanks for your interest here @tushar994! I only saw your comment after creating a PR myself for this issue--feel free to review it (#5574).