React to protocol parameter changes

[ch1bo]

Why

On cardano parameters can change any epoch. That is, the underlying costs for executing plutus scripts could change. As user of Hydra heads we want to be able to close/finalize heads (or other features) to not be impacted by these changes unnoticed.

What

• The hydra-node does detect protocol update proposals on the layer 1 and informs users about them.

  • This is of warning severity -> it may be relevant for some applications.
  • In the logs and through the API.
  • Both, on the update proposal and when the parameters changed is detected.
  • This message includes:
    • Proposed updates
    • Effective slot and time (projected)
    • If a head is open:
      • Contestation period
      • Next possible contestation deadline (= earliest finalization)

• The hydra-node does inform users when layer 1 protocol parameters are different than the configured --ledger-protocol-parameters

  • This is an informational message as a difference is often desired (e.g. lower fees).
  • Only log this, no API message.

• Hydra node operators can acknowledge changes by reconfiguring their hydra-node with new --ledger-protocol-parameters (coordinatedly).

• Out of scope: Interpreting parameter updates is not in scope! So no decision making based on the new parameters. This needs to be done by operators.

To be discussed

• What changes to the mainnet could affect currently open Hydra Heads? What parameter updates are problematic?

  • Any which make a previously "closable" Head "non-closable". That is, any
    change that will make off-chain UTxOs not accepted by the ledger. e.g.
    minUTxOValue or maxTxExecutionUnits (see
    https://hydra.family/head-protocol/core-concepts/faq/)
  • Any change which would make UTxO unspendable on the layer 1, i.e.
    transactions to spend some UTxO become too expensive

• How realistic are restrictive changes (e.g. higher prices, lower budgets, smaller tx size)?

  • Has never happened. Only increases so far.
  • Any such change would break a lot of applications on the layer 1.

[JaredCorduan]

i.e. will we always be able to submit old era txs?

From Shelley onward, the wire format for transactions has been backward compatible. We would have to have a very strong reason to abandon this commitment.

@JaredCorduan could you help us on this?

absolutely! let me know how/when I can help.

[ch1bo]

absolutely! let me know how/when I can help.

Answering this open question was what I meant, but appreciate it. Thanks!

[ch1bo]

Discussed this in one of our Weekly Hydra Engineering meetings: https://github.com/input-output-hk/hydra-poc/wiki/Logbook#2022-11-02-engineering-weekly

Should take these notes into consideration on our next grooming session.

[ch1bo]

Grooming session:

• We think that it's two things: Hard-fork stuff and protocol update stuff

• Protocol parameter updates (on L1)

  • Protocol parameter updates are introduced via special transactions on the L1. There is a update proposal some time before the actual update transaction. We can observe these.

  • Check the L1 parameters against the (given) L2 protocol parameters.

  • This is only about the L2 transactions. i.e. L1 parameter changes affecting transaction cost are only indirectly relevant because we will be putting the UTxO from L2 to L1.

  • When to inform users? Also before opening a head. -> Whenever the parameters are different.

  • Also inform users when only an update proposal is seen (via an API message).

  • Shall we compare (interpret) the new parameters? Or not compare it with L2 parameters at all?

  • In fact, hard-forks will be introduced the same way via special transactions announcing the end of the Era!

• Hard-forks (== protocol changes which might impact the L1 part of Hydra)

  • Common scenario: New ledger era with a new transaction format
  • We still should write-up what is to be done when the L1 changes in one way or the other via a hard-fork -> ADR?

• What is a secure change on parameters? i.e. when to close a head or not for the user?

  • This feels very complicated.
  • Closing a head is maybe more destructive than keeping it open.

[ltouro]

Idea (leaving HFs aside for a moment):

1. Hydra keep track of "proposed protocol parameters";
2. Hydra define a threshold time range that is between the upper bound of contest period and the lower-bound of new protocol parameters coming to effect. [i.e. there is enough time to close the head before the new protocol parameters lands on L1]

Rule) When inside the threshold time range, if the current [signed] snapshot is not valid in the proposed protocol parameters, close the head (as in non-collaborative peer).

Rule) When inside or after the threshold (but before lower-bound of new protocol parameters come to effect) snapshots and txs are validated against both current and proposed protocol parameters

Rational)

