hydra
hydra copied to clipboard
input-output-hk
Not discard InitObservation when some keys don't match
Why
It's very hard to diagnose when a Head initialization was not picked up by one of the hydra-nodes. More specifically, the hydra client does not report anything at all and the hydra-node logs are also not very conclusive. For example, when some keys are not configured correctly there is not even an OnInitTx observation in the logs, just some blocks received.
What
Even when we have not configured our keys correctly, we want to have a log entry about a Head initialization, maybe even an API output. However, we do not want to have the hydra-node "adopt" this Head initialization, as it will not be fine anyways (because we are missing knowledge of hydra and/or cardano keys of the other parties).
~~Instead of discarding InitObservation when some keys don't match, we want to "discover" all Heads where we are part of. That makes it easier to see a Head has been initialized and if there is a misconfiguration, we can notice by checking Hydra vkeys and the misconfigured party not seeing a head open.~~ (was not informing enough, so we changed the definition of what we want to do here)
How
BLOCKED: This is actually not possible as we don't have any knowledge of cardano keys in the HeadLogic + the chain layer needs to take a decision about a state transition as well (into the L1 onchain state) ADR18 could be a solution to this as we will not be needing to store anything in the chain layer and we could yield the observation of an init transaction into the HeadLogic.
To be able to inform a client about an IgnoredHeadInit we would need to be notified about such a transaction in the head logic! That means, that the chain layer need not filter valid, but unrelated init transactions, but yield a InitObservation always when it is a valid init transaction. No matter whether we are part of this head or not!
- [ ] Do not
guardon who is part of a head inHydra.Chain.Direct.Tx. - [ ] Filter
OnInitTxevents inHeadLogicdepending on configured Hydra/Cardano keys. - [ ] Add a
ServerOutputfor when the filtering deemed to haveIgnoredHeadInit. - [ ] In the tui, explain that a head was ignored and checking logs/configuration is necessary.
TBD
There is no concept of layer 1 / cardano keys in the Head logic component so far!
By applying this change, now the misconfigured party can not init a head with others but observes others' initializations. The problem is that after this observation we can join and open and participate with the initialized head.
A better design would be to keep others' observations but don not be able to join and open a head if any party is misconfigured.
Possibly we display an error in this situations, like: Initialization Discarded/Ignored
Started investigating the second point of the blocking part again
the chain layer needs to take a decision about a state transition as well (into the L1 onchain state)
Although hoped initially ADR18 (now basically superseeded) did not do the trick as the problem is really the fact that the observeInit needs to produce an InitialChainState in order to be able to observe any commits. So we cannot just yield the OnInitTx to the application and not update the state accordingly .. or it would make the code very contrived.
So recently we set out to try to make observe.. functions not need a ChainState to observe and be handed a fully ResolvedTx. While this is possible, the returned ChainState is still required by the construction functions and hence we would need to make the whole transaction creation also less stateful. This is a big change .. and so we have not continued that just yet.
This issue is not only about stateless observation of the chain but also about improving feedback to the users and troubleshooting capabilities of the hydra-node and clients. Errors or notifications in general do not need to go through the HeadLogic as this would clutter this already significantly complex piece of logic, it might make sense to start "channeling" some of the logs to the clients.
