Fixing Cosmos Governance With Fully Homomorphic Encryption

· Tarek Awwad

Silhouetted figures casting glowing ballots into a translucent, circuit-patterned ballot box, surrounded by padlock icons. AI-generated illustration.

In this series we will explore a real world use of Fully Homomorphic Encryption that can solve the limitations of the open vote system in the cosmos ecosystem. In this first part, we discuss the pros and cons of open voting systems and then we draw the overview of a possible solution.

Governance in Cosmos

Why does Cosmos require on-chain Governance?

Cosmos-based chains are far from being the only blockchains with governance mechanisms. However, one could argue that on-chain governance in the Cosmos ecosystem is among the most active in the blockchain landscape. This may be dictated by several factors which we expose hereafter.

The fine granularity of decision-making

Token stakers in Cosmos-based chains can natively vote on a wide array of protocol-related proposals, ranging from upgrades to module parameter changes (e.g., staking, distribution, minting, shared security, ICA, etc.). This range expands further when considering the plethora of application-specific decisions made in a truly decentralized environment. For instance, Osmosis - a DEX and Defi chain - has seen over 800 proposals in less than two years of operation. The vast majority of these proposals are application-related (e.g., LP incentive balancing, tokenomics, pool configuration, etc.). Beyond structured, code-executable proposals, the Cosmos SDK supports “text proposals”, allowing proposers to gauge staker sentiment on matters not directly addressable in code, such as vision, security, or codes of conduct.

IBC and chain interoperability

A cornerstone of the Cosmos ecosystem is decentralized interoperability through the Inter-Blockchain Communication (IBC) protocol. Lacking a native, decentralized and seamless way to decide on interoperability-related questions would significantly hinder the ecosystem’s ability to interconnect productively, thereby weakening this foundational pillar. For example, reviving a timed-out IBC client between two chains through off-chain processes would require extensive coordination and strong security guarantees - both of which are seamlessly handled through governance-driven code execution. Additionally, this native, omnipresent chain interoperability fosters financial dependencies or at least economic influence between chains. In some cases, this necessitates concurrent governance across multiple chains on a single subject, such as incentive matching for LP pools on Osmosis.

Governance in Cosmos is therefore a vital tool for the ecosystem. Nevertheless, it suffers from a major flaw …

Open Voting : the rationale

Cosmos-based chains natively implement an Open Voting model, where votes are publicly visible as soon as they are cast. This approach is designed to promote transparency and accountability within a trustless environment. While anyone staking tokens on-chain can participate in governance by voting on proposals, in practice, the majority of governance actions (primarily voting) are carried out by validators. By default these validators’ votes carry the weight of their stakers’ tokens (a.k.a voting power). As a result, it is essential for stakers to be able to hold validators accountable for the decisions they make on their behalf. Open voting facilitates this accountability, as every vote, particularly any changes to votes, is visible to stakers and must be justifiable by the validator.

By relying mainly on the validators to vote on behalf of their stakers, governance in Cosmos mirrors the Representative Democracy model, where the people elects a group of individuals who make the decisions on their behalf. However, stakers have the option to override their validator’s vote by casting their own, which introduces an element of Direct Democracy. Cosmos Governance is therefore a hybrid model which combines two systems that traditionally operate independently and are not designed to coexist, except when applied to distinct areas of decision-making.

The idea of blending these two model can be justified by the need for what we might call constrained trust and reactive accountability.

Constrained trust

Representative democracy relies on transitive trust. If I trust a person, I trust their decisions and behavior and those of the individuals they trust. However, human nature and the complexities of decision-making mean this trust cannot always be absolute. Validators may not represent the staker’s preferences in every scenario, on every proposal, or under every circumstance. This is specifically true in a dPoS (delegated Proof of Stake) chains where an intrinsic conflict of interest exists at the validator side (due to the tokenomical nature of these chains), creating an interest misalignment between the validators, as a service providers, and the stakers, as simple token holders. For this reason, it is important to have a way of constraining, for specific questions, the trust a staker credited to a validator which can be achieved through vote overriding.

Reactive accountability

In representative democracy, accountability is enforced through periodic reelections: effective representatives are reelected, while ineffective ones are not. This process is continuous in a Cosmos blockchains as the election takes the form of a delegation that can be changed at any time through redelegation (transferring the stake from one validator to another). However, redelegation comes with its economical and security impact, both on the chain and the staker. Overriding the validator vote, serves as an immediate and less disruptive way to express dissatisfaction or misalignment with the validator’s stance. This introduces a first layer of questioning the trust originally granted to the validator, reinforcing accountability in a reactive manner.

