Cardano Updates

Coder's SparseKeyed alternative

Introduce 'Maybe LeiosCert' (mirrored after the existing 'Maybe
PerasCert') as an optional field on the Dijkstra-era 'BlockBody'. Other
eras are unaffected — this is the entire Leios-related ledger changes
from leios-prototype at the time of the remake.

it across eras

across eras

since this is now part of the `StAnnTx` signal

When a 'DijkstraBlockBody' carries a 'LeiosCert' (i.e. it is a cert
block), 'hashDijkstraSegWits' now hashes only the optional Leios /
Peras certificates and ignores the four transaction segwit chunks.
This mirrors the leios-prototype's @hashBody (BodyCertificate cert _) =
hashCert cert@: the header commits to the cert, the EB closure is
resolved into 'dbbTxs' locally (by chain-sel's 'resolveLeiosBlock'
before handing the block to BBODY), and the locally-inlined txs must
not invalidate the header-committed body hash.

For regular blocks (no LeiosCert) the hash still covers the segwit
chunks plus the optional Peras certificate, unchanged.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

The BBODY rule validates the Peras certificate when present, and that
validation requires the Praos header to carry a 'PrevEpochNonce'. The
consensus header builder currently defaults that to 'Nothing', so a
Dijkstra block that happens to carry a Peras certificate (placeholder
or otherwise) fails BBODY with 'PrevEpochNonceNotPresent' and gets
rejected from the chain.

The pre-fix wire format dispatched on the body's inner list length
positionally with Peras-first: @5@ ⇒ Peras only, @6@ ⇒ Peras + Leios.
That made "Leios only" unrepresentable, forcing the consensus layer to
attach a placeholder Peras cert alongside every Leios cert and
tripping the validation failure above.

Swap the order on the wire so Leios comes first:

  4 ⇒ no cert
  5 ⇒ Leios only
  6 ⇒ Leios + Peras

"Peras only without Leios" is no longer representable; if support for
that combination is needed later the wire format should move to
explicit @StrictMaybe@ markers per cert. The hash function already
takes Leios before Peras, so the body hash is unchanged.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

The body encoder previously emitted four mandatory segwit chunks plus
optional Peras/Leios certificate bytes inline, with a constant
'listLen = 5' and 'numSegComponents = 5'. The 'DecCBOR' instance reads
an inner list length and dispatches on it (4 / 5 / 6), but the encoder
never wrote that list length and the constant 'listLen = 5' didn't
match the actual cert-presence cases. As a result, basic blocks (both
certs SNothing) failed to deserialise on the network — the outer
'Block' decoder expected 'numSegComponents + 1 = 6' elements but the
encoder produced only 5.

Wrap the body in its own CBOR list at encoding time, with the inner
length (4, 5, or 6) discriminating between (no cert) / (Peras only) /
(Peras + Leios). The matching 'DecCBOR' already reads this exact
length, so the existing decode path works unchanged. The outer 'Block'
record is now 2 elements (header + body-list), so
'numSegComponents = 1'.

A Leios certificate without a Peras certificate is not representable on
the wire (the decoder reads certificates positionally); the encoder
'error's in that case.

Co-Authored-By: Claude Opus 4.7 <[email protected]>

Re-authored on top of c175b1b317 (the cardano-ledger commit compatible
with consensus main's CHaP index-state 2026-04-13) to match the older
fat-constructor DijkstraBlockBody shape (pre-memoization refactor).
Equivalent to b6b2feb006 on leios-prototype-remake, which targeted the
post-memoization shape (DijkstraBlockBodyRaw + lensMemoRawType).

Adds:
* `dbbLeiosCert :: StrictMaybe LeiosCert` field and matching
  `dbbLeiosCertBytes :: Maybe BSL.ByteString` byte-cache, mirroring the
  PerasCert pattern in this older shape.
* `LeiosCert` placeholder newtype over ByteString with derived
  EncCBOR/DecCBOR/NoThunks/NFData (the real type lands with the Leios
  voting machinery).
* `leiosCertBlockBodyL` lens method on `DijkstraEraBlockBody`.
* Pattern synonym extended with a third `StrictMaybe LeiosCert` arg;
  body threads the bytes through `hashDijkstraSegWits` (now takes the
  Leios bytes arg too).
* `EncCBORGroup` appends the optional Leios cert bytes after the
  optional Peras cert bytes.
* `DecCBOR` handles three list-length cases: 4 (neither), 5 (Peras
  only, legacy), 6 (Peras + Leios). A Leios-only encoding is not
  expressible without ambiguity at len 5 \-- intentional: Dijkstra-era
  blocks aren't on the wire yet.
* `NoThunks` `AllowThunksIn` list extended with `dbbLeiosCertBytes`.
* Testlib: `Arbitrary LeiosCert` (and `DijkstraBlockBody <*> arbitrary
  <*> arbitrary <*> arbitrary`); `ToExpr LeiosCert` and updated
  `ToExpr (DijkstraBlockBody era)` constraint set.

Only the Dijkstra era is Leios-enabled \-- earlier eras are untouched.

Verified: `cabal build cardano-ledger-dijkstra:lib:cardano-ledger-dijkstra`
and `cabal build cardano-ledger-dijkstra:lib:testlib` both clean.

Co-Authored-By: Claude Opus 4.7 <[email protected]>