You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want Hydra Heads to be safe to use. This means that we can close & fanout the L2 state at any point throughout the life-cycle of a Hydra Head and no funds can "get locked in" a Head.
For this matter we have limited commit transactions to only allow committing 0 or 1 UTxO. However, at least since babbage with reference scripts in outputs, this is not enough to "protect" a Head from not being fanoutable. It's possible that one party commits a specially crafted UTxO which is just complex enough to make the whole U0 fit in the collect, but could be too big / complex to be redistributed in a single fanout transaction.
Also, we would like to not artificially constrain the number of UTxOs to be committable.
What
Besides this feature idea, there is also #190 which would make this redundant.
A short-term solution for this is to
limit the size/complexity of what can be collected on-chain
We do not have access to protocol parameters and limits on-chain and would not know what the fanout transaction will look like when checking the collect tx.
The limit for this is to be found empirically by estimating the size/memory/cpu budget of the fanout transaction given certain UTxOs.
We hope to identify a single, deterministic metric to do this check also on-chain
Idea: Use the length of the concatenated bytestring of all serialized tx outs. It is a discriminator in both checks.
The text was updated successfully, but these errors were encountered:
Should discuss whether we ditch this. We have written a property test to confirm, that the collect step is always more expensive than close and fanout steps. This covers the on-chain part, while #370 does cover the off-chain part of not signing UTxO sets which cannot be finalized on-chain.
Closed as it is practically not needed, because collect is always more expensive than fanout (and close). We also introduced a test which would detect when we could collect, but not close and fanout.
Why
We want Hydra Heads to be safe to use. This means that we can
close
&fanout
the L2 state at any point throughout the life-cycle of a Hydra Head and no funds can "get locked in" a Head.For this matter we have limited
commit
transactions to only allow committing0
or1
UTxO. However, at least since babbage with reference scripts in outputs, this is not enough to "protect" a Head from not beingfanout
able. It's possible that one party commits a specially crafted UTxO which is just complex enough to make the wholeU0
fit in thecollect
, but could be too big / complex to be redistributed in a singlefanout
transaction.Also, we would like to not artificially constrain the number of UTxOs to be committable.
What
Besides this feature idea, there is also #190 which would make this redundant.
A short-term solution for this is to
How
fanout
transaction will look like when checking thecollect
tx.The text was updated successfully, but these errors were encountered: