Multi-sig Deployment

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.

Execution Pace

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.

Program upgrades

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.

Transparency

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

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

Conclusion

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.

Comments

Post a Comment

Popular posts from this blog

CAP Theorem and blockchain

Image
In theoretical computer science, the CAP theorem states that it is impossible for a distributed data store (such as a blockchain network) to simultaneously provide more than two out of the three guarantees: Consistency, Availability & Partition tolerance. CAP Theorem – the parts C: Consistency – At any given time, all nodes in the network have exactly the same (most recent) value. A: Availability – Every request to the network receives a response, though without any guarantee that returned data is the most recent. P: Partition tolerance – The network continues to operate, even if an arbitrary number of nodes are failing. Due to the nature of distributed data stores (such as blockchain), Partition tolerance is a given fact; there will always be failing/unreachable nodes in the network (not least because of the unstable nature of the internet). CAP Theorem states that one has to choose between C (Consistency) or A (Availability) when in the presence of P (Partition): Av...
Read more

Length extension attack

Image
What is length extension? When a Merkle–Damgård based hash is misused as a message authentication code with construction H(secret ‖ message), and message and the length of secret is known, a length extension attack allows anyone to include extra information at the end of the message and produce a valid hash without knowing the secret. Quick sidebar, before you freak out: Since HMAC does not use this construction, HMAC hashes are not prone to length extension attacks. So, a length extension attack is a type of attack where an attacker can use Hash(message1) and the length of message1 to calculate Hash(message1 ‖ message2) for an attacker-controlled message2, without needing to know the content of message1. Algorithms like MD5, SHA-1 and most of SHA-2 that are based on the Merkle–Damgård construction are susceptible to this kind of attack. Truncated versions of SHA-2, including SHA-384 and SHA-512/256 are not susceptible, nor is the SHA-3 algorithm. A bit more details ...
Read more

Contract upgrade anti-patterns

Image
A popular trend in smart contract design is to promote the development of upgradable contracts . To be fair, existing techniques to upgrade contracts have flaws, increase the complexity of the contract significantly, and ultimately introduce bugs - even in the Zeppelin contract upgrade strategy. In this article, we are going to detail our analysis of existing smart contract upgrade strategies, describe the weaknesses we have observed in practice, and provide recommendations for contracts that require upgrades. In a follow-up blog post, we will detail a method, contract migration, that achieves the same benefits with few of the downsides. An overview of upgradable contracts Two ‘families’ of patterns have emerged for upgradable smart contracts: Data separation, where logic and data are kept in separate contracts. The logic contract owns and calls the data contract. Delegatecall-based proxies, where logic and data are kept in separate contracts, also, but the data contr...
Read more