Energy Web Governance

This page describes the current and planned features of the Energy Web Governance mechanism. 

EWC governance should be decentralized as quickly and significantly as possible. In the original EWC white paper, a “governance by gas” mechanism was described, in which decision-making power is granted to known, vetted application developers and decisions are made via a combination of on- and off-chain mechanisms.

While many members of the EWC ecosystem continue to believe in this vision, in the months since the original Energy Web white paper was published, the EW community determined that it is not appropriate, nor technically feasible, to implement such a formal on-chain governance mechanism at the time of the EW Chain launch (June 2019). Three primary factors led to this decision:

  • The ultimate governance mechanism should not be created or implemented by EWF alone; instead, a collaborative approach should be pursued with Energy Web Members (formerly "Affiliates"), others in the blockchain community, and energy market participants. 
  • At the time of launch, there were not sufficient numbers of decentralized applications and developers active on the EWC to enact the original “governance by gas” mechanism described in the white paper.
  • On-chain voting mechanisms are an emerging field, and there are few examples of successful on-chain governance to date; further research is needed to ensure that the final design of such a system is both secure and fair. 
  • To date, EWC is the only public blockchain to feature known companies from around the world as validators, and it is designed to support enterprise-grade applications that interface with competitive and highly-regulated energy systems. Accordingly, the EWC governance mechanism should be informed by relevant regulations across multiple jurisdictions; it should limit the liability of participants while incentivizing innovation and ensuring network stability. 

In light of these factors, the most effective way to begin decentralizing the EWC governance immediately upon launch was to establish an interim "rough consensus" EWC governance model based on other well-established public blockchain models (e.g. Bitcoin, Ethereum) in which key ecosystem stakeholders (namely network core developers and miners/validators) make collective decisions through discussion and consensus building off-chain. Following the launch of the Energy Web Chain in June 2019, EWF and the initial validator set collectively decided to use a consensus governance model based on Ethereum’s governance model in which validators convene via bi-weekly calls to evaluate and make decisions. In the initial consensus, the default assumption was that a proposal is accepted unless a majority opposes it.

As of Q4 2019, the validator set became large enough (22 validators and growing) and geographically diverse enough (12 countries spanning 16 time zones) that in order to ensure that all validators have opportunities to express their opinions and true preferences about governance topics, the bi-weekly calls needed to be replaced with a more formal process of decision making and a more robust record keeping of what decisions were made as well as how they were made. The long-term EW Chain governance roadmap includes the potential for on-chain voting and experimentation with weighting, potentially governance by gas but those mechanisms require further research and development.

As a first step, a simple voting system within the existing Validator Discussion Forum (Energy Web implementation of Discourse) will be implemented and launched in Q4 2019 to give validators the ability to formally make and vote on proposals within the forum. The experience with this initial voting mechanism will inform the development of a smart contract implementation of a simple voting system, which is expected to launch in Q1 2020. This implementation will include more sophisticated ways to deal with different levels of voter participation and record all votes and results on-chain. In Q2/Q3 2020, voting tool functionality will expand with additional features that allow for different voting weights based on meaningful metrics. These metrics will be identified based on experimentation and testing. They might include a governance-by-gas model in which DApp developers voting weights are derived from the usage of their DApps. Other possibilities that will be explored are staking based approaches. Depending on security considerations, automatic execution of selected proposals will be tested during this phase.

Near-term EWC Governance

For the foreseeable future, there are three primary actions that will be subject to a governance decision: 1) adding and removing validators, 2) implementing client updates, and 3) modifying the governance mechanism itself (e.g. eligibility, voting, etc.). 

