What is multisig
Multi-signature is a digital signature scheme, that allows a group of users to sign a single transaction. The transaction could be a governance proposal, a snapshot vote, or even a simple fund transfer instruction. A common terminology to describe a multisig setup is m-of-n multisig. Given n parties with their own private keys, at least m of the private keys must sign a transaction to perform a transaction. For example, a multisig that has 7 members in the group and requires 4 signatures for a transaction to be fully signed — will be termed 4-of-7 multisig.
The need for a multisig administration
Before we answer the question — why do we need multisig administration? — let us first understand how it supplements the deployment management. The smart contract that is being deployed onto the chain, holds logic — sometimes worth millions of dollars. Think about swapping contracts in the decentralized exchange managing all the business logic. And in order to deploy these contract into the main-net, someone needs to sign it. Who should it be? Company devops engineer, the developer who created these contracts, VP of RnD… Do you see where I’m going, there should be a single person, who signs the deployment, which is against everything blockchain is stands for — being a decentralised system.
To understand why offloading the decision-execution to multisig administration is a good approach let’s look at the different administration methods that are possible in such a scenario:
- A single person could act as the administrator. This has a very low overhead, and the administrator can move quickly when there is a need to deploy a critical bug fix. However, it also places a high degree of trust in a single person.
- On the opposite side of the spectrum, a decentralised autonomous organisation (DAO) program could act as the administrator. Administrative tasks could only be executed after a majority of token holders approve. This is decentralized, but it makes it very difficult to act quickly when needed.
A good middle ground between these two extremes is multisig, a program that executes administrative tasks after m out of n members have approved. For m greater than one, no single party can unilaterally execute administrative tasks. At the same time, we only need to coordinate with m parties (instead of a majority of the token holders) to get something done.
The benefits of multisig don’t end here. Using a multisig eliminates a lot of concerns that a typical an end-user might have while investing or the manager while delegating. Let’s take a look at some of the other problem areas that the use of a multisig addresses.
Reducing points of trust
Can I trust the creators of the program to not change critical parameters of their own accord? There is always the risk that an administrator or the contract developer can start executing decisions arbitrarily. By including multiple parties in the multisig, we reduce the points of trust and make the decision execution more decentralized.
Can the RnD perform program upgrades quickly, in case of a critical bug? A pitfall of on-chain governance is that in the case a critical bug-fix is required, achieving consensus on-chain could prove to be too slow and very costly as a result. A completely decentralized model of governance slows down project execution, especially if a project is in its initial stages. There is always a tradeoff between the ease of execution and the degree of decentralization. However, that does not mean that one should do away with decentralization completely. A governance model carried out by a multisig administration is the perfect compromise for a project. This lends it speed to execute decisions quickly in the earlier stages and also mitigates the risk of delayed fixing of critical bugs.
The multisig decides on program upgrades. To understand why this is a reasonable solution, we need to take a look at the two possible extreme cases:
- Single upgrade authority — in many blockchains the upgrade authority, the address that can sign upgrades, has a lot of power. A single upgrade authority could upgrade programs maliciously at will. For example, a malicious upgrade authority could upload a new version of the program, containing a bug, which would allow to withdraw all the funds into some address. As addresses on blockchain are anonymous, there is no way to know to whom the monies were transfered.
- No upgrades allowed — On the other hand, if we don’t allow the program to be upgraded at all, and then if it turns out to contain a critical bug, we can’t fix it.
So, a multisig is a good middle ground, where no single entity can take control over the programs and their funds, but we can still enable upgrades.
Is the source code public and has it been verified that program is built from that source code? It is imperative for the organisation, to be sure that the program does not contain any backdoors or hidden features that might hurt their investments. One way to be sure of this is to know that the multisig owners have verified that the multisig programs were built from the source code.
Multisig ceremony is the process that the multisig uses to execute decisions. On a high level, this process works as a series of steps:
- Build a blockchain transaction
- Wrap the transaction in a multisig transaction (Instead of signing it with a wallet and executing, like we normally would)
- Sign and broadcast the wrapped transaction to the blockchain
- Notify the other N-1 signers to review the transaction
- The signers sign and submit their approval transactions to the blockchain
- When the multisig transaction has enough approvals, anybody (usually the last party to approve) can step in and execute the transaction
As explained earlier, multisig programs require multiple signatures to approve a transaction. This allows the signers to review an action on the blockchain before it is executed — making for decentralized governance. On Solana you can use Serum Multisig program to introduce decentralization. On Etherium you can use Gnosis Multisig. The process is faily simple an well documented in the relevant site.
Originally published at https://deeprnd.blogspot.com on November 21, 2021.