Shorthand
Discussion participants: Egor Ivkov, Salakhiev Kamil, Andrei Lebedev, Nikita Puzankov
Egor Ivkov : [20.04.20 13:34]
@mtakemiya what should be the actions of a peer when it receives pending transactions as part of gossip between peers?
Kamil' Salakhiev, [20.04.20 13:38]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, [20.04.20 13:39] :
However, size of the quorum is unknown when the transaction is received
Kamil' Salakhiev, [20.04.20 13:40]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, [20.04.20 13:40]
[In reply to Никита Пузанков]
:
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.
Kamil' Salakhiev, [20.04.20 13:42]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 武宮誠 (Sora.org - Soramitsu), [20.04.20 14:45]
[In reply to Egor Ivkov]
:
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`
...