Continuing the Thought experiment of Governance in Blockchain. Dual Chain and Token Governance Model (Rough concept, Rough draft)

Warning: this is a very long post, but a pretty interesting idea IMO.

Dual Chain and Token Governance Model:

Goal: Structuring a Decentralized governance structure, that can act as the sovereign governance execution and data availability layer. Built specifically to interact with a Cosmwasm smart contracting platform and perform the necessary Governance actions, as the arm of execution across the IBC.

Necessary utilities needed to make such a structure possible:

• Interchain Accounts
• Interchain Queries
• ZK proofs capability over IBC
• Exclusive or permissioned version of ICS, securing the governance chain, using the smart contracting chain

Introduction

Proof of stake blockchains to date, have a glaring issue that shouldn't be overlooked. They do not have the level of decentralization needed to sufficiently create a censorship resistant entity. Most proof of stake chains do not have the appropriate number of validators to protect the chain against real, large scale third party threats, and the chains that claim to, tend to have tons of validators being run by a few entities. Blockchains in reality, have two primary ideas around Governance, you have the school of thought, found mostly in proof of work chains like Bitcoin, which has a massive number of nodes validating transactions, with a nearly immutable code unless there is total consensus among the miners themselves. The next school of thought, tends to be more applicable in Proof of Stake. In this model, the network tends to operate in a democratic manner where the delegators stake to the active validators of their choice, and then gain the opportunity to vote on-chain, to decide where the network should go next. This includes things such as where funds from a network treasury should go, whether a network upgrade should be uploaded, and many other democratic decisions to be made.

However, there is one fact that tends to be overlooked by many in the crypto space. If a validator set, or a majority of the validator set were to be corrupted in some way, delegators have almost no recourse towards the validators to hold them accountable, outside of selling their tokens and finding a new chain that aligns with their values. This is an inherent risk in the validator/delegator relationship, your values only matter, if the validator gives you the power to matter. However, the harsh reality is, validators are the sole controllers and gatekeepers, of the most important part of a blockchain, the code. This makes it important in my opinion, to figure out how we can get some level of recourse built in at the code level, for delegators to check the power that the validators currently hold.

In this post, I will introduce a Governance system, built on the Cosmos IBC, that, with certain functionality, could level the field of power in the delegator/validator relationship. I bring up certain topics like the ability for delegators to slash or jail a validator directly if a supermajority believe it is a necesssary move. I also bring up concepts like high deposits for proposals, with deposit incentives and slashing, depending on how the vote goes on-chain. I want to say, I am by no means a "blockchain expert", not even close, just someone who has fun thinking about blockchain governance and decentralization. So feel free to critique and comment on the concepts and ideas I am bringing here and let me know where I may be off or where I should look deeper into, to gain better perspective of how governance on the blockchain could work. This post in it's entirety is regarding a specific app-chain I have conceptualized, however bits and pieces of this idea could be interesting on other chains, in their governance systems as well.

Details of the two chain Governance System

This model will consist of a general, cosmwasm smart contracting chain, with a seperate side chain that strictly runs as the sovereign Governance execution layer. Items such as the delegators execution module will require a significant amount of predetermined functionality that will be necessary for such automated Governance to occur. So rather than create significant code complexity and attempt to run both a smart contracting platform and automated Governance modules on one chain, and sacrifice the scalability of one chain. I have opted to implement a second chain, that can handle the code complexity, incentivizes the additional load for validators using its own token and will give a permissionless governance structure allowing for delegators to have certain rights deemed necessary in a decentralized and secure blockchain. These rights will be automatically executable, rather than relying on a developer plan and validator execution. These rights are built into the system, to be enacted by the will of the delegators at any time where consensus of such action would be deemed necessary.

