Page History

Background

By default At the time of writing 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. There is a need for transactions that should be signed by several signatories from the same account for security purposes when dealing with large sums of money. Also it is planned to support conditional multisig (for example to support typical scenarios as two tellers should sign or one manager should sign). The detailed description of conditional multisig can be found in the whitepaper.

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.

...

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

...

Conditional mutlisig

The conditional multisig is planned to be implemented with the support of the Expressions that let the user to define their own conditions. An example implementation of the whitepaper scenario is given in one of the expression tests.

Transaction Pipeline

In Iroha2 there will not be a strict division between a multisig and a simple transaction. Instead transactions will be collected on the leader peer in a queue until the moment its account's `signature_condition` (in the form of Expressions) is true for this transaction or dropped when its TTL is reached.

Client Side Interaction

Iroha 1.x Approach

It was considered to use the same approach as in Iroha 1.x and to send the same transaction several times with different signatures from the client. But there is a following problem with this approach:

Transaction hash incorporates the timestamp of transaction creation in Iroha2. So even if transaction were sent with the same contents, the hash because of the timestamp will be different, and therefore it would be impossible to aggregate signatures (which have hash as a payload).

Iroha 2 Approach

Therefore in Iroha2 the following approach is planned to be used.

1. First client to submit the MST transactions, submits it normally as any other transaction
2. Other clients that want to add signatures to this tx request this pending tx from the Iroha peer and sign it with their signature and resubmit it.

But the UX does not need to change for the end user. For example:

1. User wants to submit a transaction
2. Client library requests if there are any transactions waiting for signatures from this account
3. If there are, it acquires them and compares to the one that user wants to submit
4. If contents of transaction match excluding the timestamp
5. Client library asks if the user wants to add a signature to already existing transaction

Therefore users may submit MST asynchronously without the knowledge of who submitted it first.

Concerns

...

Assumptions

Risks

Additional Information