Original Compilation: Old Yuppie

Original Compilation: Old Yuppie

Many Web3 projects use fungible and tradeable native tokens for permissionless voting. Permissionless voting can provide many benefits, from lower barriers to entry to increased competition. Token holders can use their tokens to vote on a range of issues - from simple parameter adjustments to overhauls of the governance process itself. (For a review of DAO governance, see "Lightspeed Democracysecondary title

Governance Attacks in Practice

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

In a 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 dollar) to select witnesses. While Steemit and Steem are gaining traction, Justin Sun has laid out plans to merge Steem into Tron, the blockchain protocol he founded in 2018. To gain the voting rights to do so, Justin Sun approached one of the founders of Steem and purchased tokens equivalent to 30% of the total supply. Once the Steem witnesses at the time found out about his purchases, they froze Justin Sun's tokens. What followed was a public fight between Justin Sun and Steem to control enough tokens to deploy their favorite top 20 witness list. After involving major exchanges and spending hundreds of thousands of dollars on tokens, Justin Sun eventually emerged victorious and effectively took free control of the network.

In another example, Beanstalk, a stablecoin protocol, found itself vulnerable to governance attacks via Flashloan. An attacker obtained enough of Beanstalk's governance tokens through loans to pass a malicious proposal in an instant, allowing them to seize $182 million in Beanstalk's reserves. Unlike the Steem attack, this one happened within a block, meaning it was over before anyone had time to react.

While these two attacks took place in the open and out of public view, governance attacks can also be carried out in secret for extended periods of time. An attacker could create many anonymous accounts, slowly accumulating governance tokens while behaving like other holders to avoid suspicion. In fact, given the often low voter participation in many DAOs, these accounts can remain dormant for long periods of time without arousing suspicion. From a DAO perspective, an attacker's anonymous account could 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 being able to respond. Likewise, malicious actors may gain enough voting power to control governance when turnout is low enough, and then attempt 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 work, in practice governance can sometimes produce inefficient outcomes as a result of incentive failures or other loopholes in protocol design. Just like government decisions can be dominated by interest groups or even simple inertia, poorly structured DAO governance can lead to poor outcomes.

secondary title

The Fundamental Challenge: Indiscernibility

The market mechanism for token distribution fails to distinguish between users who want to make valuable contributions to the project and attackers who place a high value on disrupting or otherwise controlling the project. In a world where tokens can be bought and sold on the public market, the two groups are behaviorally indistinguishable from a market perspective: Both are willing to buy large quantities of tokens at increasingly higher prices.

This indistinguishability problem means that decentralized governance does not come for free. Instead, protocol designers face a fundamental trade-off between open 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.

secondary title

A Framework for Assessing and Addressing Vulnerabilities

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

secondary title

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 scope of potential attacks is much narrower than when governance allows full universal control over the governing smart contracts.

secondary title

Increase the cost of obtaining 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, projects may wish to reduce liquidity in order to protect governance. One could try to directly reduce the short-term tradability of tokens, but this may not be technically feasible.

To indirectly reduce liquidity, projects can provide incentives to make individual token holders less willing to sell. This can be achieved by incentivizing staking, or by giving tokens an independent value that goes beyond pure governance. The more value token holders receive, the more aligned they are with the project's success.

secondary title

Increases the cost of performing an attack

In addition to raising 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, such as a KYC (know your customer) check or a reputation score threshold, for voting users. We could even limit the ability of uncertified actors to acquire 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 significant portion of the voting power. (Many proof-of-stake solutions use a similar technique to safeguard their security — tightly controlling who has access to early stake, and gradually decentralizing from there.)

Additionally, projects can allow attackers to have difficulty passing malicious proposals even if they control a significant amount of voting power. For example, some projects have timelocks that prevent a token from being used for voting for a certain period of time after it has been swapped. As a result, attackers looking to buy or borrow large amounts of tokens would face the additional cost of waiting before actually voting — and the risk that voting members would notice and thwart their intended attack in the meantime. Authorization is also helpful here. By giving active but non-malicious actors the right to vote on their behalf, individuals who do not want to take a particularly active role in governance can still contribute their voting power to securing the system.

Some projects use vetoes, 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 and similar designs is to deter attackers from sneaking through malicious proposals and to give the project's community time to develop countermeasures. Ideally, proposals that are clearly in the interests of the agreement would not have to face these roadblocks.

For example, in the Nouns DAO, the veto 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 risk to the Nouns DAO or the Nouns Foundation."

Projects must strike a balance that allows for a degree of openness (which can sometimes be unwelcome) to community changes while not allowing malicious proposals to slip through the cracks. Often it only takes one malicious proposal to bring down a protocol, so a clear understanding of the risk trade-offs of accepting and rejecting proposals is critical. Of course, there are also high-level trade-offs 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.

Original link

Original link