The two chain model would offload the vast majority of the complexity out to a second chain that’s dedicated to the data availability and execution of governance and the many different forms it can take. This allows for the main smart contracting chain to do what its best at, which is executing contracts and acting as the overall consensus layer necessary to ensure safe, secure transactions with interoperability. This operates on the surface as the domain of validator power. They execute the transactions in a permissionless way, acting as the will of developers, smart contracts and the customers these contracts are designed to be utilized by. The second chain has a very specific skill set as a Governance module, the predetermined slashing functions and delegator voting transactions will happen on this chain, away from the general influence of the smart contracting chain and allowing Governance transaction and contracting transactions to be separate, but remain linked together with interwoven functionality between the chains.

This Governance chain will need the ability to perform these slashing functions at the will of the delegators, and therefore the IBC will need to have such functionality, that one chain can execute its will on the other chain in a permissionless manner. I do believe that functionality is possible with new functions like Interchain Accounts and Interchain Queries, however a variation of Zero Knowledge proofs across IBC may be necessary as well, to be able to provide a proof to the contracting chain, acting as the command to slash as specific validator when the proof is received. Without ZK proofs, this information could provide issues of overwhelmingly bloated IBC transactions and may not allow the direct assurance needed to make the transaction fully automatic. In a situation without ZK proofs, this may require developer and validator action and trust, in order to execute the necessary actions. With that said, the two main functions that will be necessary are the zero knowledge proof, vindicating that action is necessary, and the predetermined functionality of automated slashing on the smart contracting chain, to ensure proper execution.

ZK proofs and the automated governance module, that would act as the execution “contract” and provides proof of mutual assent between the governance and smart contracting chain. Resulting in a trustless and permissionless piece of core functionality in the relationship between these two chains. An example of permitted action from a ZK proof from the Governance chain, would be it sending an IBC proof that, in the governance module would read like this;

“A slashing action was voted on and approved, by a supermajority of delegators, for the slashing of (X) validator for (Y) reason stated in our mutual assent, here is the (ZK) proof. Therefore per the terms of our agreement, you need to slash (X) validator for breaching their social contract with delegates”

This should act as seamless, automatic action with no need to trust developers to create such code and no need to trust validators to upgrade or execute such code. Rather the code is a part of the basic function of both of these chains, with terms of mutual assent stored in both chains, in a hard coded module, allowing it to be performed as any action on the chain would be and with equal immutability.

Securing the system, shared security between the two chains

The governance chain will operate under a similar structure to a permissioned version of ICS. This will allow them to have the same level of security, with a smaller amount of governance rewards being paid to delegators, since the majority of tokens should be earned through governance participation.

I believe this model will allow for a high degree of value capture between the chains and will be the best option to keep the validator set the same for both chains by utilizing ICS for a model with two chains needing to be attached at the hip, so to speak.

Whether the chain will have the capability to onboard other chains similar to how the Cosmos Hub does, would be left to the market to decide and would leave additional opportunity for growing its interchain services.

How a proposal may work on the two chain Governance structure (rough rundown)

• A proposer starts by connecting their wallet to the central governance chain and governance hubs UI. Ideally this wallet would be whatever the most popular wallets are in the Cosmos ecosystem (Keplr, Cosmostation).
• The proposer initiates the UI to make a proposal. They will provide a full detailed run down of their proposal, and this proposal will initiate into the deposit stage.
• The deposit in general, will be a rolling .5% of the circulating supply, that adjusts per day, at an epoch of its own. This deposit amount will not change for the 21 day deposit period. After 21 days, if the proposal has not had the required amount deposited, then the deposit will be disbursed back to the original wallets that sent the funds.

(Note: Should a deposit be editable while in the proposal phase? Maybe a certain time like 19 out of the 21 day deposit period, so negotiation and debate can take place with meaningful results can be added to the proposal. What stops this from frequently changing so people can’t keep up, fee per edit?)

• A successful deposit will be automatically, in its final form, be uploaded on chain for official voting.

Deposit risk and incentive- The goal of this model is to incentivize and encourage good governance with on-chain, economic assurances. One assurance would be, depositors will be incentivized for on-chain proposals that pass through the voting process. However, economic assurances must come with balance. The balancing power is, if a proposal ends its voting period with a “No With Veto”, then a deposit slash (example, 10% of total deposit slashed) will occur, giving a penalty for wasted on-chain governance,

