Abstract
By default Iroha works with single-signature transactions which are accepted by the peers signed only by one signatory. However in some cases it is not enough.
Example
Let's take an example of selling good from Seller to Buyer with independent Arbiter involved . Buyer sends XORs Transfer Iroha Special Instruction needed to cover the price of the good.
Seller should send a physical good to the Buyer to complete XORs Transfer. Multisignature transaction could be use to make this process safe.
M-of-N
If M is the required number of signatures and N the total number of available signatures so in this example we need to set `M=2` and `N=3` (restricted by Signatures of Seller, Buyer and Arbiter).
In case of an "easy" deal Buyer and Seller both add their signatures to the transaction letting Iroha to process Transfer Instruction. If one of the parties decided to not sign the transaction, Arbiter can decide to add or not to add it's signature.
If Arbiter will try to Transfer XORs to itself, it will fail because one signature is not enough in this situation.
Introduction
Multisignature transactions in general provide an ability to restrict some actions for individual signatories, to implement them in Iroha we need to check more specific requirements from stakeholders.
Requirements
From Iroha 1:
A transaction which has the quorum greater than one is considered as multisignature (also called mst). To achieve stateful validity the confirmation is required by the signatories of the creator account. These participants need to send the same transaction with their signature.
And from Iroha 1 again:
Multisignature Transactions Processor
It is an internal gRPC service that sends and receives messages from other peers through Gossip protocol. Its mission is to send out multisignature transactions that have not received enough signatures to reach the quorum until it is reached.
From Vadim Reutskiy
1. To have quorum in each account and possibility to change it by the command (+ corresponding permissions)
2. To have possibility to configure list of signatories for the current account (+ corresponding permissions)
3. To have possibility to get list of pending transactions waiting for the additional signatures (related to the current account or in network in general + corresponding permissions)
4. Configuration of the time, while pending transactions will be in the pending list before being rejected
5. Corresponding checks in stateful validation to check all these rules
6. Corresponding checks and sync in the block proposal algorithm, consensus and mechanism of syncing the list of pending MST transactions between all nodes.
7. Place for future insertion of the conditional logic for MST checkups
Conditional multisignature
From the whitepaper: https://github.com/hyperledger/iroha/blob/iroha2-dev/iroha_2_whitepaper.md#conditional-multisignature
Let's consider a situation where a bank wants to allow either 2 tellers or 1 manager to sign off on any transfer transaction over $500 and under $1000. In this case, the condition will be: Condition.asset("usd@nbc").qty(500).comparison(">").qty(1000).comparison("<") and the signatory_sets for the tellers and manager will be OR unioned, so that either the m-of-n signatues from the tellers or the single signature from the manager will be acceptable for transaction signing.
Iroha 2 Adoption
Second version of Iroha evolved the design of Iroha 1.x and can't use the same approach while it works to address requirements.
First of all - we minimize domain entities in Iroha 2 and implement such a things like Event Listeners and Permissions as a combination of Iroha Special Instructions and Assets.
The same way Multisignature transactions implementation can be done.