Pre-onchain DAO era: sudo module and multisig

Hi there, human nodes and friends,

Today we wanted to go over how the pre-onchain DAO will work and highlight several critical security measures that were put in place so that the Humanode network, during its early days, is adequately secured until it matures into an established network. All of what is going to be described here today is thoroughly described in the whitepaper. Still, we have decided to make things much more transparent for the community and give more technical details about the implementation that we have today. We don't want to delve into all the information in this article, so if you'd like to understand the basics of what is discussed here, I suggest you go to the whitepaper's section "Vortex" and read it.

As stated in the whitepaper, Humanode aims to create a governance model where governors have the right to vote and make proposals on crucial matters. The goal is to become a governance-led protocol and, by 2026, fully decentralize the network's decision-making and upgrades, transferring it from Humanode Core to the Proposal pool - Vortex - Formation trio. As this system hasn't been implemented yet, it is the responsibility of Humanode Core to gradually introduce the technical implementation as well as oversee the transition of power.

If you have delved into details of how the governance will be structured, you might know that for security reasons, regardless of how well-formed the governance system is going to be, any decision taken would need the approval of 66% of the Consuls. This need for authorization will be lifted only at full decentralization to mitigate the vectors of attacks that a newborn protocol with mildly tested Sybil-resistance can't handle. Thus to retain the power of Consuls without the existence of on-chain governance, we have implemented the sudo pallet with multisig.

Why sudo pallet?

Sudo pallet is an on-chain Substrate module that allows arbitrary change of the chain state. Sudo pallet is an effective initial implementation of what we described in the paper, just a more manual way of implementing the same logic.

Sudo pallet brings centralisation risks: the person controlling the key can change the state of the ledger. We are addressing this issue by introducing a multisig pallet.

Mitigating centralisation risks: multisig

Multisig pallet - a module that contains functionality for multi-signature dispatch, allowing multiple signed accounts to coordinate and dispatch a call from a well-known origin. Multisig account has a threshold of signatures required to enable an on-chain transaction or a runtime upgrade.

As there are now 3 Consuls in Humanode, the sudo account is controlled by three accounts set up at the chain's genesis. In the whitepaper released in 2020, we stated that more than 66% of votes are required to approve core proposals; that's why the current sudo key is a multisig with a 3/3 threshold.

There are two risks to having a 3/3 multisig. The first one is that one of the keys can be lost or compromised, meaning that Consuls won't be able to approve any transaction. The second one is that all three keys will be compromised, and the attacker will be able to perform arbitrary changes to the chain state. Both of the issues will be mitigated with a hard fork.

Mitigating centralisation risks: community transparency

In the meantime, we will add support for delayed calls via the scheduler pallet to enable community awareness. Note – this is not a time-delayed proxy because we require immediate intervention in some of the anticipated needs for using the sudo keys, mainly for the zero-down-time disaster recovery. The scheduler pallet enables us to provide community awareness of privileged operations where applicable.

The community can easily track all the sudo operations through our explorer. Later on, we'll release a separate web page where you'll be able to see the history of all sudo operations.

Also, from now on, every sudo transaction will be announced beforehand with descriptions of what it does. With call data posted in a separate thread, it would be easy to decode it in polkadot.js, check the changes and then let the community discuss it.

As with any blockchain, if the community does not agree with the sudo operations, members would be able to fork the Humanode chain.

Short-term decentralization plan

In the coming months, we plan to launch the Proposal Pool, Vortex, and Formation as temporary off-chain substitute applications. While they will mimic the governance process described in the whitepaper, enable proposals, voting, and DAO workflow, making the operations transparent, Consuls will still guarantee the security of on-chain operations and upgrades. It is the responsibility of the Consuls to oversee the democratization of the decision-making and mitigate the violation of the processes stated in the whitepaper.

Long-term decentralization plan

We will implement a DAO-based governance system to eliminate the sudo keys altogether in the long run (Vortex). It will include the following:

• A time-delayed proxy with reasonable duration, such as 48 hours, for community awareness of privileged operations;
• Introduction of an on-chain DAO, governance, and voting to increase decentralization, transparency, and user involvement.