Governance: voters weights add-in

[SebastianBor]

Summary

The purpose of this change is to support voter weights provided by an external program (addin). This would allow to move away from a simple token deposit based weights and make it possible to provide custom strategies without the need to modify the governance program (open/close principle).
The following voter weight addins are planned (not part of this PR):

• Time locked token deposits
• Time locked token deposits with multiple locks (ex. 1mm locked for 4 years and 1k locked for 1year)
• Token freezing instead of deposits
• Multiple tokens deposits
• NFTs deposits
• Reputation score

Solution

• VoterWeight addin interface was defined using VoterWeightRecord account. Governance program reads the account to get voter's weight instead of using the internal deposit pool.
• Each addin program manages their own VoterWeightRecord accounts
• The Governance program stores the chosen addin program id in RealmConfig extension account and flags it in realm config use_community_voter_weight_addin
• Sample voter-weight-addin program is provided as a template for creating custom addins

Time sensitive voter weights

VoterWeightRecord has expiry flag for time sensitive voter weights. When the up to date voter weight needs to be calculated at the time of voting the client (UI) would call Revise instruction for the addin with all the needed accounts within the same transaction as the governance instruction and the addin would set the expiry to the current slot. Then the governance instruction would validate the expiry to ensure it uses up to date weight.
This way any custom logic can be supported and the addins might use any arbitrary set of accounts and current time to calculate the up to date voter weight.

Alternative solution I was considering was to make a CPI call from the governance program to the addin program to get voter's weight, but that would need a custom set of accounts to be provided in all but trivial scenarios, and I decided the Revise instruction with vote_weight_expiry was a simpler solution and would cover any arbitrary scenario.

[joncinque]

It took me awhile to understand it all, but I think the approach is sound. My main question is about the provided skeleton program, and whether it'll actually move tokens. A lot of the logic in DepositGoverningTokens relies on governance info, so you'll have to be careful duplicating those parts. There's also the problem with topups / relinquishes, and making sure that it's reflected in vote records.

I wonder if there's some nice refactoring that can be done for the deposit / withdraw logic, so that the governance program reuses bits of the basic addin.

[SebastianBor]

It took me awhile to understand it all, but I think the approach is sound. My main question is about the provided skeleton program, and whether it'll actually move tokens. A lot of the logic in DepositGoverningTokens relies on governance info, so you'll have to be careful duplicating those parts. There's also the problem with topups / relinquishes, and making sure that it's reflected in vote records.

I wonder if there's some nice refactoring that can be done for the deposit / withdraw logic, so that the governance program reuses bits of the basic addin.

Your observations are correct, the provided add-in skeleton is not a full working example yet. For this PR I implemented only the bare minimum to make it possible to use it in governance tests. I'm planning to do the full end to end implementation in the next PR.

And yes, it's a good idea to make the common code to create add-ins reusable. Since the add-in has dependency on the governance program (and knowledge about it) I think it could just reference the spl-governance crate, but we could also create a crate with just the reusable utilities. I'm not sure which one would be better yet.

Note, when the add-in is used it doesn't eliminate need for TokenOwnerRecord. It's still used to track realm members, their active proposals, active votes and allows to use governance delegates. And it's still the governance program responsibility to manage all of that. This is why CreateTokenOwnerRecord instruction was created as part of this PR to make it possible to create the account without depositing any tokens.

[joncinque]

Sorry for the late re-review -- most of the points are cosmetic, and the overall concept behind this is sound. Do add the build.rs file to remove that *.so in the repo please!

[SebastianBor]

Sorry for the late re-review -- most of the points are cosmetic, and the overall concept behind this is sound. Do add the build.rs file to remove that *.so in the repo please!

Thank you, I've addressed the issues in a follow up PR #2512