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]
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]
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
Andrei Lebedev, [20.04.20 13:41]
[In reply to Kamil' Salakhiev]
It is possible to check quorum if WSV is accessed
Kamil' Salakhiev, [20.04.20 13:42]
yes, so for MST transactions we kind of start stateful validation earlier?
Kamil' Salakhiev, [20.04.20 13:43]
although if WSV is in memory then there is no issue
Kamil' Salakhiev, [20.04.20 13:44]
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
Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [20.04.20 14:46]
It is probably okay to wait for multisig quorum check until later. The block creator can do that
Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [20.04.20 14:46]
Otherwise another approach is to create a pending multisig tx queue and put it in there
Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [20.04.20 14:47]
Either approach seems acceptable I think.
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?