The Problem with Cosmos Governance

Open voting arguably achieves its intended goals of transparency and accountability. It also allows to achieve complementary goals i.e. constrained trust and reactive accountability which are only possible in an open voting setup. But what are the trade-offs of achieving these goals?

By relying on Open Voting, governance in Cosmos inherits its flaws. It all comes down to the following: knowing an individual’s vote with certainty, improves the likelihood of controlling it. A blockchain is a social and economic melting pot. Its decentralized and permissionless nature attracts participants from diverse backgrounds with varying visions and goals: retail investors, whales, market makers, developers, institutions, infrastructure providers, social media influencers, and more. These actors not only share a common economic space, but the social boundaries between them blur to the point of disappearing - something uncommon in more traditional systems. This dynamic fosters social pressure, facilitates bribery, and encourages collusion. Without legal frameworks to penalize such behavior, public blockchains are even more vulnerable to its effects.

Secret Voting solves - at least to some extent- the issues of vote buying, coercion, polarisation and social pressure. This is why it remains the most common type of voting in referendums and elections.

Is the problem real though?

The discussion above is largely theoretical, but does it hold true in practice? In other words, do the limitations of open voting manifest in real-world on-chain governance? One way to assess this is by examining the governance history of major - or formerly major - Cosmos blockchains, focusing on proposals where open voting may have contributed to a suboptimal democratic voting process. Hereafter, we showcase some of these proposals. This is by no means an exhaustive list but rather a selection of easily illustrative examples that generated significant polarization within the ecosystem.

Redeeming the gamed airdrop tokens

This is proposal 16 on the Juno blockchain, one of the most valuable chains in the ecosystem at that time. According to the proposal, an atom holder a.k.a the whale, has gamed the capped airdrop, by splitting their Atom tokens over multiple wallets. Moreover, since the airdrop also excluded institutional wallets like CEXs, the whale which turned out to be a private management fund, has also been considered ineligible. The proposal aimed at redeeming the unfairly airdropped tokens (all but 50K $JUNOs) into a community controlled wallet. The proposal passed and the whale tokens were redeemed.

Beyond rational and founded arguments like the systemic risk related to the whale balance, this proposal had multiple ethical and social facets that create an easy path to social pressure and intimidation. Some proponents of the proposal framed the ethical issue of gaming the airdrop as comparable to stealing. Others appealed to retail sentiment by bringing the common disdain and hate for whales in blockchain communities to the forefront. All of which are emotional and unfounded arguments.

Moreover, due to the value of the tokens at stake (tens of millions of dollars), there was a significant incentive for bribery. The whale could have easily bribed validators inclined to vote “No” by redelegating tokens to them, increasing their Voting Power and ensuring a favorable outcome for the vote. This reasoning was validated when the whale redistributed their stake after the proposal passed to “express gratitude” to validators who voted “No”. The resulting redistribution of Voting Power could have led to the proposal’s rejection.

Last but not least, throughout the voting process for this proposal, another critical issue has been raised and debated. Redeeming the tokens of the whale - or, for that matter, of any wallet - to a third-party account, even if it is a community-controlled account, has been likened by some knowledgeable individuals to an act of confiscation. According to these individuals, this action carries a potential legal dimension and could have direct legal repercussions on those who propose, validate, and execute it. That is, among others, the stakers who voted “Yes”. This legal interpretation, however, was not confirmed during the vote, and the absence of legal action afterward suggests that the fear of legal consequences was likely unfounded. The open voting process may have led some voters to take a “safe” approach by opting for an “Abstain” or “No” vote.

All of This, regardless of the specific instance and vote output, shows how open vote has lead to a community polarization and to fear or profit driven bias.

The Atom vision

Following a loss of interest and lack of revenue on the Cosmos Hub (the Atom token chain), questions arose about the Hub’s future, including its vision and the technical and economic direction it should take. Two key proposals emerged: Atom One and Atom 2.0. Both of these proposals were rejected.

Open voting in this context revealed significant challenges. First, the technical complexity of the proposals left many voters unable to fully grasp the details, leading to uneducated votes often based on trust - e.g., “X voted for Proposal A rather than B; I trust X, so I’ll vote A”. Second, open voting allowed social pressure, where voters may feel compelled to align with or against a particular individual or organization, regardless of their proposal’s content. This has been exploited by both parties where accusation of corruption, incompetence and conflict of interest were used to discredit the proposal by undermining the credibility of the proposer.

