Use Mithril to sign and verify Hydra snapshots

[abailly-iohk]

Why

Current Hydra Head consensus mechanism requires all nodes to be online for liveness. Using a snapshot signature process the does not require collecting all parties' signatures while still being customisable and negotiable (eg. in terms of the quorum required) would make scenarios where some of the peers can go offline without compromising progress, while still retaining some degree of security related to honest quorum assumptions.

What

• Use Mithril to sign Hydra Head snapshots
• Set Mithril protocol parameters when the head is initialised

How

• Mithril technology is available as a service (both for signer and aggregator) and/or library which could be run alongside hydra nodes to produce signatures from arbitrary snapshots (eg. blobs)
• The protocol would still be leader based with the leader proposing a snapshot through the ReqSn, the followers signign the snapshto through the AckSn messages and everyone independently verify the snapshot through the standard mithril TMS
• We would need to be able to verify Mithril signatures on-chain when closing, but I understand this should be possible once BLS crypto is integrated in Plutus. @iquerejeta could confirm

[iquerejeta]

If the security model allows for a strict subset of members to produce a signature, then we could explore threshold signatures. However, AFAIU, hydra's security model is based on the assumption that we need everyone to produce a signature for security.

If that's not the case, there's a few things to consider before choosing going forward with Mithril.

• How large are we expecting the committee to be? Mithril is designed for large committees, were we expect a large amount of non-participants. I believe none of this conditions apply in Hydra.
• How often we want to verify snapshots on main-net? While verifying Mithril certificates will be possible, it might not be practical. Working with parameters used for cardano main-net, the size of Mithril certificates is the following

+----------------------+
| Hash: Blake2b 256    |
+----------------------+
k = 554 | m = 3597 | nr parties = 3000; 113728 bytes 

• Can we work with Ad-hoc Threshold MultiSignatures (ATMS) instead? These are more efficient in the 'optimistic case'. This means that the more people sign, the shorter and cheaper is the signature. Also, this design is made for smaller committee sizes, so it might be a more interesting alternative. While there does not exist an audited ATMS implementation, there exists a Rust library (which I have just realised it has been archived.

[uhbif19]

There was some discussion on such consensus change in Hydrozoa thread: #850 (comment)