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

Evolve ForgeState eagerly and trace it #2160

Merged
merged 12 commits into from
May 28, 2020
Merged

Evolve ForgeState eagerly and trace it #2160

merged 12 commits into from
May 28, 2020

Conversation

edsko
Copy link
Contributor

@edsko edsko commented May 27, 2020

This actually required some refactoring, getting rid of the boolean blindness introduced in #1927. Now if a node is not a leader, its config does not even need to contain any info anymore that is required for block production, and conversely, if we are a leader, then we don't need to deal with the case that we might lack this information in checkIsLeader.

@edsko edsko marked this pull request as ready for review May 28, 2020 06:56
@mrBliss mrBliss self-requested a review May 28, 2020 07:13
edsko added 5 commits May 28, 2020 09:15
This is stateful, which requires an additional @m@ parameter in various places,
which is why this commit is a bit larger. Not much happening though.
We used to have

```
checkIfCanBeLeader :: ConsensusConfig p -> Bool
```

But this leads to boolean blindness, and moreover meant that we needed to
somehow be able to represent within the config that we may or may not be a
leader. This was getting in the way of the refactoring we require for this PR,
so I've now introduced

```
-- | Evidence that we /can/ be a leader
type family CanBeLeader p :: *
```

This removes a bunch of error cases, and means that in `protocolInfo`, we can
now express that we only need to provide a `MaintainForgeState` instance if and
only if we are a leader: we bundle it in a single `Maybe` together with the
`CanBeLeader` proof.
It's now backed by a `StrictMVar` rather than a `TVar`, which means we can use
`modifyMVar`. This makes it possible to avoid the awkward "evolving key" dance
that was needed for `TPraos`. Had to change `ChaChaT` to be `ReaderT` (of a
`TVar` containing the DRG) based rather than `StateT`, because the latter does
not support `MonadCatch`/`MonadMask`, required for `modifyMVar`.
Copy link
Contributor

@mrBliss mrBliss left a comment

Choose a reason for hiding this comment

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

Nice, much better than before!

@edsko
Copy link
Contributor Author

edsko commented May 28, 2020

bors merge

iohk-bors bot added a commit that referenced this pull request May 28, 2020
2160: Evolve ForgeState eagerly and trace it r=edsko a=edsko

This actually required some refactoring, getting rid of the boolean blindness introduced in #1927. Now if a node is not a leader, its config does not even need to contain _any_ info anymore that is required for block production, and conversely, if we _are_ a leader, then we don't need to deal with the case that we might lack this information in `checkIsLeader`.

Co-authored-by: Edsko de Vries <edsko@well-typed.com>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented May 28, 2020

Canceled

@edsko
Copy link
Contributor Author

edsko commented May 28, 2020

bors merge

@iohk-bors
Copy link
Contributor

iohk-bors bot commented May 28, 2020

@iohk-bors iohk-bors bot merged commit b33db58 into master May 28, 2020
@iohk-bors iohk-bors bot deleted the edsko/issue-2154 branch May 28, 2020 09:37
coot pushed a commit that referenced this pull request May 16, 2022
2160: Evolve ForgeState eagerly and trace it r=edsko a=edsko

This actually required some refactoring, getting rid of the boolean blindness introduced in #1927. Now if a node is not a leader, its config does not even need to contain _any_ info anymore that is required for block production, and conversely, if we _are_ a leader, then we don't need to deal with the case that we might lack this information in `checkIsLeader`.

Co-authored-by: Edsko de Vries <edsko@well-typed.com>
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.

None yet

2 participants