Finally, short-sighted economic incentives play a role, as voters may side with the perceived “winner” in hopes of benefiting from potential airdrops or rewards for supporting the successful proposal. These dynamics highlight how open voting can undermine the quality of decision-making in such critical governance matters.

The solution

Cosmos needs a governance mechanisms that fulfils the following conditions:

  1. It should rely on secret voting.
  2. It should allow some form of validator accountability.
  3. It should preserve the features currently available, like re-vote, weighted votes, abstention, etc.

FHE: a path to sound on-chain democracy

What is FHE?

Homomorphic Encryption is a type of encryption that enables computations to be performed directly on encrypted data without requiring decryption first. The results of these computations remain encrypted and can only be accessed by decrypting them. The decrypted output is identical to the output of an identical computation performed on identical, yet unencrypted, input data. This approach ensures the privacy of the data owner while retaining the practical utility of the data.

In practice, not all Homomorphic Encryption methods are created equal. Some methods support only a limited range or number of operations (i.e., partially and somewhat homomorphic encryption), while others can handle an unlimited number of any type of operations, albeit with a trade-off in efficiency (i.e., fully homomorphic encryption).

In the governance context we are tackling here, FHE can be used as a way to achieve vote secrecy.

How can FHE solve the Cosmos governance limitations ?

The use of FHE to ensure the vote secrecy is an obvious option. It completely fulfils our first requirement by rendering all the votes secret through encryption while allowing vote counting and quorum computation. Furthermore, it allows us, with some design and engineering effort to fulfil requirement two and three. Let’s start by an overview and discuss how our requirements can be achieved.

Overview workflow

This list summarizes the lifespan of a vote. From casting to counting:

This workflow involves switching between on-chain and off-chain processes, similar to how Zama’s FHE-compatible EVM operates with its off-chain coprocessor. This design keeps the chain agnostic to encoding and decoding processes while preventing bottlenecks caused by their inefficiencies.

What about accountability?

To enable accountability, particularly validator accountability, validators vote can be decrypted after the final tally. The decryption can be either systematic or DAO controlled. In the former case, all validators votes are decrypted and published on-chain in plain text after the vote ends. In the latter case, a validator-specific DAO would allow stakers to decide, on a proposal-by-proposal basis, whether the want their validator’s vote to be decrypted.

Since validator votes on a given proposal are only revealed once the voting period ends, stakers are deprived from the benefits of vote overriding. This is a double-edged sword: on one hand, losing this powerful tool could reduce staker engagement in the governance process. On the other hand, it could encourage them to rely less on the validator stance, which as explained earlier may not always be fully aligned with their interests.

Limitations

Fundamental research on speeding up FHE is yielding impressive results over the year. Nonetheless, doing computation on encrypted data is still orders of magnitude slower than plain text computations. Therefore, one should expect the counting and decryption processes to be slow especially for large chains with large validator lists and most importantly a large wallet number.

As mentioned earlier, governance proposals in Cosmos cover a broad range of use cases, with varying levels of time sensitivity. Textual proposals - typically used for signaling purposes and off-chain or manual operations - generally don’t have strict time constraints. However, some parameter change proposals contain modifications that must be applied precisely when the vote concludes and passes. In these cases, any delay in the tally process can be problematic. The proposer could take into account such a delay and the chain needs to be able to handle it. One possibility is to use an additional “apply height” parameter similarly to the “halt height” used in upgrade proposals. However, this remains a limited solution and the tally process need to be sped up regardless.

One way of achieving this is by minimizing the number of encrypted votes as much as possible. To this end, we can leverage the specificities of the use case and the blockchain in general. Let’s recall that the impact of a wallet on the voting process is what implies the need to vote secrecy. Wallets on a blockchain can be clustered based on their impact according to different criteria, mainly the following two:

Based on these factors, one can devise a hybrid system where not all votes require encryption. The conditions for requiring an encrypted vote can be one or a combination of the following:

In the next part of this post, we will go into the technical details of this solution and its challenges and discuss design choices in-depth. In following parts, we will attempt to build a working PoC. We will modify a vanilla Cosmos SDK chain and use external processes to encrypt and post transaction as well as to compute the vote output and eventually to decrypt it and post it on-chain. We will also discuss the feasibility of a decentralized validator managed decoding process that leverages ABCI++ and its vote extension capability.

First published on the Sydyk blog, January 2025.