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*Lwith
being the tx validity bounds andL
being 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
currently hard-coded (to100
slots) to set some upper bound on thecloseTx
. 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
, while our local devnets use0.1s
. This means hardcoded values likecloseGraceTime
need to be in sync with the underlying network.The
can be configured by users via theInit
client input. For example, the hydra-cluster test suite uses a hardcodedcperiod
on the client side.Default value for
is 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.
expressed in seconds in place ofcloseGraceTime
and adjust to appropriate value.The contestation period is to be used to create bounded close transaction (together with
). Before it was only used for computing the contestation deadline.If contestation period is higher than
we will pick the latter. We still needmaxGraceTime
is 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 betweencontestationPeriod
so 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
, e.g. via a--contestation-period
command 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
make sure to use--contestation-period
value from our node's flag.If other nodes observe
value does not match with their--contestation-period
setting - ignoreInitTx
since we are using it also for upper bound of a contest tx.Consequences
Not any positive number of seconds is a valid contestation period any more!
Upper tx validity of close transaction is the minimum between
and 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.