IntersectMBO / IntersectMBO/ouroboros-consensus

[BUG] - envelopeChecks ignoring header's protocol major version?

Open
#2,127 3 comments 0 reactions 0 assignees View on GitHub
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**

Image

**Additional context**
Add any other context about the problem here.

Contributor guide

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.