as voted on by the voters. This risk/reward structure should motivate good proposals, with wording that comes easy enough for people to understand as well as ideas that are sound. While spam proposals will likely never make it on-chain, as most spam stops at the hub deposit period. The overarching idea being that depositors are more likely to want to preserve capital and only risk there tokens on a proposal they see as valuable, to earn incentives, rather than risking a slashed proposal.

• It is from the point of the proposal being uploaded that a 10 day voting time frame will begin, with a 40% quorum minimum at the time of the end of the period. After this period and depending on results, the deposits plus or minus the incentive/penalty will be automatically returned. Deposits that are slashed can be sent to a treasury, sent to delegators of the staking token, burnt or wherever the community may decide in this matter.

How software upgrades could be handled on-chain:

Software upgrades inherently come with many responsibilities to try to work out every potential issue before submitting a proposal for the validators to upload. A testnet requirement with hub functionality that allows for multi-validator slashing by delegators, if they do not utilize the full testnet and do proper due diligence. This system would need to have some level of oracle functionality to relay information of the start of a testnet, and the time the testnet has been in process. The due process of the Testnet would be that the full testing period should be fulfilled before the Testnet ends and the upgrade is uploaded. This requirement can be sufficiently nullified if a signaling proposal is made by the community and passes, to allow early exit of the Testnet, penalty free.

Slashing and Jailing process

The slashing punishment, is a power left ultimately to the judgment of the delegators to enact, as this power would be strictly left to a delegator only model with no voting ability by any validators. A way to accomplish this could be through the knowledge of the validators address used for staking reward payouts and general voting address, and using that knowledge to having those addresses added as invalid addresses for the delegator specific voting module. Delegators will have this exclusive slashing ability, however, this should have an element of due process of on-chain approvals, to minimize the risk of delegator abuse.

• This process needs to start with a general signaling proposal, however this signaling proposal should take place in a delegators specific voting module, where validator wallets will be excluded from voting, to allow for a proper democratic voting demonstration.
• This general signaling proposal will require a 51% quorum with a 67% approval before this would be considered passed and moving into the execution phase.
• The execution phase will add in what would be new functionality of automated slashing, where the delegators can pick out which validators are to be slashed, and this slashing will be done at the protocol level, via an execution proposal, that will include a specific set of “reasoning” behind why delegators are proposing to implement a slash, with an additional secondary vote to ensure the slashing execution is the way the network wants to proceed. The proposal period will be the same as the signaling proposal at 51% quorum and 67% approval of this slashing. The Execution module will require a significant amount of predetermined functionality that will be necessary for such automated Governance to occur.

Jailing a validator

• An additional delegator power that could be added to a Governance system could be a delegation jailing a validator from the network of the jailing is deemed necessary by delegators and the function deemed necessary to be jailed, is not automated on-chain. This could be a process very similar to the slashing function and could prorate in a similar model.

General actions that could constitute a reason for delegators right to slash or jail a validator:

• A validator or multiple vote on a proposal in a way that is out of character for the general social consensus of the network, thereby giving the network recourse against actors who seek to change the network outside the scope of what is generally seen as reasonable by the network. This recourse could cause a validator or multiple to seek a hardfork, which could split the network, but the network should seek a hardfork if enough validators and many delegates agree. Ultimately the right to fork should persist, and these governance measures are to be enacted when it is deemed most necessary to keep the general social consensus heading on the track that is generally approved.
• If a validator or multiple validators were to become corrupted in some way by a malicious third party. It may be possible, in this scenario, for a significant slash or jailing could occur, that could effectively remove or limit the corrupted validators power over the network. Restaking to a safe, trusted and not corrupted validator would also be a possibility, however in some cases where a wealthy validator is holding most of its delegation by itself, this slashing could do material harm to the overall power the validator had.

