Multiple Authorisation (aka., Multisignature)
Given a pool of n addresses that could authorise a payment, get a subset m of them to authorise a payment by signing the respective transaction (m ≤ n).
In blockchain-based applications, activities might need to be authorised by multiple blockchain addresses. For example, a monetary transaction may require authorisation from multiple blockchain addresses. Also, to release payments/tokens held by an escrow, both buyer and seller need to confirm successful delivery of product or service.
All the addresses that can authorise an activity might not be reachable at the time of issuing the transaction due to the sporadic or limited availability of some authorities. Also, it may not be possible to decide on all possible approvers in advance. How can a transaction be authorised by a subset (> 1) of approvers?
- Dynamism – A transaction needs to be authorised by a subset of authorities pre-defined in a pool of addresses. However, some of the authorities may not be available, unreachable, or related private key may be compromised when issuing the transaction. Also, the address pool needs to be changed as the application evolves, e.g., the addition of a new authority or revocation of an existing authority.
- Tolerance of lost key – Authentication in a blockchain is based on digital signatures. However, blockchain does not offer any mechanism to recover a lost or a compromised private key. Thus, losing a private key on the blockchain means permanent loss of control over a blockchain account and associated smart contracts as blockchain does not provide any key recovery mechanism.
- Flexibility – The parties that could authorise a transaction can from a set of predefined authorities.
A transaction could indicate multi-party authorisation using a digital signature scheme that allows a group of addresses to sign the transaction. Such a signature is known as a multisignature. Depending on the chosen multisignature algorithm, we can enforce that the transaction is signed by all or a subset of the authorised addresses. As depicted in the following figure, to enable flexible binding of pre-defined authorities for a payment transaction, a multisignature mechanism can be designed to require m out of n private keys to authorise a transaction, in which m is the threshold of authorisation (2 ≤ m ≤ n).
Multiple authorisation pattern
Depending on the context, a smart contract’s owner/manager can pre-define a group of addresses that can authorise a transaction and set the minimal number of authorisations required to approve a payment. Some blockchain platforms accept transactions containing a multisignature. For example, in Bitcoin, a multi-signature mechanism can be used to require more than one private key to authorise a transaction. However, a multisignature is more commonly validated using smart contracts. For example, in Ethereum, smart contracts can mimic multi-signature mechanisms. Such on-chain mechanisms enable more flexible binding of authorities.
In the simplest form, each authorised address can submit a signed transaction to the multisignature smart contract that keeps track of the number of transactions with valid signatures. Once the number of valid transactions reaches the pre-specified threshold, the smart contract can perform the token payment. Alternatively, more efficient signature schemes, such as threshold signatures, could be used to generate a short signature off-chain and submit to the smart contract using a single transaction. In either case, the pool of authorised addresses needs to be pre-specified before issuing the transaction. When the membership change, threshold signature schemes usually require regeneration and distribution of all the keys/addresses.
- Dynamism – Multisignature allows flexible binding of authorities for approving a transaction.
- Tolerance of lost keys – The risk of losing control over smart contracts is reduced as one participant can have more than one blockchain address in case a private key is lost. One participant can own more than one blockchain address to reduce the risk of losing control over their smart contracts due to a lost private key. In a smart contract implementation, of this pattern, there could be a function to update the list of allowed authorities and the authorisation quorum. This update function may also require a quorum.
- Flexibility – This pattern enables flexible binding of authorities.
- Risk of key loss – There is still a risk of losing control over smart contracts when m private keys among the n private keys are lost.
- Cost – If a public blockchain is adopted, storing multiple addresses, updating the list of addresses, and issuing multiple transactions cost money. There is a greater cost for storing multiple addresses compared to only one.
- Predefined authorities – Although the pattern enables flexible binding, all the possible authorities still need to be known in advance of any decision or update.
- The escrow pattern can use a multisignature to get confirmation from both buyer and seller about the successful delivery of a product.
- A decentralised oracle can use multisignature to confirm the physical state of a product from multiple attesters.
- The voting pattern could be implemented using this pattern.
- This pattern complements the embedded permission pattern.
- Off-chain secret enabled dynamic authorisation pattern is used when the possible authorities are unknown beforehand.
- Multisignature is offered by Bitcoin to authorise transactions.
- Multisignature wallet, written in Solidity and running on the Ethereum blockchain, is available in the Ethereum Dapp browser Mist to approve transactions.
- A multisignature wallet is used in TokenMarket security token to confirm critical activities that affect the shareholder balances.
- Data filed in the ERC-1400 standard can be used to submit a multisignature signed off-chain using a single transaction.