Always abortable Head

[ch1bo]

Why

We want Hydra Heads to be safe to use. This means that we can always abort initialization of a Hydra Head and no already committed funds can "get locked in" a Head.

Also, we want to not (artificially) limit how many UTxOs an individual participant can commit.

Currently after committing some UTxO into a Head, it either needs to be collected when the Head becomes open, or gets reimbursed in an abort transaction. Both, collect and abort need to process all the commits at the same time. This is problematic if, adversarial or by accident, someone commits a UTxO complex enough that neither collect nor abort is possible - fits into the L1 transaction limits. This is especially true since Babbage, where outputs can have big inline datums, and if we want to relax the limit of only committing one input. This is related to #698 and #190, but this one here is only about the initialization stage of the Head.

What

Multiple alternative solutions have been identified so far:

1. Individual abort
   • Each participant needs to reimburse their own commit with a restore transaction
   • An additional cleanup transaction can be used to clean up the head output
   • Remove abort transaction as known so far
   • Pseudo-code: https://docs.google.com/document/d/1cmzAkimFfSx-Et68Zk0JUaj-rf1NGWsmJNGzTdLcQRo/edit#
2. Undo commit transactions
   • A participant can reimburse their own commit with an undoCommit transaction
   • This reverts the head state as if the participant never committed
3. @pgrange proposal of changing the whole protocol in how a head is opened
   • do off-chain interaction to in-turn multi-sign a transaction doing all the work
4. Implement and use incremental commits only and open the head directly Incremental commit #199

Within this item we want to explore both, but only implement one variant.

How

• Create an ADR outlining decision & consequences for both alternatives
• Implement the protocol change in validators, transaction creation / observation and protocol logic
• Update all interfaces and documentation to potentially new terminology
• Remove the hard-coded limit of maximum parties as we will always be able to abort now if collect "does not fit".

Some thoughts

• Variant 1: cleanup may orphan the commits and Head state is not "containing" it the same way
• Variant 2: keeps the same overall life-cycle

[ch1bo]

Discussion: Do we need this before aiming for mainnet? It depends on the risk of this situation happening / being possible. Also, this attack is not about stealing funds and is really a denial of service attack.

[ch1bo]

Closing this as not planned as we decided to explore alternative 4. of #1329 in a dedicated feature.