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