Sometimes, Vitalik likes to mention the Hive fork from Steem when talking about game theory in blockchain consensus and governance. He did so again today on his blog. Here's the link: Moving beyond coin voting governance.
Vitalik is also famous for criticizing delegated Proof of Stake by saying it will lead to bribery and voting cartels. Today, he presented a much more balanced view. It is a must-read if you are interested in governance and decentralization.
Hive's governance is at risk
The number one argument in favor of Hive's DPOS is the lockup. It takes 13 weeks to power down, so investors who stake are incentivized to act with a long-term view that benefits hive. Any person engaging in vote selling is hurting their own stake.
However, this argument will soon be meaningless once Hive.loans launches.
For those who don't know, hive.loans will be a way to use a hive account as collateral, enabling the exchange of an account with hive power for liquid hive by giving up the private keys.
This opens up the possibility of vote-selling on hive as short-term incentives become stronger. Vitalik also mentioned lockups as an ineffective way to enforce coin voting governance:
Some DAO protocols are using techniques like timelocks to limit one's ability to participate against these kinds of attacks, but ultimately timelocks are bypassable; as far as security systems go, timelocks are more like a paywall on a newspaper website than they are like a lock and key.
He also links to a great article on timelocks and their problems: Bypassing Smart Contract Timelocks.
In Hive's case, the power down can only be bypassed through centralized services because hive doesn't support smart contracts on layer 1. This will probably mean that bypassing the lockup will cost a fee, which is better than nothing and provides some long-term incentive for investors. But it isn't enough.
I personally believe that right now, Hive is in a fantastic place regarding its governance. The token is well distributed, and I don't know any significant bad actor with massive influence engaging in vote selling.
However, this doesn't mean that it will always remain so. We need to take measures in advance to have sound governance forever because hard forking is very painful and should be the ultimate last resort measure.
Solutions
In his blog, Vitalik talks about many solutions grouped under 3 categories.
- Limited governance
- non-coin-voting governance
- Skin in the game
Solution two requires either Proof of personhood, which means KYC accounts, or Proof of participation, a way to verify that a human has a single account even if we don't know who it is.
Both of these solutions are unlikely to be applicable on hive. KYC accounts are not a solution. I believe most people here would agree that this is not wanted. In addition, I can't see Proof of Participation working well enough to prevent people from creating two accounts and gaming the system. Maybe that will be possible in the future, but there are no concrete examples right now.
So we can eliminate solution 2 from the discussion.
Solution 1: limited governance
I found two of Vitalik's propositions to be interesting for hive.
Adding time delays: Hive already does this. A recent powerup cannot affect governance. 30 days are needed for the stake to begin being useful. This is very effective against malicious powerups from exchanges like Binance did in the Steem takeover.
However, what if a large stake is powered up anonymously without declaring any intentions? Someone could power up millions of hive and wait 30 days without talking to anyone or casting any governance vote. Once the time delay expires, one could suddenly make a big vote with harmful consequences.
Therefore, Vitalik's proposed time delay could be beneficial on hive:
a governance decision made at time T only takes effect at eg. T + 90 days. This allows users and applications that consider the decision unacceptable to move to another application (possibly a fork)
For instance, we could add a time delay for protocol hardforks. If 17 witnesses approve a hardfork, then it doesn't happen for 30 days. If the chain is under attack, we can hardfork to another chain while avoiding consequences.
This would have been EXTREMELY useful in the Steem takeover because a 30-day time delay would have allowed witnesses and whales like 
Be more fork friendly: When under attack, forking is a stressful operation, I'm sure many of us remember.
Setting up most of the dev work in advance can be done. There could be a step-by-step guide on how to hardfork hive, and we could even set some emergency DAO funds that could be unlocked only for such reasons. Obviously, it's impossible to unlock funds in a decentralized way when under attack, so The DAO emergency fund could be unlocked according to a snapshot of the hive voting stake taken a month ago.
For example, Justin Sun somehow takes over hive again. He now has a majority stake. We want to fork and unlock the emergency fund to sell as much hive as possible and use it for the next hardfork.
To unlock the fund, we need approval from 17 old witnesses voted in a month before the takeover, and we need x% of the staked hive one month ago to approve the emergency unlock.
This would be a significant disincentive for attackers, as they will get dumped on very heavily. Furthermore, they can't confiscate those funds, assuming we also implemented the fork delay, because they can't change the rules in a minute.
Solution 3: skin in the game
As mentioned before, the power down time is no longer enough as we will bypass it. So we need skin in the game for day-to-day voting to provide the right long-term incentives instead of short-term vote selling.
We have already succeeded at this for reward pool distribution. We got rid of vote-selling and bid bots by tweaking the parameters to encourage better curation with the EIP on hardfork 21 (I might be wrong about that number).
We now need to do this for governance voting, as the effectiveness of the power down will disappear soon. Vitalik proposed 3 different strategies which are already well researched or implemented.
I honestly cannot judge how effective those strategies can be or how difficult it is to implement them. But I think the community should start to think about this and propose similar or different solutions before we become a complete mess like EOS.
Comment below any idea you have or make posts about that. The sooner we come up with something concrete, the less risk we take. Layer 0 won't last forever.