IntersectMBO / IntersectMBO/ouroboros-consensus
[BUG] - envelopeChecks ignoring header's protocol major version?
- Dominant language
- Haskell
- Stars
- 67
- Forks
- 43
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 43
Description
**Internal/External**: **External**
**Summary**
The consensus layer is responsible for validating block headers (at least, some elements of it). This happens through the `envelopeChecks`:
https://github.com/IntersectMBO/ouroboros-consensus/blob/2ca6c748588a0e4703c7199d280ef67e06f36123/ouroboros-consensus-cardano/src/shelley/Ouroboros/Consensus/Shelley/Protocol/Praos.hs#L111-L125
One of the check refers to the protocol major version:
```
unless (m <= maxpv) $ throwError (ObsoleteNode m maxpv)
```
However:
- `maxpv` is a configuration parameter provided at runtime
- `m` comes from the _ledger view_ and reflects the current protocol version major
Notice that the protocol version from the header is totally ignored.
**Steps to reproduce**
See [this block](https://preview.cardanoscan.io/block/4259486) on Preview which declares a protocol major version `12` when the network just transitioned into `11`.
**Expected behavior**
I am unclear whether this is desired or a genuine oversight? It seems to me that this check only ensures that the consensus and ledger libraries agree on what is the maximum protocol version; but then, why perform this check on *every* header?
If this is the intended behavior, then so be it. If not, let me know 😶
**System info (please complete the following information):**
- OS Name: irrelevant
- OS Version: irrelevant
- Consensus version: `==3.0.1.0`
**Screenshots and attachments**
**Additional context**
Add any other context about the problem here.
Contributor guide
Research direction
Start in ouroboros-consensus-cardano/src/shelley/Ouroboros/Consensus/Shelley/Protocol/Praos.hs at the envelopeChecks code around lines 111-125, then compare the ledger-view protocol version with the header version from the referenced Preview block. Done means determining whether the header version should be validated and resolving the behavior accordingly, with coverage for the relevant case if the project’s existing tests identify a suitable location.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- haskell
- Domain
- blockchain
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 38/100