1. Not close heads if UTXO set is valid in the new protocol parameters
2. Give Head users at least some time to 'fix' the UTXO set to make it valid in the new protocol parameters (the delta between new parameters being proposed and the above threshold lower bound)
3. Don't depend on user action to make sure Completeness property holds
4. Also accounts for snapshots that were signed/confirmed before the protocol parameters proposal
5. Snapshots keep being confirmed, even if invalid in the new protocol parameters, until it reachs the threshold limit

[ch1bo]

I like your proposal @ltouro. However, validating snapshots against some protocol parameters is not as simple as it sounds. While we could keep the last n snapshots around to validate the transactions contained in them, it would only discover incompatibilities on "transaction-level", but not if some remaining UTxO will become unspendable with given protocol parameters. For example, if the UTxO are script outputs, we would not know the script which needs to validate before someone actually tries to spend these outputs.

[ltouro]

I agree that validating transitions for each transaction does not makes alot sense, since the Close/FanOut TX won't be doing that anyway.

What about validating [what would be] the Close Tx in the context of the L1 ledger for a given snapshot for proposed PPs? Is this too much overhead? I assume this is already done for current PP.

Something like:

Case 1: New snapshot created in Head

1. Node receives a new 'to be signed' snapshot
2. Node checkes if there is proposed PP underway.
3. If so, validates the [would be] Close TX for that snapshot in the context of a local ledger tweaked to use the new PP
4. If invalid under new rules, node enter in a "Warning State" (i.e. the snapshot is accepted and signed but there is a time threshold to get out this state before the head is forcibly closed by the protocol as in non-collaborative peer)

Case 2: New PPs received from L1:

1. Node receives a new proposed PPs
2. Node checkes if the last snapshot validates under a local ledger tweaked to use the the new PP
3. If invalid under new rules, node enter in a "Warning State" (i.e. the snapshot is accepted and signed but there is a threshold to get out this state before the head is forcibly closed by the protocol as in non-collaborative peer)

Is that the case that Close TX does not make all validations that would be performed in FanOut TX?

[ch1bo]

@ltouro The cases you describe would make total sense to approach this. I'm just saying that

3. If so, validates the [would be] Close TX for that snapshot in the context of a local ledger tweaked to use the new PP

and

2. Node checkes if the last snapshot validates under a local ledger tweaked to use the the new PP

Will only work to check incompatibility of UTxOs (the state we will put back on L1). For example, if the minUTxOValue parameter changes we can notice if it affects the snapshot's UTxOs. However, if the maxTxExecutionUnits change, we would not know if some script UTxO will become unspendable on the L1 (or L2 in case we adopt the updated parameters into the Head).

See also the last question in our FAQ

[ch1bo]

We discussed the hard-fork part of this in today's grooming (and likely will incorporate it into this item):

• Will scripts change? No, by themselves.
  • Internally we use a lot of the same dependencies in building our scripts.
  • Maybe keeping the hydra-plutus in the same repository might complicate this.
  • Using a separate toolchain (aiken?) would also remove conflation.
• Should be able to run a head across eras.
  • Which version of hydra-needed throughout?
  • Might need to update node to be able to close it in the new era.
  • A conway-compatible hydra-node
  • If not updated, an open head will not be closable/contestable.
• "Any head will survive a hard-fork", it's more about the hydra-nodes being able to interact with them.
• How is this related to backward compatibility of the cardano-node?
  • What are the assumptions / requirements the node puts on us / gives us?
  • Can we post Babbage transactions into a Conway era node?
• What about the layer 2 ledger? What era will it be?
  • Currently it's hard-coded to be one specific era (= the L1)
  • Should it be configurable or even track the L1 era automatically?
• Detect era change is something we should definitely do (or even warn when era is incompatible)
• Testing should be possible using debug flags in the cardano-node (ideally; or at least by doing protocol update requests)
• Major version always only represents one era in the Hydra ledger (L2). Hence, if hydra-node 1.x provides a babbage ledger and works on babbage + conway networks, hydra-node 2.x would drop the support for babbage networks and also deliver conway on the L2.
• Next step: Update or supersede React to protocol parameter changes #195 by concretizing it for the upcoming Conway hard-fork (split-off any parameter update handling parts)

[ch1bo]

Moved hard-fork portions of this item into #1177 and #1178 and updated body of this item. So this item is only about protocol parameter changes and marked it to be an idea (to be groomed) again.