[evm] HubVotePool: Spoke vote limiter

[djb15]

A defence in depth measure to allow a permissioned entity to set the maximum voting power for each spoke.

This is intended to be a temporary measure, and it can be easily reversed by pulling out this commit (or alternatively this commit lives on a fork), redeploying the HubVotePool without these change, and creating and executing a proposal to update the HubVotePool the HubGovernor points to.

The intended permissioned entity is the Wormhole Governance contract controlled by the Guardians, but initially the entity is decided by the deployer to allow for an initial sensible configuration based on the current distribution of tokens.

[0kage-eth]

This looks good to me as a security measure but I also see some side-effects to this.

In a dynamic environment with continuous token flows cross-chain, is there a risk that the voting power becomes out-of-sync with actual token distribution across chains? I see two possibilities:

1. A spoke chain could have more actual tokens than its votingPower allocation, preventing legitimate votes - this looks like a potential downside to this new design...
2. A spoke chain could have fewer actual tokens than its votingPower, though this is less concerning since votes are still limited by actual token holdings

If the owner becomes WH Governance, then any change to voting power will go through execution timelock - will that make syncing even more challenging?

[djb15]

@0kage-eth Thanks for your review of this change, appreciate it!

Yep both of these points are true and are indeed constraints of the changes. In the first case, the admin would be able to come in and bump the voting power of the chain to ensure legitimate vote delivery before the proposal voting deadline. The second case is the case we always want to be in in the ideal world. We want to set the voting powers to be greater than the current voting power, with some buffer. These changes are included to prevent infinite vote delivery from a connected spoke, but there is no requirement for a completely in-sync relationship. To operate this effectively there needs to be some off-chain monitoring to keep track of token balances across different chains. It's not the perfect solution by any means, but it should be an effective short term backstop in the worst case; a critical voting bug allowing a single spoke to vote through a malicious proposal.

And re the owner point, the admin for the voting powers will not be the multigov timelock for exactly the reason you mention. It will be a permissioned entity, likely the Wormhole Governance contract (which is a separate contract controlled by the guardians, not by the W token).

[0kage-eth]

Agree. As a short term feature with continuous off-chain monitoring, this is a good practical solution.

[djb15]

Discussed further internally, we think the canceller role on the timelock is a sufficient backstop for our deployment, given the distribution of W between spokes. Closing this PR for now, we can revive in the future if opinions change