Certain parameters would need to be set to make these Governance proposals executable, which could take some amount of foresight. However, the checks and balances of this system could be extremely interesting.

A deeper look at risks and rewards in depositing for a proposal:

The role of incentives is a straightforward idea, however the model I prefer is somewhat unique, at least compared to what I’ve seen. In most incentive structures the incentive is used to pay someone for voting or pay someone to vet proposals. However I don’t believe paying someone to vote, actually generates a good governance system, rather one where small amounts are paid to those who vote and a larger amount to the privileged ones with the time to review and vet proposals, or become a member of some council. I think there is a better and more inclusive way to incentivize good governance.

Essentially, the process comes with the premise that if we want to ensure good, high quality governance, the proposal needs to be backed by a deposit that depositors are risking, in hopes that the proposal is quality enough for the community to approve, thereby giving the depositors a reward paid out in the Governance token. This reward, however, would only be paid out after the proposal has passed, then the depositers into then successful proposal will receive their incentives for promoting good governance on the blockchain.

The flip side of the coin is that if a proposal ends with a “No With Veto”, then it was likely a wasted proposal and should be slashed, as a punishment for wasting time and blockspace. This skin in the game approach, would make the proposers think twice about small little proposals that don’t really propose a meaningful addition to the network. This slashing risk however, is only limited to a “No With Veto”. We do not want to take this too far with making a “No” voted proposal be slashed. Many “No” voted proposals will have legitimate changes offered, that the network simply didn’t want to utilize at the time or they simply felt that the proposal did not represent the will of the delegators. So these “No” votes will not be slashed, rather the full deposit will be returned after the voting period has ended.

A recent example of bad governance in Cosmos

Many community members didn’t like Prop 89, one of the Cosmos Hubs most recent governance proposals. However, with all of the controversy and ruckus it brought amongst the community, the proposal passed thanks to a few powerful validators.

This proposal could have had a very different outcome, had it been in the two chain governance system. In my opinion, the proposal likely would have never met the deposit amount of .5% of the current circulating supply without the entity proposing it making a large deposit or some larger entities coming in and helping to make the deposit of roughly 1,460,000 ATOMs. Would the ATOMs they had requested even been worth the risk of losing a large sum of ATOMs if the proposal was a “No With Veto” and the deposit was slashed?

These different risk/reward additions to governance could encourage good governance in a very meaningful way. You could see that the valuable proposals and upgrades are the ones that make it through the pipeline, and the governance that doesn’t make an impact will never make it through the deposit period without a significant risk to the deposited funds.

Shorter validator voting period

In general, a separate issue could be addressed. The fact that validators were able to vote last minute to make prop 89 pass, is a flaw that gives the largest and most powerful, the ability to totally sway a proposal. So the two chain model would also include a 2 day difference between the validator voting period and the delegator voting period. Within this two days, the delegators would have the ability to win over public opinion who may not have voted or may have abstained, thereby allowing the delegators to have a bit of time for coordination in the event that a proposal is on the brink of passing or failing, and the community at large wants to sway it in their preferred direction.

Conclusion

What benefit could this experiment of a two chain governance structure provide to the community and blockchain as a whole. Largely, this model would be a proof of concept. That this model could work to help decentralize a network and level the playing field for its delegators, rather than just its validators, and potentially make it more secure against third party risk.

The idea that a blockchain is as decentralized as its stake among validators, is a flawed narrative. Validators have a sole oligarchy over the entrance if effective code, and one coordinated effort by a majority of the validators, could seriously affect the network in a negative way. The slashing and jailing at the code level, with the rights to do so at the delegators full discretion, could be an interesting way to solve the issue of third party risk, and gives the delegators recourse to fight back against a corrupted or malicious validator set.

Please feel free to comment and critique (Also, sorry for any grammar or spelling mistakes). This is an important topic going forward in blockchain, as we need to figure out how to become more decentralized and censorship resistant as time goes on. I am loving this thought experiment.

Thanks for reading.