Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit size/complexity of UTxOs in Head #698

Closed
ch1bo opened this issue Feb 3, 2023 · 2 comments
Closed

Limit size/complexity of UTxOs in Head #698

ch1bo opened this issue Feb 3, 2023 · 2 comments
Labels
💭 idea An idea or feature request

Comments

@ch1bo
Copy link
Member

ch1bo commented Feb 3, 2023

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 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
  • limit the size/complexity of snapshots that get signed off-chain (also covered by Only sign closable snapshots #370)

How

  • 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.
@ch1bo ch1bo added the 💭 idea An idea or feature request label Feb 3, 2023
@pgrange pgrange mentioned this issue Feb 8, 2023
4 tasks
@ch1bo
Copy link
Member Author

ch1bo commented Mar 15, 2023

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.

@ch1bo
Copy link
Member Author

ch1bo commented Mar 21, 2023

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.

@ch1bo ch1bo closed this as completed Mar 21, 2023
@ch1bo ch1bo closed this as not planned Won't fix, can't repro, duplicate, stale Mar 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💭 idea An idea or feature request
Projects
None yet
Development

No branches or pull requests

1 participant