The HydraHeadV1 formal specification contains a bounded confirmation window:
T_max <= T_min + L // Bounded confirmation window
DL’ = T_max + L // The latest possible deadline is 2*L
T_maxbeing the tx validity bounds and
Lbeing the contestation period.
- This is to avoid attacks with specified upper validity bound being too far in the future and denial of service the head with this (e.g. 10 years).
Current state of things:
The contestation period and upper tx validity is used for computing the contestation deadline.
There is a
closeGraceTimecurrently hard-coded (to
100slots) to set some upper bound on the
closeTx. This was also required so far to compute the contestation deadline.
Different networks (chains) have different slot lenghts, e.g. the preview network has a slot every
1s, while our local devnets use
0.1s. This means hardcoded values like
closeGraceTimeneed to be in sync with the underlying network.
contestationPeriodcan be configured by users via the
Initclient input. For example, the hydra-cluster test suite uses a hardcoded
cperiodon the client side.
Default value for
T_Minis negative infinity.
Lower tx validity being in the future does not pose a problem since other participant is able to close a head.
What we want to achieve:
We want to enforce topmost formula in this file in our code on-chain.
maxGraceTimeexpressed in seconds in place of
closeGraceTimeand adjust to appropriate value.
The contestation period is to be used to create bounded close transaction (together with
maxGraceTime). Before it was only used for computing the contestation deadline.
If contestation period is higher than
maxGraceTimewe will pick the latter. We still need
contestationPeriodis low for the current network our txs reach the upper bound fast and become invalid. That is why we set the upper tx bound to be minimum between
maxGraceTimeso that txs have high enough upper bound.
Make sure all head participants use the same value for
Attack vector has a corresponding mutation test.
Use the specification formula on-chain.
Configure the contestation period (number of seconds) on the
hydra-node, e.g. via a
--contestation-periodcommand line option.
Lower tx bound should be the last known slot as reported by the
Upper tx bound is the current time + minimum between
When submitting the
InitTxmake sure to use
--contestation-periodvalue from our node's flag.
If other nodes observe
contestationPeriodvalue does not match with their
--contestation-periodsetting - ignore
maxGraceTimesince we are using it also for upper bound of a contest tx.
Not any positive number of seconds is a valid contestation period any more!
Upper tx validity of close transaction is the minimum between
contestationPeriodand this needs to be good enough value with respect to running network. This is a consequence required by the ledger when constructing transactions since we cannot convert arbitrary point in times to slots.
All parties need to aggree on contestation period before trying to run a Head protocol otherwise InitTx will be ignored.