Measuring Governance Utility

It is possible to create a framework that can identify the components of governance utility to protocol stakeholders?

As onchain governance becomes more widespread questions about stakeholder apathy emerge. The introduction of gasless voting such as snapshot (snapshot.page) in some protocols has shown signs in the ability to increase stakeholder participation.

The modern rational voter theory developed by Downs (1957), Tullock (1967), and Riker

and Ordeshook (1968) proposed just such a framework for analyzing why people

Vote.

The modern rational vote framework can be expressed as: U = qB − C + T

Where:

q = the probability voter is pivotal

B = Benefits if ballot wins

C = cost of voting

T = extra benefit of voting

After factoring all these in, only when U or the utility value to the voter is positive will they be compelled to vote.

Using this model, gasless voting would decrease C or the cost while quadratic voting & voting credits increase q or the probability the voter is pivotal.

This also leads to ask if offsetting the cost of voting using incentivized voting would actually increase voter utility?

What if the incentive is so large as to always make utility in the framework positive but not provide true utility to protocol in practice?

The modern rational vote framework is a framework for individual voter utility. What would a framework for protocol wide utility look like? How would the effectiveness of such a framework be tested for?

Topics:

  • Decentralized decision making
7 Likes

TL;DR

A recent and interesting concept which tries to optimize the voters utility for every protocol actors :

  • Coordination token: A token that allows its holders to vote for a parameter, and that remunerates those who have the power to apply this parameter if they follow the majority of votes.

This concept will be experimented by a project which introduced:

  • “A coordination token to allow holders to vote on what their individual desired Ethereum Gas Limit is, and reward miners (pools) for listening to the community and user preferences”

I would like to share some posts from Vitalik Buterin concerning coordination and collusion :

These posts abstract and contextualize multi-agent coordination concepts using real world examples and blockchains governances. The author raised some limits such as the difficulty to identify collusions or briberies, and concluded that there is currently no one-size-fits-all governance/coordination model. Indeed in an ideal world, actors can act together to solve their problems, however this also permits participants to collude to benefit at the expense of another group. While for example, a high coordination level can be useful for participants in some cases such as to strike back against collusion.

Buterin then proposed a list of coordination structures aimed at fixing (or improving) several raised issues, among them I find these ones interesting:

  • Deliberate decentralization, distributing control of some mechanism to a wide group of people that are known to not be well-coordinated
  • Decentralization between role-based constituencies, separating out different functions (or different shares of the same function) to different types of participants (eg. in a blockchain: “core developers”, “miners”, “coin holders”, “application developers”, “users”)

This list gave birth to a project which was previously discussed on this ethresear.ch discussion channel : A Third Way: Coordinating the gas limit - Eth1.x Research - Ethereum Research .

"The Ethereum Eagle project (EGL) is a community led effort to solve the misalignment of incentives and lack of transparency between the community (e.g. users, core devs, DApps) and miners in the Ethereum ecosystem. Our primary focus is to align incentives and enable coordination between the community and miners in a way that maximizes value for all Ethereum stakeholders.

Following in the footsteps of Flashbots, this effort builds upon the phenomenon of community initiatives focused on tackling protocol level attributes without requiring a protocol change.

Specifically, EGL introduces a coordination token to allow holders to vote on what their individual desired Ethereum Gas Limit is, and reward miners (pools) for listening to the community and user preferences.”

The authors describe that according to the current Ethereum network architecture, only a subset of actors can act or vote to change the block gas limit. Indeed unlike Bitcoin which defines this parameter according to the wishes of the core developers, Ethereum allows miners (or rather pools) to decide to change the gas limit by themselves (and they have indeed). However the miner utility may not be aligned with that of the users or the protocol. The idea consists of using a coordination token to enable users to express their desired gas limit, and to reward mining pools that are acting in accordance with the majority of the voters. This concept of coordination token will firstly be used to experiment with the gas limit parameter but it could be used further for any other customizable parameter.

Coordination tokens could be a kind of framework which tries to optimize the voter utility in a cooperative way instead of the individual rationality. This concept also brings incentives for new actors to participate in voting processes (as some parameters which were previously not subject to voting can become so). However I remain curious about the course and the functioning of this experimentation that I will try to follow (notably concerning which type of actor will be prominent during the votes? Will the rewards be sufficient for the mining pools to follow the majority? What are the different risks of influence and results regarding new voters? etc).

@Fizzymidas During the last community call we mentioned the possibility of thinking about a taxonomy of “decentralization measures” of different aspects of the protocols. I think that some of the concepts previously mentioned and contained in this topic could be relevant to take in consideration during our future discussions:

We already mentioned the need for different types of taxonomies according to the protocol concerned (layer 1, Dapps, etc), but we must also take into account the several actors of blockchains (developers, miners, holders, users, etc.) and what leverage they have in terms of action or voting. "structure of coordination : which groups of people and in what configurations can come together to further their group goals, and which groups cannot?".

6 Likes