Affects Version/s: None
Fix Version/s: None
Sprint:11, 13, 14, 12, INDY 17.21, INDY 17.22
- Is it Primary who calculates multi-sig?
- Where do we store multisig? Is it a separate db? If we need historical proofs, then we need a protocol to have it always in sync and be able to restore/catch-up it.
- Store the nodes participated in the signature together with the multi-sig (since it’s possible that only n-f nodes participated)?
- Need to think how to represent the Nodes participated in multi-sig:
- Option1: Each Nodes calculates and stores multi-sig independently
- Each COMMIT contains sig_i.
- Once each Node orders a txn, it calculates the multiplication of sig_i (>= n-f), and stores the sig and nodes participated in multiplication in a separate DB.
- It’s possible and fine that multi-sigs are different for the same state for different nodes (because they may receive different set of COMMITs). The only requirement that >=n-f nodes must sign.
- It’s OK that a Node may miss a multi-sig in its own DB. In this case a client should ask another Node.
- Also we may implement requesting of missing signed states.
- Do we need to verify multi-sig of a previous batch sent with PRE_PREPARE? Isn’t the multi-sigs crypto and the requirement of having n-f participants already provides all necessary info for state proofs?
- Option2: Primary calculates the multi-sig and it’s persisted with the next batch
- Primary calculates the multi-sig and stores it in its own DB.
- During the next PRE-PREPARE, other nodes verify multi-sig, and if it’s fine, then they store it in they own DBs (so, we have a lag between ordering and signing).
- We may have incorrect multi-sigs stored in primary’s DB if the primary is malicious. Probably that’s not a big problem.
- If nodes find that primary’s multi-sig (for last batch) is invalid, then should the new primary re-calculate it?