Many Web3 projects use fungible and tradable native tokens for permissionless voting. Permissionless voting can provide many benefits, from lowering barriers to entry to increasing competition. Token holders can use their tokens to vote on a range of issues — from simple parameter tweaks to overhauls of the governance process itself. (For a comment on DAO governance, see “Lightspeed Democracy”) But permissionless voting is vulnerable to governance attacks, where attackers gain voting rights through legitimate means (such as buying tokens on the open market), but for the attacker’s own benefit , using this voting power to manipulate the protocol. These attacks are purely “in-protocol”, which means they cannot be solved cryptographically. Instead, preventing them requires thoughtful mechanism design. To this end, we have developed a framework to help DAOs assess threats and potentially counter such attacks.
Governance Attacks in Practice
The problem of governance attacks is not just theoretical. Not only can they happen in the real world, but they have happened and will continue to happen.
In one prominent example, Steemit, a startup building a decentralized social network on its blockchain, Steem has an on-chain governance system controlled by 20 witnesses. Voters use their STEEM tokens (the platform’s native Taiwanese currency) to select witnesses. While Steemit and Steem are gaining traction, Justin Sun has drawn up plans to incorporate Steem into Tron, the blockchain protocol he founded in 2018. In order to gain the voting rights to do so, Justin Sun found one of the founders of Steem and purchased tokens equal to 30% of the total supply. Once Steem witnesses at the time discovered his purchases, they froze Justin Sun’s tokens. What followed was a public fight back between Justin Sun and Steem to control enough tokens to deploy their preferred list of top 20 witnesses. After involving major exchanges and spending hundreds of thousands of dollars to buy tokens, Justin Sun finally emerged victorious and effectively took control of the network freely.
In another example, Beanstalk, a stablecoin protocol, found itself vulnerable to a governance attack via Flashloan. An attacker borrowed enough Beanstalk governance tokens to pass a malicious proposal in a flash, allowing them to seize Beanstalk’s $182 million in reserves. Unlike the Steem attack, this one happened within a block, meaning it was over before anyone had time to react.
While both attacks occurred in public and in the public eye, governance attacks can also be carried out in secret for extended periods of time. Attackers may create many anonymous accounts, slowly accumulating governance tokens while behaving like other holders to avoid suspicion. In fact, given that many DAOs tend to have low voter participation, these accounts can remain dormant for long periods of time without arousing suspicion. From a DAO perspective, an attacker’s anonymous account can facilitate the emergence of a healthy level of decentralized voting power. But eventually attackers may reach a threshold where these fake wallets have the ability to unilaterally control governance without the community responding. Likewise, malicious actors might gain enough voting power to control governance when turnout is low enough, and then try to pass malicious proposals when many other token holders are inactive.
While we may think that all governance actions are simply the result of market forces at work, in practice governance can sometimes produce inefficient results, the result of incentive failures or other loopholes in the protocol design. Just as government decisions can be controlled by interest groups or even simple inertia, DAO governance can lead to poor outcomes if not properly structured.
So, how do we address this attack through mechanism design?
The fundamental challenge: indistinguishability
The market mechanism for token distribution cannot differentiate between users who want to make valuable contributions to the project and attackers who have high value in sabotaging or otherwise taking control of the project. In a world where tokens can be bought and sold on public markets, the two groups are behaviorally indistinguishable from a market perspective: both are willing to buy large amounts of tokens at increasingly higher prices.
This indistinguishability problem means that decentralized governance is not free. Instead, protocol designers face a fundamental trade-off between overtly decentralized governance and securing their systems from attackers seeking to exploit governance mechanisms. The more freely community members can gain governance power and influence the protocol, the easier it is for attackers to exploit the same mechanism to make malicious modifications.
This indistinguishability problem is familiar in the design of Proof of Stake blockchain networks. That is the case there, the highly liquid market for tokens makes it easier for attackers to gain enough stake to compromise the security of the network. Nonetheless, a mix of token incentives and liquidity design makes proof-of-stake networks possible. Similar strategies can help secure the DAO protocol.
A framework for assessing and addressing vulnerabilities
To analyze the vulnerabilities faced by different projects, we used a framework captured by the following formula:
For a protocol to be considered safe against governance attacks, the attacker’s profit should be negative. When designing governance rules for a project, this equation can serve as a guiding principle for assessing the impact of different design choices. To reduce the incentive to exploit the protocol, the equation implies three clear choices: reduce the value of the attack, increase the cost of gaining voting rights, and increase the cost of executing the attack.
reduce the value of the attack
Limiting the value of an attack can be difficult because the more successful a project is, the more valuable a successful attack is likely to be. Clearly, a project should not deliberately sabotage its own success in order to reduce the value of an attack.
However, designers can limit the value of attacks by limiting the scope of what governance can do. If governance only includes the power to change certain parameters in the project (for example, the interest rate of a lending agreement), then the potential scope of attack is much narrower than when governance allows smart contracts that allow full universal control of governance.
Governance scope can be a function of a project phase. Early in its life, a project may have broader governance as it finds its footing, but in reality governance may be tightly controlled by the founding team and community. As projects mature and control is devolved, it may make sense to introduce some level of friction into governance – at least for the most important decisions requiring large plenary meetings.
Increase the cost of gaining voting rights
A project could also take steps to make it harder to gain the voting power needed for an attack. The more liquid a token is, the easier it is to claim voting rights, so, almost paradoxically, a project may want to reduce liquidity in order to protect governance. One could try to directly reduce the short-term tradability of the token, but this may not be technically feasible.
To indirectly reduce liquidity, projects can offer incentives that make individual token holders less willing to sell. This can be achieved by incentivizing staking, or by giving tokens independent value beyond pure governance. The more value the token holders receive, the more they can align with the success of the project.
Standalone token benefits may include participation in live events or social experiences. Crucially, benefits like this are of high value to individuals aligned with the project, but useless to attackers. Providing such benefits increases the effective price an attacker faces when acquiring tokens: current holders will be less willing to sell due to the independence benefit, which should increase the market price; however, while attackers must pay higher price, but the existence of a standalone function does not increase the value of the token obtained by the attacker.
Increase the cost of executing an attack
In addition to increasing the cost of voting rights, friction can be introduced that makes it difficult for attackers to exercise voting rights even after acquiring tokens. For example, a designer could require some kind of authentication for users participating in a vote, such as a KYC (know your customer) check or a reputation score threshold. We could even limit the ability of unauthenticated actors to get voting tokens in the first place, perhaps requiring some existing validators to prove the legitimacy of the new party.
In a sense, this is exactly how many projects distribute their initial tokens, ensuring that trusted parties control a fair share of voting power. (Many proof-of-stake solutions use similar techniques to defend their security—strictly controlling who has access to early staking, and then gradually decentralizing from there.)
In addition, projects can allow attackers to face difficulties in passing malicious proposals even if they control a large amount of voting power. For example, some projects have timelocks that prevent a token from being used for voting for a period of time after it has been exchanged. As a result, attackers seeking to buy or borrow large amounts of tokens will face the additional cost of waiting before the actual vote — and the risk that voting members will notice and thwart their intended attack in the meantime. Authorization is also helpful here. By giving active but non-malicious participants the right to vote on their behalf, individuals who do not want to play a particularly active role in governance can still contribute their voting power to securing the system.
Some programs use veto power, allowing voting to be delayed for a period of time to alert inactive voters to a potentially dangerous proposal. Under such a scheme, even if an attacker makes a malicious proposal, voters have the ability to respond and close it. The idea behind these designs and similar ones is to deter attackers from sneaking through malicious proposals and give the project’s community time to develop a response. Ideally, proposals that are clearly in the protocol’s interest would not have to face these roadblocks.
For example, in the Nouns DAO, the veto power is held by the Nouns Foundation until the DAO itself is ready to implement an alternative model. As they write on their website, “The Nouns Foundation will veto proposals that pose significant legal or existential risks to the Nouns DAO or the Nouns Foundation.”
Projects must strike a balance that allows a degree of openness to community changes (which may sometimes be unwelcome), while not allowing malicious proposals to slip through the cracks. Often it takes only one malicious proposal to bring down a protocol, so it is critical to have a clear understanding of the risk tradeoffs of accepting and rejecting a proposal. Of course, there is also a high level of trade-off between securing governance and making governance possible – any mechanism that introduces friction to deter potential attackers will of course also make the governance process harder to use.
The solutions we outline here fall on the spectrum between fully decentralized governance and the ideal of partially sacrificing some decentralization for the overall health of the protocol. Our framework highlights the different paths projects can take as they seek to ensure governance attacks are not profitable. We hope that the community will use this framework to further develop these mechanisms through their own experiments to make DAOs more secure in the future.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/a16z-how-to-identify-evaluate-and-avoid-dao-governance-attacks/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.