Multi-signature (or multisig) wallets presents a way for different participants to agree (or disagree) on a particular transaction on the blockchain (ie, issuance of a electronic bill of lading on a token registry), but is that the only way? In this article I explore various options to represent the signalling of the intent for a transaction that requires more than one participant to agree on. In addition, there will be suggestions on which methods to be used in different circumstances.
In each of the different methods, notice how there must be a layer of abstraction which amalgamates the different participants into a single entity.
The different types of solutions will be broken down into two broad categories, on-chain solutions and off-chain solutions.
On-chain solutions allow for all observers of the blockchain to see that the different participants of the transaction has agreed on the transaction. On-chain solutions are used in instances where the participants' public address are associated with known real-world identities from the perspective of observers. Should the participants' real-world identities not be associated with their address, the act of signalling intent via separate addresses has no meaning to the observer.
Multisig wallets are contracts that abstract the access controls from the contracts with the business contract. They play a role as the gatekeeper and usually the only address allowed to interact with the business contract from the joint entity point of view.
Several multisig contracts are readily available for immediate use and can be found here. If more complex access control patterns are needed, custom multisig contracts can be created.
With these contracts, there will be abstraction of internal controls since the smart contract handles the logic yet providing observers the transparency of the internal control via the public code.
Off-chain solutions allow for business constraints be enforced without publishing these details which are not useful for other observers on the blockchain. In all solutions, observers on the blockchain will only see one transaction originating from one address associated with the joint entity. From the perspective of the observer, it does not need to know how the entity is being organized internally.
This is particularly useful when observing that a transaction originates from a business entity, as oppose to a transaction originating from two different directors, a secretary and a temporary admin clerk of the companies. In the latter, it's extra work for the recipient to:
MPC allows for different entities to jointly compute the signature to a transaction, with each having their own private keys without the need of a master private key or trusting any other entities to the process
Transaction signing can also be controlled by softwares. Most businesses would have softwares that they use to manage internal workflow. These business could simply build the signing and publishing of blockchain transaction into their business process management platform and rely on the access controls and workflow they are most familiar with.
While the business can store the private key to the wallet on some VM or environment which the developers may gain access to, they may also consider secret management softwares like Vault or even the use of hardware security modules (HSM) for key generation, storage, signing, etc.
Aside from mentioned method, one common method continuously arise during discussions which is to append the signatures from multiple parties onto the data itself. From OpenAttestation documents perspective, it means that the signature is added as additional fields.
The idea likely stems from legacy reason where it is not possible to separate the joint entity from its multiple participants. For instance, it is impossible to have a company sign on a form, the proxy for that is to have a common requirement for authorized person (such as the Singapore Company Act) or have a common seal.
The problem with this method is that is separates the intent (the individual signatures) from the action (the actual blockchain transaction). Observers will not only have to validate the blockchain state but also additional business requirements not on the blockchain. This not only creates an opportunity for dispute where it is possible to have scenarios where the intent exist without the action and for the action to exist without the intent but also add complexity to programs interpreting these transactions.
As such, this method should be avoided at all cost.
The use of a common seal should be replaced by one of the off-chain signalling method since it is possible to establish the signing key as the "common seal".
The use of multiple signing parties should be replaced by the on-chain signalling methods if identity of the participants are known to intended observers.