Thanks all for the comments!
I’ll move the discussion here; to enable everyone to continue discussing the merits of upgrading the governance smart contracts and the DVP-Quorum proposal.
The first thing to mention is that changing how Quorum is computed and working on increasing active voting power / increased delegation is not mutually exclusive. They are complementary, certainly if the quorum threshold seeks to remain relevant into the long term. We should focus on increasing delegation by tokenholders as well.
@castlecapital: Firstly, it does not recognise the growing issue of voter apathy or seek to address the stagnation in the DAO’s delegated voting power - something we know there is a clear need for and should focus on before discussing altering quorum calculations. We have seen informal delegation events happen in the past, and encourage the DAO, the Foundation and OCL to do more in this regard.
One of the surprising results of the report, as seen in Figure 4, is that voter apathy has actually gone down over time. Still, we need to make sure apathy of voting power continues to be reduced while increasing total delegated tokens beyond what it is currently.
@castlecapital: Secondly, the proposed solution is entirely novel and untested, and therefore likely has not had various edge cases hypothesised and tested for attack surfaces.
The motivation for this report, alongside the vote to continue working on it, is to allow the DAO to decide whether we should focus on building it out, but also to continue evaluating the mechanism alongside any issues that arise. The vote should not be considered an end-state where there is no longer any evaluation on its security or the wider implications.
@krst: This process would be inherently costly - it requires not only smart contract development, but also thorough audits and updates to all tooling that currently relies on existing calculations, such as Tally, Proposals.app, and various dashboards displaying these values. We recall a similar situation in Optimism almost two years ago, where governance contract upgrades resulted in numerous governance tools breaking across the ecosystem.
There is currently a getter function for fetching quorum by block number. So, assuming partners are using the getter function, then they should not have an issue if DVP-Quorum is implemented. I do agree though, we should work with partners to make sure there are not any unexpected implications if the smart contracts are upgraded and of course make sure they are resolved before any on-chain vote or upgrade.
@krst: We are not suggesting that upgrades should never be made, but they should not be undertaken lightly. If we proceed with one, we should consider what other features could be included in such an upgrade. From the top of our minds, examples include partial delegation and private voting or flexible voting—both of which were identified as missing features necessary for the proper implementation of staking mechanisms.
I (personally) do not have a strong opinion on flexible voting or partial voting.
Private voting, on the other hand, is exceedingly difficult to achieve. The first problem is that private voting impacts autonomy as it either relies on an external tallying authority who can halt the vote or it implement a proof-of-work scheme (time puzzles) that is computationally expensive. It is possible to implement self-tallying with voter privacy, but it does not scale beyond a small set of parties (<10). The bigger problem, which I’ve only recently discovered, is that even if you do implement private voting, where the ballots are secret but the final tally is published, the unique characteristics of weighted voting allows an adversary to still break voter privacy and link votes to voters.
With all that in mind, I’d advise against private voting anytime soon, especially if we want to maintain true on-chain autonomy. The scale of problems that arise far outstrip anything we see with DVP-Quorum, it is just a totally different ball game.
@krst: Finally, we believe that alternative mechanisms should be explored before adopting a complete redesign. For example, the Auto-Abstaining Wallet model, implemented by Scroll DAO, presents an interesting approach. It mitigates quorum issues without requiring fundamental contract upgrades, thereby limiting the impact on external systems and reducing additional security risks. Arbitrum could benefit from a more thorough analysis of this model before committing to an approach as impactful as DVP Quorum.
This suggestion has popped up a few times during the discussion.
It is effectively the same as lowering quorum by a fixed amount, where the abstainer can decide whether it should be lowered or not. This can be done even as a short-term solution, but it is also acknowledging that Quorum is too high and it should be lowered under certain conditions. This introduces further considerations for the abstainer’s role down the line. For example, the abstainer might lower quorum if there is strong agreement on the ‘FOR’ side, but not if the abstainer perceives the vote as a hostile takeover.
I’m aware there are mixed opinions in the DAO about taking ARB from the treasury for the purpose of voting. My preference is to find a viable solution to computing quorum, so it isn’t required.