feat: Add minimal approval configuration

[clauBv23]

Task ID: OD-1451

TBD:

• The new updateMinApproval permission id should be UPDATE_VOTING_SETTINGS_PERMISSION_ID or a new one should be created?
• Old initialize function on Token voting should revert or continue allowing initialize the plugin without minApproval value?

[nivida]

Is it possible to have this event defined in the interface?

[clauBv23]

I'm not entirely certain about the approach we're taking with this, but I noticed that VotingMinApprovalUpdated](

token-voting-plugin/packages/contracts/src/MajorityVotingBase.sol

Lines 262 to 274 in 65198a0

	/// @notice Emitted when the voting settings are updated.
	/// @param votingMode A parameter to select the vote mode.
	/// @param supportThreshold The support threshold value.
	/// @param minParticipation The minimum participation value.
	/// @param minDuration The minimum duration of the proposal vote in seconds.
	/// @param minProposerVotingPower The minimum voting power required to create a proposal.
	event VotingSettingsUpdated(
	VotingMode votingMode,
	uint32 supportThreshold,
	uint32 minParticipation,
	uint64 minDuration,
	uint256 minProposerVotingPower
	);

) was defined in the contract rather than the interface.

Given that events are not part of the interface ID, I believe it’s reasonable to define them in the interface. However, for the sake of consistency, I lean to keep it here unless you have a strong reason to move it to the interface.

[nivida]

Are we always doing breaks for function arguments or not? I see a small inconsistency here :-)

[clauBv23]

It will depend on the line length (100 - 120).
If there are too many arguments will break into lines, if not it should be on the same one.
In this case, there is a single argument but the modifier name on the auth function increases the line length and breaks in lines

[novaknole]

small incosistency. name them the same.

[clauBv23]

done f7e0f97

[novaknole]

you still use _minApproval instead of _minApprovals. hahaha

[novaknole]

and rename the function as well to _updateMinApprovals.

[clauBv23]

hopefully all are renamed now 92070c4 9b6cf85

[novaknole]

What's the reason for going with uint32 instead of uint256 ? I wonder the reason in your mind was that in the future, if we add more state variable, they would be tightly packed ? If that's the reason, I think it's a wrong reason.

packing only makes good and efficient sense if state variables are stored in the same tx. I highly doubt that whatever new state variable we add, that value and minApprovals value would be updated in the same tx. From the solidity docs:

If you are not reading or writing all the values in a slot at the same time, this can have the opposite effect, though: When one value is written to a multi-value storage slot, the storage slot has to be read first and then combined with the new value such that other data in the same slot is not destroyed.

Up to you as I haven't thought this very deep, but from first impression, that's the impression I got.

[novaknole]

Also, can you remind me of why we can not put this state variable inside VotingSettings struct ?

[clauBv23]

I went with uint32 mainly because minParticipation and supportThreshold the other ratios we already store are defined as uint32.
At some point questioned it because an extra operation is needed for casting the value every single time, however just continued with uint32 for consistency among the ratios.

 

Didn't store it inside VotingSettings because it is being received as a parameter for several functions:

• __MajorityVotingBase_init: is not important because is not on any interface id.
• initialize: that is in TOKEN_VOTING_INTERFACE_ID but we are already overriding it so we can manage it.
• updateVotingSettings: that is in IMajorityVoting interface, adding a new entry to the struct will change the function selector, and even if we implement erc165 with both IDs, we still need to "support" the old function which has a no longer existent struct.

A new struct could be created to add this parameter and deprecate the old one, but to be honest, I don't have a strong opinion on this, neither option is clean.

[novaknole]

I went with uint32 mainly because minParticipation and supportThreshold the other ratios we already store are defined as uint32.

This was because of packing, but for new minApproval, no packing needed. I'd go with uint256.

As for other question, I missed this detail and yes, I think we don't have any better way. Have to think this through

[clauBv23]

I also agree to go with uint256 done in 4ce4388

[novaknole]

1st ROUND.

[clauBv23]

Suggested change

	/// @notice The ID of the permission required to call the `updateVotingSettings` function.
	/// @notice The ID of the permission required to call the `updateVotingSettings` and `updateMinApprovals` functions.

[evanaronson]

@clauBv23 - sorry for the long delay in getting to this review. Functionally this looks like it works as specified in the requirements.

The only thing that really makes me uncomfortable is not including minApprovals in the voting setting struct. It is a governance setting just like the others, so having it separate, and with its own permission doesn't make any practical sense.

Will this always be a problem when we want to extend the functionality of existing plugins? Are there any other product inputs that can help inform how to improve this decision?