ChainSyncClient: No BlockNo when tip is genesis
#1585
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `Tip` data-type was
```haskell
data Tip b = Tip
{ tipPoint :: !(Point b)
, tipBlockNo :: !BlockNo
}
```
where `Point` uses `WithOrigin`. This is not correct. When `tipPoint` is
`Origin`, then there _is_ no `tipBlockNo` (`genesisBlockNo` is the block
number of the first block on the chain). In this commit we change this
to
```haskell
data Tip b =
-- | The tip is genesis
TipGenesis
-- | The tip is not genesis
| Tip !SlotNo !(HeaderHash b) !BlockNo
```
It doesn't, however, make any real changes, providing instead some
"legacy" API that pretends that we _do_ always have a `BlockNo`. This
primarily affects consensus only, in networking this only appears in
examples and tests.
We also use this legacy format to avoid changing the binary presentation
of `Tip`, so that this PR does _not_ break backwards compatibility.
dcoutts
approved these changes
Feb 5, 2020
|
bors r+ |
|
Will create the ticket. |
iohk-bors bot
added a commit
that referenced
this pull request
Feb 5, 2020
1585: ChainSyncClient: No `BlockNo` when tip is genesis r=edsko a=edsko
The `Tip` data-type was
```haskell
data Tip b = Tip
{ tipPoint :: !(Point b)
, tipBlockNo :: !BlockNo
}
```
where `Point` uses `WithOrigin`. This is not correct. When `tipPoint` is `Origin`, then there _is_ no `tipBlockNo` (`genesisBlockNo` is the block number of the first block on the chain). In this commit we change this to
```haskell
data Tip b =
-- | The tip is genesis
TipGenesis
-- | The tip is not genesis
| Tip !SlotNo !(HeaderHash b) !BlockNo
```
It doesn't, however, make any real changes, providing instead some "legacy" API that pretends that we _do_ always have a `BlockNo`. This primarily affects consensus only, in networking this only appears in examples and tests.
We also use this legacy format to avoid changing the binary presentation of `Tip`, so that this PR does _not_ break backwards compatibility.
Co-authored-by: Edsko de Vries <[email protected]>
|
#1587 is the ticket. |
|
LGTM. Used to be we had to have a block number for some reason, and we chose 0 for the genesis, and each EBB would have the same block number as the 0th block number of its epoch. If this isn't needed anymore then good riddance! |
This might still be needed, but if so, it should be Byron specific, and not live in the general infrastructure. The addition to of |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
Tipdata-type waswhere
PointusesWithOrigin. This is not correct. WhentipPointisOrigin, then there is notipBlockNo(genesisBlockNois the block number of the first block on the chain). In this commit we change this toIt doesn't, however, make any real changes, providing instead some "legacy" API that pretends that we do always have a
BlockNo. This primarily affects consensus only, in networking this only appears in examples and tests.We also use this legacy format to avoid changing the binary presentation of
Tip, so that this PR does not break backwards compatibility.