Pending and MST transactions sharing between peers

Shorthand

Discussion participants: Egor Ivkov, Salakhiev Kamil, Andrei Lebedev, Nikita Puzankov

Egor Ivkov :

@mtakemiya what should be the actions of a peer when it receives pending transactions as part of gossip between peers?

Salakhiev Kamil :

if transaction has less signatures than the size of the quorum, then we should put it into the pending transaction pool. In the pool we maintain the signatures of transactions, so that when some transaction collected enough signatures it is sent further into the pipeline (in case of Iroha 1 transaction was sent to ordering service)

Andrei Lebedev :

However, size of the quorum is unknown when the transaction is received

Salakhiev Kamil :

yes, in Iroha1 quorum was put into transaction, but there were no way to check that given quorum is valid, right?

Andrei Lebedev :

Considering this approach, it may be better to try to process it until it becomes valid or expires. It is possible to check quorum if WSV is accessed.

Salakhiev Kamil :

yes, so for MST transactions we kind of start stateful validation earlier? although if WSV is in memory then there is no issue, so we don’t need to put quorum into transaction as it was in Iroha1.

Makoto Takemiya :

It should validate the stateless data (format, signatures) and add it to their queue. One of these lucky peers will become the block creator and leader of consensus for the next block.

It is probably okay to wait for multisig quorum check until later. The block creator can do that. Otherwise another approach is to create a pending multisig tx queue and put it in there. Either approach seems acceptable I think.

TL;DR

For Multisignature transactions we have the following algorithm: keep them in "pending" transaction queue until we will receive enough equal transactions with different valid signatures. Then we process them as usual single signature transaction.

Current State

Right now in our implementation Transaction has four states: Requested, Accepted, Signed and Valid.
In code we have:
1. When torii receives transaction from client its state is `Requested`.
2. Then the transaction is added to the queue of `pending_tx` and its state becomes `Accepted`

In what state should transactions be forwarded to other peers?

Nikita Puzankov suggested: Periodically all the transactions from the queue are forwarded to other peers, and when forwarding their state turns again to `Requested`. And they are added to the queue by receiving peers making state again `Accepted`.

Egor Ivkov suggested: Peer should sign it's transactions before forwarding them, otherwise we will not be able to gather signatures and proceed to Signed state.

When are the transactions signed?

Based on current implementation there can be a situation when peer receives pending_tx that it already built a block from, so it will build another block from the same tx. How should this situation be handled?