The Energy Web Chain was originally launched with 11 validator nodes (each operated by independent organizations that are active EWF Members (formerly "Affiliates") in June 2019. As of October 2019 the Energy Web Chain is supported by over twenty validator nodes, and approximately thirty validator nodes are expected to be live on the EWC by the end of 2019. 

As described above, currently EWF facilitates discussion of proposed changes via multiple channels (including the online Discussion Forum, validator conference calls, as well as online messaging tools like Slack and email), administers the initial voting mechanism in the Discussion Forum, supports the decisions and strategic direction of the validator set, and acts as an administrative implementation body. Herein, EWF implements changes to the chain - including the rules and processes of the governance mechanism itself - if a majority of validators support any given proposal through off-chain consensus (achieved via the channels mentioned above, namely the initial voting mechanism within the Discussion Forum). Proposals may include transitioning Energy Web Chain governance to on-chain voting mechanisms, governance of the Energy Web community fund, and/or updates to Energy Web validator requirements. Implementation of such governance mechanisms are thus decided by the validator set, and are only deployed with the majority support of Energy Web Chain validators.


EW Chain Governance Roadmap

The following content describes some of the key considerations for an on-chain governance mechanism, as well as more detail on how a "governance by gas" approach could work. This is only an initial draft - comments and feedback from the community are encouraged!


Context: In order to maintain the integrity of the Energy Web Chain and keep it operating correctly, the way changes are defined and implemented must be governed. These tasks include adding new validators, removing misbehaving validators, proposing and approving client and protocol updates, and modifying the governance mechanism itself. For all these tasks there are different incentive structures to consider for the stakeholders of the chain. EWF and others have described a formal on-chain voting mechanism in which the application developers that run successful applications on the Energy Web Chain are the main decision makers while the EW Chain validators act as gatekeepers with certain veto powers to ensure effective cheques and balances. 


What are the components of a formal on-chain voting mechanism? 

At a high level, there are four parameters that must be defined to enact a formal on-chain voting mechanism:

  1. Voting Participation: which stakeholders should be allowed to participate in votes? 
  2. Vote Weighting: How much decision-making power should individual stakeholders exhibit in the voting mechanism? 
  3. Winning Threshold: what are the prerequisites to win a vote ? E.g. what is the level of support that a proposal needs to be approved?
  4. Checks and Balances: what, if any, special rights should certain stakeholders get to veto or otherwise override a vote decision? 

These are the essential aspects of a voting mechanism. There are of course many additional design decisions that have to be made, including the timing and frequency of votes, whether to have binary or multiple candidate elections, whether voters should vote simultaneously or in a sequential order, and whether to have open or secret voting. All these design decisions should ideally be made in a way to reduce the risk of manipulation and increase the fairness of the procedure.


What formal governance are used by other projects?

To date, there have been relatively few examples of formal voting mechanisms in public blockchain governance systems (both Bitcoin and Ethereum currently rely on informal, off-chain governance). Blockchain projects that do implement a formal voting mechanism often choose to weight the votes based on the number of tokens an individual owns or is willing to lock-up (i.e. stake) for a certain period of time (e.g. Cosmos, tezos, EOS, MakerDAO, Aragon etc.). Winning in this context mostly means that some threshold of tokens for or against a proposal has to be reached, e.g. 50% (less conservative, with higher likelihood for change approvals) or up to 80% (very conservative, with higher likelihood for maintaining status quo). “Token voting” can make a lot of sense because it is easy to implement and has been tested in several contexts. At the same time, token voting gives greater decision-making power to individuals that own a large number of tokens, and it is not clear that these individuals are necessarily better informed than other stakeholders or the stakeholder group that creates most value for the network (compared to application developers, validators, and end-users for example). An alternative approach used by the PoA-Network is to give control entirely to the validators of the network in a one-person-one-vote style. This approach benefits from simplicity, but potentially creates misaligned incentives, especially for the task of adding new validators (see below). Additionally, it does not differentiate between reliable, long-term validators and unreliable ones, or validators that might have just joined the network and may lack some of the experience and context of longer-tenured validators. 


Who should participate in EW Chain governance?

On the EW Chain three different stakeholder groups can be identified: application developers, validators, and users of the chain. All of these groups should participate in the EW Chain governance in some capacity, and in many cases one organization or person may act in multiple (or all three) roles. However, the specific roles and responsibilities of each group should reflect their unique characteristics and incentives. 

Decision-making power should be given to the stakeholder groups that create (and receive) the greatest value for the Energy Web network, and thus have the greatest incentive to maintain the security and robustness of the chain over time. Today these stakeholder groups are application developers and validators (this may change in the future). 

Application developers build applications that generate value for users of the chain, including energy companies and their customers. They have the highest stake in ensuring high performance and security of the Energy Web Chain because their applications, and thus business models, rely on it. As a result they can be expected to put a lot of effort into making the right decisions for the entire network and adopting useful functionalities. In addition, as application developers work with the blockchain on a day-to-day basis, they have a very good understanding of the technology and can make very informed decisions about how to evolve the system. They have a level of technical expertise that cannot be expected from users of the Energy Web Chain. 

Similarly, the direct contact validators have with the blockchain protocol through hosting and maintaining a validator node makes them excellent candidates to double check the decisions made by application developers. As EW Chain validators are well-known companies, they are highly likely to make decisions that protect the integrity of their nodes and the overall chain itself. 

End users may not have the interest or level of expertise required to directly participate in decision-making, but they should not be excluded from the governance process entirely. In the spirit of transparency and decentralization, users should be able to make proposals, contribute to discussions, and review the outcomes of votes. 


How should the vote of the stakeholders be weighted?

While decision-making power should proportionally reflect the level of “stake” in the EW Chain, using tokens as a basis of vote weighting is likely not the most appropriate design decision for the EW Chain. Metrics that are more meaningful for the different stakeholder groups should  be incorporated. 


Application Developers

Logically, an application that has hundreds of thousands of daily users and/or generates millions of dollars in revenue should have greater influence than a small hobby project that runs on the EW Chain. However, it is important to prevent  a high degree of centralization, and the vote weighting should ensure that the interests of smaller applications are also considered to enable healthy competition. One baseline metric to weigh the votes of application developers is the active usage of their applications expressed in “gas”. Every time a transaction happens on the Energy Web Chain the computation has to be paid for in gas. The active usage of an application on the Energy Web Chain therefore perfectly correlates with the amount of gas that users spend in order to interact with the application. To account for active usage only the gas expenditure of a specific time period (e.g. the previous year) can be counted. In theory, this metric should only be influenced by end users of applications, not the application developer directly; this is in contrast to token holdings, which can be arbitrarily increased. 

  • Problem: gas cost on the EW Chain may be significantly lower than other public chains  (e.g. ethereum) due to the distinct characteristics of the PoA consensus; this is likely especially true in the early stages of the EW Chain when few commercial-scale (i.e. thousands of users / transactions per day) are running. As a result application developers could artificially increase their vote weight by simulating usage of their app (e.g. creating dummy accounts and transactions) at a very low cost.
  • Possible Solution: To avoid centralization and reduce possible negative effects of this type of manipulation, a double square root voting system may be appropriate. In this system, based on the spirit of quadratic voting, the square root of the baseline metric is taken to reduce decision power of very big players and limit the efficacy of “artificial” gas spending increases. There are also other measures that could be taken, such as dynamically adjusting the time period in which gas measurements are taken (e.g.  not counting increases since most recent vote, adjusting the time period proportionally based on total number of transactions or developers) that could also help mitigate the impacts of targeted artificial vote weight increases for a specific proposal. 


Validators

Similar to the application developers, very reliable and/or long-tenured validators should have more decision power proportional to their level of experience and/or reputation. As a result, the baseline for weighting the votes of validators could be the number of blocks they have validated in a given time period (e.g. the previous year). This way, reliable long-term validators have more decision power than ones that are unreliable or have only been a validator for a short time period. This metric can also not be arbitrarily increased but can only be maximized by having a very high uptime, which is very beneficial from a network perspective.

  • Problem: The metrics that are used for application developers and validators, namely active usage of the DApp in gas and produced blocks, are not directly comparable. As a result, they cannot vote in the same election together.
  • Possible Solution: The different stakeholder groups could take on different roles depending on the task and its specific incentive structure (see below). It might for example make sense that one group is the main decision maker, voting on proposals, while the other one is there to check the decisions of the main decision makers. This way, both groups participate in making the decision, while it is not a problem that their vote weights are not directly comparable. In such a system decisions of one group could be vetoed by the other if a majority opposes the decision. It would likely be beneficial to design this in a way that the second stakeholder group has to become active to veto a decision to disturb the regular workflow as little as possible, while also limiting the power of the main decision makers.


How should the winning threshold (quota) be set?

Most decisions in blockchain governance are binary. Binary decisions are beneficial from a game theoretic perspective because they do not allow for any kind of strategic voting and it can be expected that voters reveal their true preferences. In most cases, voters can choose to approve or dismiss a proposal so it must be decided how much support (expressed in percent of total votes, or voting power) a proposal needs to be approved. The higher the winning threshold, the more conservative the average outcome will be; there are important tradeoffs in setting the threshold. For example, in a simple majority  the winning threshold or quota is 50%, so changes are relatively likely to be adopted (and with weighted voting, potentially approved by a relatively small number of participants). Many decisions (e.g. significant changes to the protocol) may benefit from a more conservative voting mechanism that requires a higher level of approval; in these cases, the quota could be 70% or even 80%. The way these quotas are chosen is often arbitrary, depending somewhat on the “level of conservatism” that seems appropriate. In contrast, the double square root voting system offers a dynamic method to calculate an appropriate quota based on the participating voters and their vote weights. Using the formula developed by the mathimaticians Słomczynski & Życzkowski has several advantages: 

  • The vote weight always equals the actual voting power of an individual voter (e.g. when a voter has 80% of the vote weight he/she only has 80% of the voting power because the quota will increase to a value well above 80%)
  • As a result, there can never be a dictator (a voter that has 100% of the voting power)
  • The quota dynamically adapts based on the participants and their vote weight: The quota is automatically higher in situations where a more conservative quota is appropriate (big differences in vote weight and/or low number of voters) and lower in situations where a less conservative quota is acceptable (evenly distributed vote weight and/or high number of voters)
  • The quota is not known until the end of the voting period which can disincentivise vote buying, coercion and artificial increase of own vote weight

For more information on the double square root voting system and its advantages visit:

https://hackernoon.com/in-praise-of-the-double-square-root-voting-system-for-blockchain-governance-977fa37f62cd 


How can the governance process be made secure?

The details of the governance process will be subject to experimentation and will only be decided by the initial validators of the Energy Web Chain. Generally there needs to be a platform where proposals can be submitted, discussed and voted upon. There are of course many open questions and hypotheses regarding incentive structures to be tested before moving towards an on-chain governance system. The best way to achieve this is to develop a survey tool with which the EW Chain formal governance process can be tested. This survey tool would enable simulation of an on-chain governance process. This way, the process can be tested and parameters adjusted without any of the risks of a real on-chain governance approach. Once there is consensus about the security of the process, the survey tool can be turned into a real voting tool that implements a completely automated on-chain governance process.


Breakdown of the different tasks:

Adding validators: This is crucial to increase the number of validators or replace validators that have dropped out. There are several incentives that have to be considered: For the network as a whole, the ideal number of validators depends on the desired degree of decentralization (which increases security) and the desired time to finality (which can be important for some applications). The two parameters are inversely correlated; the more validators, the more decentralized but the longer the time until finality is achieved. 

  • Problem: The individual validators have a financial incentive to keep the number of validators as low as possible because they produce less blocks in total and therefore receive less block reward. Overall the validators of course also have an incentive to have a secure chain with many applications and users which might work against the individual financial incentive to have a very low number of validators. 
  • Possible Solution: It becomes clear that application developers would be good candidates to make this decision. They are well suited to find the ideal number of validators that fits their security needs and thereby ensure a secure and well functioning network for all stakeholders. Including the validators in this decision through e.g. a veto right could be problematic because of the above mentioned misaligned incentives. But is generally possible, if the incentive to have a secure network is perceived as bigger as any individual financial incentive. There are also other, more indirect ways to include validators in this decision (see “adding and removing application developers”). 
  • Another question is how to ensure that the validators comply with the eligibility criteria that were agreed on in the first governance call. In reality there could be a waiting list that is administered by EWF and once there is a need to add a new validator the community can choose one of the entities from that list.


Removing validators: Validators should either be removed because they requested this themselves or because of observed misbehaviour. Once a validator is not producing any more blocks or is producing blocks on a forked different chain, this validator poses a security risk for the entire network and it is in everyone's interest to remove this entity from the validator set. 

  • Problem: As explained above, if the decision lies solely with the other validators, there might be the risk that a subgroup of validators collude to remove validators to increase their own block reward. 
  • Possible Solution: Again, the application developers seem to be good candidates to make this decision. But in contrast to adding validators, there is no great risk in also involving the other validators in this decision through e.g. a veto right on the application developers decision. To react fast once misbehaviour is detected, every participant of the formal governance should be able to propose the removal of a validator. It could also be discussed if automated proposals once misbehaviour is detected on-chain could be an option.


Client and protocol upgrades: These decisions are very technical and likely have the greatest impact on application developers. 

  • Problem: Very technical decisions should be decided by stakeholders who fully understand what they are voting on. But in the end the validators are the ones running the software on their machines. They can always decide not to make an update or not to support a protocol upgrade and fork the chain. Their decision power in the formal governance process should reflect this.
  • Possible Solution: The application developers are again good candidates to make this decision as they can be expected to have the capability to make very technical decisions. But a veto right for the validators to oppose the decisions of the application developers seems necessary to reflect the power they have in this matter and to avoid forks. 


Adding and removing application developers as participants of the formal governance: It is questionable if all application developers should be allowed to participate in the formal governance of the chain. It could very well be that the community wants to enforce some eligibility criteria similar to the validators. Only allowing certain application developers to participate in the formal governance process also solves problems connected to KYC and Sybil attacks. 

  • Problem: If similar to the validator set there exists a set of application developers, again the question arises who should have the power to add and remove entities to/from this set. Application developers that are already in the set have an incentive to keep the number of other entities low to increase their own decision power. In addition, a single real-world entity could potentially act as both a validator and an application developer; how to administer those two roles should be considered. 
  • Possible Solution: One solution could be to let the validators decide about who to add and remove as an eligible application developer. This way validators have an indirect control of all other governance decisions (e.g. also who to add as a new validator) in a way that they can choose to not accept application developers that they do not perceive as capable to make these decisions. To limit the control that validators have, application developers could get a veto right on removing entities from this set (complementary to removing validators). Having validators control the set of application developers and application developers control the set of validators with additional veto right for removals could potentially create really effective cheques and balances between these stakeholder groups.