Leios: vote and certify over the announcing RbHash by geo2a · Pull Request #2086 · IntersectMBO/ouroboros-consensus

geo2a · 2026-06-19T11:42:36Z

Fixes input-output-hk/ouroboros-leios#941

Changes to LeiosDemoTypes

Add RbHash --- a newtype over ByteString representing a hash of a Ranking Block.
LeiosVote now carries an RbHash instead of LeiosPoint. This is the crux of the PR, all other changes stem from here.
LeiosOutstanding gets a new field offeredEbRbHashes :: Map EbHash RbHash. This field records the RbHash for each EB announcement. We cannot write the RbHash directly in the DB, because we don't yet have the EB body to attach to.

Changes to the DB interface

add the leiosDbRbOfEb :: EbHash -> m RbHash field to LeiosDbConnection. leiosDbRbOfEb maps an EbHash to the RbHash for the ranking block that announced this EB.
Both constructors of LeiosEbNotification now carry an RbHash.
leiosDbInsertEbBody and leiosDbInsertTxs now accept RbHash.

Changes to the forge

when forgeShelleyBlock forges an RB and produces an EB announcement (as decided by decideLeios), take note of the hash of the forged RB and store it into leiosDbRbOfEb for future reference.
when forgeShelleyBlock certifies an EB, fetch the hash of its announcing RB from leiosDbRbOfEb.
minor: mkAndStoreEb is split into two separate functions: mkEb and storeEb. This is necessary because storeEb needs to know the RbHash of the newly forged RB when announcing an EB, so it needs to be called after the RB is forged.

Changes to `LeiosNotify`

MsgLeiosBlockOffer now carries the RbHash of the announcing block. This is needed so that we can record the RbHash of the EBs we received from peers into the DB.

Changes to voting

In runLeiosVoting, we now forge votes on RbHash instead of LeiosPoint.
queryCert now accepts RbHash as the index instead of LeiosPoint.
The HasLeiosVoting instance for Dijkstra now needs the ShelleyCompatible constraint in order to convert the previous block's HeaderHash into a raw hash and interpret it as RbHash to stick into validateLeiosCertificate.
In the HasLeiosVoting instance for Dijkstra, we don't use the payload of the announcement in validateLeiosBlockCert anymore, as we only need the HeaderHash of the previous block for validateLeiosCertificate. We still pattern-match on the announcement to check if it's not Nothing and refuse to validate the cert if it is.

ch1bo

Not fully through it, but I'm not convinced that we need that many changes.

The certificate verification and vote signing is correct AFAIS, but it's a big of a too big rats tail on the storage and definitely the N2N mini protocols should not change? Please argue for why if I'm wrong.

ch1bo · 2026-06-22T12:11:15Z

+                  Nothing ->
+                    -- A CertRB always has a (non-genesis) announcing parent;
+                    -- the apply path shouldn't have produced one otherwise.
+                    error "applyBlock: cannot determine announcing RB hash for CertRB"


Should: replace the call to protocolStateLeiosAnnouncement above with this

The RbHash is the new announcement and all what we need to verify the cert. We might be able to drop protocolStateLeiosAnnouncement completely

ch1bo · 2026-06-22T12:13:42Z

  | TraceLeiosVoted {vote :: LeiosVote, weight :: Weight}
  | TraceLeiosVoteAcquired {vote :: LeiosVote}
-  | TraceLeiosCertified {point :: LeiosPoint}
+  | TraceLeiosCertified {rbHash :: RbHash}


Could: keep point and give this a more descriptive name like announcingRbHash

ch1bo · 2026-06-22T12:17:31Z

-                    pure $ MsgLeiosBlockOffer point ebSize
-                  AcquiredEbTxs point ->
+                  AcquiredEb point announcingRbHash ebSize ->
+                    pure $ MsgLeiosBlockOffer point (Leios.rbHashBytes announcingRbHash) ebSize


Must: not change the N2N protocol because of this

Why would we need the offer to include the announcement?

ch1bo · 2026-06-22T12:20:11Z

+instance SignableRepresentation RbHash where
+  getSignableRepresentation point =
+    toStrictByteString $
+      encodeRbHash point


Should: just use the hash bytes directly instead of CBOR

Not entirely sure what is the more common paradigm in the codebase? In any case, we should keep a note in the CIP / the vote CDDL about this.

ch1bo · 2026-06-22T12:21:18Z

 data LeiosVote = MkLeiosVote
