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
This is will be the last PR related to deposits that also fixes the
"deposit used too early" problem identified in course of #1951 and
related discussions. With all the prior work already done in #1969,
#1974 and the refactorings of #1977 this was fairly straight forward.
:alarm_clock: Breaking change on the network as I needed to change the
`ReqSn` message.
:alarm_clock: Needed to substantially increase the `defaultTTL` of
re-enqueing inputs. This is needed because the `ReqSn` handling will
wait for the deposit to become active (passes the `--deposit-period`)
and needs to act on the `ReqSn` only then. This is problematic because
the input queue is not (yet?) persisted and restarting the node will
lose that state -> the deposit will become active, but an `AckSn` would
not be sent. See #1999
for a follow-up to address this.
:alarm_clock: The fact that we observe a `SlotNo` in
`DepositObservation` requires a `TimeHandle` to convert it further to a
`UTCTime` (in `convertObservation`). As the `hydra-chain-observer` does
not have a `TimeHandle`, I decided to switch to using `HeadObservation`
(the type from `hydra-tx`) instead of `OnChainTx` (the type from
`hydra-node`) for the chain observer / `hydra-explorer` interface. This
results in quite a lot of (backwards compatible) changes and this
companion PR: cardano-scaling/hydra-explorer#47
TODO:
- [x] spec changes
cardano-scaling/hydra-formal-specification#18
- [x] make chain observers not break the explorer API
---
* [x] CHANGELOG updated
* [x] Documentation updated
* [x] Haddocks updated or not needed
* [ ] No new TODOs introduced or explained herafter
- Two new TODOs in `Hydra.HeadLogic.onOpenNetworkReqSn` on things we're
not sure that are needed or even missing from the implementation (not
critical, but just inconsistent)
Copy file name to clipboardExpand all lines: docs/docs/dev/protocol.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -115,7 +115,7 @@ As indicated on the transaction trace example above, a successful incremental co
115
115
116
116
For `incrementTx`, the input is governed by the deposit validator which ensures funds can only be spent into the destined head before the **deposit deadline** (by anyone using a `recoverTx` after the deadline). Hence, any rollbacks _before_ this deadline can be mitigated by re-submitting the same (or a new) `incrementTx`. It is vital though, that the deadline is _far enough_ in the future to not be prone to yet more chain re-organization and run out of time mitigating eventually. As the deposit deadline is only relevant for the pessimistic case, we can pick fairly *high values* without affecting user experience. For example: **1 week**, equating to roughly 5x the worst case settlement time of Cardano.
117
117
118
-
For `depositTx`, the inputs may very well be spent by an attacker and an honest `hydra-node` should be cautious in observing a deposit as settled before signing a snapshot that authorizes addition of those funds to the L2 state. To mitigate this, a **deposit period** analogous to the contestation period of close/contest phase is introduced. A valid deposit must record in its datum when it was created and when the deadline shall be (see [specification](./specification.md)). An honest `hydra-node` will only consider deposits that are **older** than the deposit period and when the deadline is **further out** than the deposit period. While the deposit period will delay all increments by at least that time, a `hydra-node` can configure the risk it is willing to take using this period. For example: **1 hour** means that roughly after 180 blocks on `mainnet` we would only see a rollback including the `depositTx` with `0.01%` likelihood, assuming a `15%` adversarial stake fairly conservative grinding power. See [this excellent explanation and calculator](https://aiken-lang.org/fundamentals/what-i-wish-i-knew#transaction-latency-vs-finality) in the Aiken docs.
118
+
For `depositTx`, the inputs may very well be spent by an attacker and an honest `hydra-node` should be cautious in observing a deposit as settled before signing a snapshot that authorizes addition of those funds to the L2 state. To mitigate this, a **deposit period** analogous to the contestation period of close/contest phase is introduced. A valid deposit must have an upper validity to indicate when it was created (at latest) and record the deposit deadline in the output datum (see [specification](./specification.md)). An honest `hydra-node` will only consider deposits that are **older** than the deposit period and when the deadline is **further out** than the deposit period. While the deposit period will delay all increments by at least that time, a `hydra-node` can configure the risk it is willing to take using this period. For example: **1 hour** means that roughly after 180 blocks on `mainnet` we would only see a rollback including the `depositTx` with `0.01%` likelihood, assuming a `15%` adversarial stake fairly conservative grinding power. See [this excellent explanation and calculator](https://aiken-lang.org/fundamentals/what-i-wish-i-knew#transaction-latency-vs-finality) in the Aiken docs.
119
119
120
120
In summary, a deposit may only be picked up while `Active` in the following deposit life cycle:
Copy file name to clipboardExpand all lines: docs/docs/known-issues.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -57,6 +57,10 @@ Note that, as with any adjustments of this kind, it is good practice to make a b
57
57
58
58
There is a hard-coded limit on the **mainnet** where only up to 100 ada can be committed into the Hydra head. This is a safety precaution and will be increased as more experience is gained in running Hydra heads on the mainnet.
59
59
60
+
### Deposit periods
61
+
62
+
The `--deposit-period` allows an individual `hydra-node` operator to decide how long they want a deposit to have settled at least. However, differences bigger than [`defaultTTL * waitDelay`](https://hydra.family/head-protocol/haddock/hydra-node/Hydra-Node.html#v:waitDelay) (currently 10 minutes) result in non-approved snapshots. This is due to the way the `HeadLogic` is implemented and snapshot requests are not retried currently. See [hydra#1999](https://github.com/cardano-scaling/hydra/issues/1999) for more context.
63
+
60
64
### Known bugs
61
65
62
66
Refer to the project repository issue tracker for [known issues](https://github.com/cardano-scaling/hydra/issues?q=is%3Aissue+is%3Aopen+label%3A%22bug+%3Abug%3A%22). If you discover any security-relevant problems, please follow our [security policy](https://github.com/cardano-scaling/hydra?tab=security-ov-file#readme).
0 commit comments