Skip to content

Leios: Vote signing and committee selection#2039

Open
ch1bo wants to merge 21 commits into
leios-prototypefrom
ch1bo/leios-voting-committee
Open

Leios: Vote signing and committee selection#2039
ch1bo wants to merge 21 commits into
leios-prototypefrom
ch1bo/leios-voting-committee

Conversation

@ch1bo
Copy link
Copy Markdown

@ch1bo ch1bo commented May 12, 2026

Refs input-output-hk/ouroboros-leios#790.

Builds on the initial Leios voting prototype (#1963) by adding committee selection and real signature creation/validation, replacing the placeholder voting from #1963. Cross-repo bumps are pinned via source-repository-package for ledger and network.

Summary

  • Committee selection (per EB) from the stake distribution. A HasLeiosVoting decides whether (and as which VoterId) the local node votes on an EB, derived from the Shelley PoolDistr. For now, this only runs in the latest era and uses a basic selection scheme.
  • Real BLS signatures. Switched from placeholder/fake signing to actual BLS signatures, using a cardano-crypto-class ^>=2.4 that exposes a BLS DSIGN instance. Votes carry a signature over the EB point, and LeiosVoteState validates each vote individually before adding/relaying.
  • Voting key material. Committee membership tracks signing keys in tests; the previous unsafe Ed25519-as-BLS reinterpretation derived from pool id has been removed and replaced with a safer scheme.
  • Tests. LeiosVoteState unit tests cover the new validation API; ThreadNet expectations remain green.

Notes for reviewers

Test plan

  • cabal build all against pinned sibling SRPs
  • ThreadNet property tests pass (votes diffuse and are validated)
  • LeiosVoteState unit tests pass

ch1bo and others added 16 commits May 12, 2026 13:28
This class based approach mirrors other components of the consensus code
base where abstract code is made block-specific via type classes.
Enumerating shelley / praos instances for HasLeiosVoting makes it very
clear that a committee is only expected to be selected in Conway (later Dijkstra)
This will be just enough to derive a committe.. if I just re-use the
pool key hash as the vote signing key of all pools and derive
verification keys this way (to still skip proper key registration).
This derives vote signing key from the cold key hash - obviously still a
dirty hack, but just fine to avoid doing key registration.
Unsure about this because it's less explicit, but thought I give it a try.
Provide access to the committee using the HasLeiosVoting type class and
via the ChainDB access to the tip's ledger state.
The LeiosVoteState now drives us to add cryptographic signatures so we
cannot fake the voterId (index in the committee) without also having the
private key.
Real signing keys requires some more bytes. This is still unsafe of course.
Point at the ch1bo/leios-voting branches of cardano-ledger and
ouroboros-network instead of relative local paths.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ch1bo added 3 commits May 12, 2026 23:33
We might want to drop / not allow votes from previous epochs as the
committee can change and nodes would come silently to different
conclusions depending on their selected tips.
@ch1bo
Copy link
Copy Markdown
Author

ch1bo commented May 13, 2026

@kderme I'm hesitant in fixing most of the warnings/build errors of upstream packages because it would make the diff bigger for your rebase of leios-prototype, which would automatically include bumps to the latest cardano-crypto-class .. what do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Prototype Voting

1 participant