Aggregated multi-signatures

[ch1bo]

Why

Users expect a Hydra Head to be fast & cheap to use. That means, that the off-chain protocol is quickly confirming transactions and the costs for moving funds to the L1 are low. The multi-signature scheme used in the Head protocol is influencing this in two ways:

• Each snapshot needs to be signed by members individually, aggregated into a multi-signed snapshot and verified for correctness off-chain. The time & space cost for this is impacting confirmation times in the L2.
• That multi-signed snapshot will be verified by the Head validator on-chain when closing & contesting the head. Consequently this impacts the size & cost of the close & contest transactions on the L1.

What

Currently, the on-chain verification (#145) uses a simple non-aggregated multi-signature. That is, a list of signatures of each Head participant is used to certify correctness of the Head state. This is more verbose than necessary and scales bad with a growing number of participants, so closing and finalizing a Head is more expensive.

To be discussed: To address this, we have looked into various aggregated multi-signature schemes and decided to go with musig2 of which a proof-of-concept implementation was done at IOG: https://github.com/input-output-hk/musig2. While this requires some additional coordination work when creating signatures, verifying these signatures is possible off-the-shelf already with current versions of cardano-node and plutus.

TBD

• Other alternatives? BLS signatures?
• Musig2 details: Exchange nonces over L2 network and key registration?

[ch1bo]

Marked as idea again as we need a clearer understanding of the benefits (performance or security implications of this)

[perturbing]

Hi, have you considered using the BLS12-381 curve for aggregated signatures? Some basic builtins over the two pairing curves will be introduced with CIP-0381. For more info on these curves see the CIP but also this nice blog and this.

Some benefits I can see, you get more flexibility in scripts since you can partially aggregate things onchain (which will not be possible for the SECP solution since you can only check signatures). I am uncertain if this is a plus, since you want to minimize computation onchain, but it's possible :)

About the cost, the plutus builtins are not costed yet, but the final verification of an aggregated signature using BLS12-381 is given by one hash to curve operation, two miller loops and one equality check in the bigger group.

Edit: I think they are cost of these builtins are known now, see this PR.

[ch1bo]

I'm not really familiar with BLS signatures, but will look into it. Would you know whether there is any interaction required to do aggregated multi-signatures? i.e. do the individual actors need to exchange any additional information besides a public key