Multisignature transactions

Background

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.

Problem

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 used 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.

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.

Solution

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. Main questions should be answered before that.

Decisions

Multisignature transaction identification

Given `M` as required amount of signatures to collect and `N` as a set of legal signatories Then if `M` is greater than 1 Transaction should be treated as Multisignature.

Signatories set

As mentioned in "Multisignature transaction identification" `N` is a set of legal signatories. What variants we can have in this set?

• One unique signatory of one account.
• Several unique signatories of one account.
• Several unique signatories of several accounts.
• Any signatories of one account.
• Any signatories of several accounts.
• ...

So how we can describe `N`?

enum N {
    Quantity(usize),
    Holders([AccountId]),
    Set([Signatory]),
}

In this case `Quantity` variant is less restrictive than goes `Holders` and `Set` as most restrictive. 

Configuration

Multisignature Transactions can be configured by a combination of `CheckSignatures` Iroha Special Instruction mandatory for every transaction with `N` Initial transaction's author Account's Asset. 

If `CheckSignatures` passed successfully rest of instructions applied to the state. Otherwise transaction will be send to all peers. 

Alternatives

Concerns

• Should we guarantee persistence of Multisignature transactions waiting for required signatures on the ledger?
• Should we provide configuration of Multisignature without assets (client only)?
• How to merge Multisignature transactions signatures?

Assumptions

Risks

Additional Information