Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADR 18: Keeping a single state #305

Merged
merged 6 commits into from
Apr 13, 2022
Merged

ADR 18: Keeping a single state #305

merged 6 commits into from
Apr 13, 2022

Conversation

ch1bo
Copy link
Collaborator

@ch1bo ch1bo commented Apr 12, 2022

Drafted how we could keep a single TVar only by updating the interface between Hydra.Node and Hydra.Chain.

I tried to exercise (quick'n'dirty and not intending to be merged) this and the to-be-discussed alternative (see ADR) on these branches:

  • Example - compiles for hydra-node with only some undefined
  • Alternative - less far explored / unfinished!

Fixes #257

@ch1bo ch1bo requested a review from a team April 12, 2022 19:33
@github-actions
Copy link

github-actions bot commented Apr 12, 2022

Unit Test Results

    5 files  ±0    72 suites  ±0   7m 35s ⏱️ +11s
197 tests ±0  195 ✔️ ±0  2 💤 ±0  0 ±0 

Results for commit 8c13be3. ± Comparison against base commit eb65cae.

♻️ This comment has been updated with latest results.

@ch1bo ch1bo force-pushed the ch1bo/adr-18-single-state branch from 0d795c2 to 8888017 Compare April 12, 2022 22:55
* The interface between the `Hydra.Node` and a `Hydra.Chain` component consists of
- constructing certain Head protocol transactions given a description of it (`PostChainTx tx`):
```hs
postTx :: MonadThrow m => PostChainTx tx -> m ()
Copy link
Collaborator

@KtorZ KtorZ Apr 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this first point is really about the interface between the Hydra.Node and the Hydra.Chain. This is really the client interface and how clients can interact with the on-chain state.

Nevermind. We do indeed use this handle as a mean between the two components, postChainTx calls are a result of effects emitted by the head logic in response to client inputs.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somehow I keep getting "confused" by this 🤔 ... Maybe just a naming question.

* We provide the latest `ChainState tx` to `postTx` by extending `PostChainTx tx`
* We change the callback interface of `Chain` to
```hs
type ChainCallback tx m = (ChainState tx -> Maybe (OnChainTx tx)) -> m ()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This suggests that the ChainState tx may evolve separately from the an event occurrence. Is that the case 🤔 ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, I missed the parentheses. The ChainState here would be provided by the logic layer. I wonder though if this can be achieved in a pure fashion 🤔 ... Intuitively, I feel like we'd need something like m (ChainState tx)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this is the core bit of the whole proposal, i did twiddle things around a bit and tested them on the https://github.com/input-output-hk/hydra-poc/compare/ch1bo/adr-18-single-state-example branch. Happy to walk you through the current proposed state and we can pair on making it simpler still maybe? :)

```hs
postTx :: MonadThrow m => ChainState tx -> PostChainTx tx -> m ()
type ChainCallback tx m = (ChainState tx -> Maybe (OnChainTx tx, ChainState tx)) -> m ()
```
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do highly prefer the alternative here ☝️ , as it:

  1. Keep the base types "simpler"
  2. Make more obvious from the type signature what is going on (typical state update s -> (a, s))
  3. Maintain a clearer separation between the stateful part, and the somewhat stateless / deterministic bits which are the chain tx.

Copy link
Collaborator

@KtorZ KtorZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay to merge provided that we make the current alternative the actual decision.

ch1bo and others added 5 commits April 13, 2022 13:38
We decided to favor the non-extended "core types" in the Node/Chain
interface as it's more explicit about ChainState updates.
@ch1bo ch1bo force-pushed the ch1bo/adr-18-single-state branch from 0bf208e to d50353e Compare April 13, 2022 11:49
@ch1bo ch1bo merged commit c7864cd into master Apr 13, 2022
@ch1bo ch1bo deleted the ch1bo/adr-18-single-state branch April 13, 2022 13:42
@ch1bo ch1bo mentioned this pull request Mar 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create an ADR to get rid of the TVar in the Direct module
2 participants