-  { point :: LeiosPoint
+  { point :: RbHash
  -- ^ Point that gets signed. The slot also identifies the voting round.


Should: rename this field. It's not a point, but just a block header hash.

Also, there is no slot in this.

ch1bo · 2026-06-22T12:23:05Z

  mconcat
-    [ "slot" .= point.pointSlotNo
-    , "ebHash" .= prettyEbHash point.pointEbHash
+    [ "rbHash" .= prettyRbHash point


Note to myself: The frontend uses the slot and ebHash to visualize votes

We must update it

ch1bo · 2026-06-22T12:23:20Z

    , "voterId" .= voterId.voterIndex
    ]

 -- | Create a vote for given 'LeiosPoint' and signing key.


Should: fix Haddocks

ch1bo · 2026-06-22T12:25:08Z

-  = AcquiredEb LeiosPoint BytesSize
-  | AcquiredEbTxs LeiosPoint
+  = AcquiredEb LeiosPoint RbHash BytesSize
+  | AcquiredEbTxs LeiosPoint RbHash


Do we emit this now for each announcement (RbHash) that was completed when an EbTxs (closure) gets completed?

I'm asking because we would need to vote for each announcement (that is not equivocated).

ch1bo · 2026-06-22T12:29:40Z

  -- ^ Batch filter: returns the subset of input TxHashes that we do NOT have.
  , leiosDbQueryCompletedEbByPoint :: HasCallStack => LeiosPoint -> m (Maybe [(TxHash, ByteString)])
+  , leiosDbRbOfEb :: HasCallStack => EbHash -> m RbHash
+  -- ^ For an EB, find the RB that announced it.


Must: store announcements differently

This is not a 1:1 relationship. Instead, we would have a n:m relationship between announcements (RB headers) and EBs.

ch1bo · 2026-06-22T12:30:58Z

  -- NOTE: This is O(n) and should only be used at startup for initialization.
  , -- NOTE: yields a LeiosOfferBlock notification
-    leiosDbInsertEbBody :: HasCallStack => LeiosPoint -> LeiosEb -> m ()
+    leiosDbInsertEbBody :: HasCallStack => LeiosPoint -> RbHash -> LeiosEb -> m ()


Should: not need to change this

An EB body should actually only be indexed by EbHash and having the Slot via LeiosPoint here is already problematic.

Vote on the hash of the ranking block that announced the EB instead of the LeiosPoint, which comprises the slot number and EB hash. This forbids reusing Leios certificates across Praos forks.

Also remove it form leiosDbInsertEbBody and leiosDbInsertTxs

geo2a force-pushed the geo2a/vote-on-rbhash branch from 6aa7446 to 005523e Compare June 19, 2026 11:43

geo2a requested a review from ch1bo June 19, 2026 11:44

geo2a self-assigned this Jun 19, 2026

geo2a linked an issue Jun 19, 2026 that may be closed by this pull request

Leios Certificates and Votes must be signing RbHash input-output-hk/ouroboros-leios#941

Open

3 tasks

geo2a force-pushed the geo2a/vote-on-rbhash branch 2 times, most recently from 550cc26 to 7e136f2 Compare June 19, 2026 13:49

ch1bo force-pushed the ch1bo/leios-certifying branch 5 times, most recently from 1b8460a to eb18f0b Compare June 22, 2026 06:51

ch1bo force-pushed the geo2a/vote-on-rbhash branch from 7e136f2 to 3cf5afc Compare June 22, 2026 06:55

ch1bo requested changes Jun 22, 2026

View reviewed changes

ch1bo force-pushed the ch1bo/leios-certifying branch 3 times, most recently from c8f869c to 13e6a58 Compare June 22, 2026 16:05

Leios: vote and certify over the announcing RbHash

26068b3

Vote on the hash of the ranking block that announced the EB instead of the LeiosPoint, which comprises the slot number and EB hash. This forbids reusing Leios certificates across Praos forks.

geo2a force-pushed the geo2a/vote-on-rbhash branch from 3cf5afc to 4293065 Compare June 23, 2026 09:16

geo2a added 3 commits June 23, 2026 12:17

leios: in DB, key completed EBs by EbHash instead of by LeiosPoint

c43edb6

[wip] Remove RbHash from LeiosEbNotification

85c0696

Also remove it form leiosDbInsertEbBody and leiosDbInsertTxs

Leios: Don't carry announcing RbHash in MsgLeiosBlockOffer

1c2f282

geo2a force-pushed the geo2a/vote-on-rbhash branch from 4293065 to 1c2f282 Compare June 23, 2026 10:22

jasagredo added the Leios label Jun 24, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Leios: vote and certify over the announcing RbHash#2086

Leios: vote and certify over the announcing RbHash#2086
geo2a wants to merge 4 commits into
ch1bo/leios-certifyingfrom
geo2a/vote-on-rbhash

geo2a commented Jun 19, 2026 •

edited

Loading

Uh oh!

ch1bo left a comment

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

ch1bo Jun 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

geo2a commented Jun 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes to LeiosDemoTypes

Changes to the DB interface

Changes to the forge

Changes to LeiosNotify

Changes to voting

Uh oh!

ch1bo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

geo2a commented Jun 19, 2026 •

edited

Loading

Changes to `LeiosNotify`