a16z: How to avoid DAO governance attacks

Many web3 projects use homogenized and tradable native tokens for permissionless voting. Permissionless voting has many benefits, from lowering barriers to entry to increasing competition. Token holders can use their tokens to vote on a range of issues, ranging from simple parameter adjustments to overhauls of the governance process itself. However, permissionless voting is vulnerable to governance attacks, where attackers gain voting power through legitimate means (such as buying tokens on the open market) and use that voting power to manipulate the protocol for the attacker’s own benefit. These attacks are purely “in-protocol” attacks, which means they cannot be solved cryptographically. Instead, preventing these attacks requires thoughtful mechanism design. To this end, we have designed a framework to help DAOs assess threats and respond to potential governance attacks.

Attacks on governance in practice

The problem of governance attacks is not just theoretical. Not only can they happen in the real world, but they have and will continue to happen.

Let’s look at this obvious example. Steemit is a startup building a decentralized social network on its blockchain Steem, with an on-chain governance system controlled by 20 witnesses. Voters use their STEEM tokens (the platform’s native token) to choose witnesses. When Steemit and Steem became more and more attractive, Justin Sun made plans to incorporate Steem into Tron. Tron is the blockchain protocol he founded in 2018. To gain voting rights, Sun approached one of Steem’s founders and purchased tokens equal to 30% of the total supply. When Steem witnesses discovered his transaction, they immediately froze Sun’s tokens. What followed was a public back-and-forth between Sun and Steem to control enough tokens to allow him to choose the top 20 witnesses he wanted. After engaging in major transactions and spending hundreds of thousands of dollars to buy tokens, Justin Sun finally emerged victorious and effectively had free reign over the network.

Take another look at the Beanstalk example. Beanstalk is a stablecoin protocol that was found to be vulnerable to Flashloan governance attacks. The attackers took out a loan to get enough Beanstalk governance tokens to immediately pass a malicious proposal that would allow them to seize Beanstalk’s $182 million in reserves. Unlike the attack on Steem, this one happened on the scale of a single block, meaning it was over and no one had time to react yet.

While both attacks occurred in public and in the public eye, governance attacks could also be carried out in secret for extended periods of time. Attackers may create large numbers of anonymous accounts and slowly accumulate governance tokens while behaving as normal as any other holder in order to avoid exposure. 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 the DAO’s perspective, the attacker’s anonymous account may help to show a healthy level of decentralized voting power. However, attackers could eventually reach a threshold at which these witch wallets have the power to unilaterally control governance without the community being able to react. Likewise, when turnout is low enough, malicious actors may gain enough voting power to control governance and then try to pass malicious proposals when many other token holders are inactive.

While we might think of all governance actions as simply the result of market forces at play, in practice governance can sometimes be inefficient as a result of incentive failures or other loopholes in protocol design. Just as government policymaking can be swayed by interest groups or simple inertia, DAO governance can also lead to poor outcomes if not properly structured.

So, how do we deal with this attack through mechanism design?

Fundamental Challenge: Indistinguishability

The market mechanism for token distribution cannot distinguish between users who want to make valuable contributions to the project and attackers who want to interfere or otherwise control the project. In a world where tokens can be bought and sold on public markets, the behavior of both groups is 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 comes with a price. Instead, protocol designers need to make a fundamental trade-off between openly decentralized governance and protecting their systems from attacks that attempt to exploit governance mechanisms. The more freedom community members have to gain governance power and influence the protocol, the easier it is for attackers to use the same mechanism to make malicious changes.

This indistinguishability problem is common in the design of proof-of-stake blockchain networks. Additionally, a highly liquid market in tokens makes it easier for attackers to gain enough stake to compromise the security of the network. Nonetheless, the combination 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 dealing with vulnerabilities

To analyze the vulnerabilities faced by different projects, we use a framework captured by the following formula:

Illustrated low-confidence descriptions are automatically generated

Ensuring the protocol is immune to governance attacks should make the attackers’ profits negative. When designing governance rules for a project, this formula can be used to guide the assessment of 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 the project, the more valuable the attack. Clearly, a project should not deliberately sabotage its own success in order to reduce the value of an attack.

Nonetheless, designers can limit the value of attacks by limiting the scope of governance. If governance only includes the power to change certain parameters in the project (for example, interest rates on loan agreements), the scope of potential attacks is much narrower than when governance allows full control over smart contracts.

The governance scope can be a function of the project phase. In the early days of a project, when the project finds its footing, it may have broader governance, but in practice governance may be tightly controlled by the founding team and community. As the project matures and control decentralizes, it may be positive to introduce some level of friction in governance – at least a large quorum is required to make the most important decisions.

Increase the cost of gaining voting rights

Projects can also take steps to make it more difficult for attackers to gain the voting power they need to attack. The more liquid a token is, the easier it is to claim voting rights – so almost paradoxically, projects may want to reduce liquidity in order to protect governance. We could directly try to reduce the short-term tradability of the token, but this may not be technically feasible.

To indirectly reduce liquidity, projects can provide incentives that make individual token holders less willing to sell tokens. This can be achieved by incentivizing staking or giving tokens a value independent of 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 face-to-face events or social experiences. Crucially, such benefits 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 are less willing to sell, as the benefit of independence increases the market price; however, while attackers must pay a higher price, independence The existence of the benefit does not increase the value that the attacker can obtain after obtaining the token.

Increase the cost of executing an attack

In addition to increasing the cost of voting rights, friction can be introduced that makes it harder for attackers to exercise voting rights, even if they have acquired tokens. For example, designers can require some kind of user authentication to participate in voting, such as KYC verification or reputation score thresholds. It is even possible to restrict the ability of unauthenticated participants to obtain voting tokens in the first place, possibly requiring some existing validator nodes to verify the legitimacy of new participants.

In a sense, this is exactly how many projects distribute their initial tokens, ensuring that trusted parties control a significant portion of voting power. (Many proof-of-stake solutions use similar techniques to secure themselves—strictly controlling who gets early stakes, and then gradually decentralizing from there.) 

Alternatively, projects can do so, and even if attackers control a significant amount of voting power, they still face many difficulties in passing malicious proposals. For example, some projects have time locks so tokens cannot be used for voting for a period of time after the swap. As a result, attackers trying to buy or borrow large amounts of tokens will face the additional cost of waiting to vote — and the risk that voting members will notice and block their potential attacks in the meantime. In this regard, delegations can also help. By giving active but non-malicious participants voting rights, individuals who do not want to play a particularly active role in governance can still use their voting rights to secure the system.

Some projects use veto powers, allowing voting to be delayed for a period of time to alert inactive voters to potentially dangerous proposals. Under this scheme, even if an attacker makes a malicious proposal, voters have the ability to respond and close it. The idea behind these and similar designs is to deter attackers from sneaking through malicious proposals and give the project community time to respond. Ideally, proposals that are clearly in the protocol’s interest would not have to face these hurdles.

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 governance 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 proposal loopholes. Often it only takes a malicious proposal to invalidate a protocol, so having a clear understanding of the risk trade-offs for accepting and rejecting a proposal is critical. Of course, there is a high trade-off between securing governance and enabling governance—any mechanism that introduces friction to deter potential attackers will of course also make the governance process more challenging.

The solution we outline here is somewhere between fully decentralized governance and partially sacrificing some desirable decentralization for the overall health of the protocol. Our framework highlights the different paths projects can take in an attempt to ensure that governance attacks are unprofitable. We hope that the community will start leveraging this framework and 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-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.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-07-29 10:10
Next 2022-07-29 10:11

Related articles