Leios: Vote signing and committee selection#2039
Open
ch1bo wants to merge 21 commits into
Open
Conversation
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>
3 tasks
3 tasks
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.
Author
|
@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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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-packagefor ledger and network.Summary
HasLeiosVotingdecides whether (and as whichVoterId) the local node votes on an EB, derived from the ShelleyPoolDistr. For now, this only runs in the latest era and uses a basic selection scheme.cardano-crypto-class ^>=2.4that exposes a BLS DSIGN instance. Votes carry a signature over the EB point, andLeiosVoteStatevalidates each vote individually before adding/relaying.LeiosVoteStateunit tests cover the new validation API; ThreadNet expectations remain green.Notes for reviewers
ch1bo/leios-voting— Prototype: Bump cardano-crypto-class for Leios voting cardano-ledger#5829 (addscardano-crypto-class ^>=2.4)ch1bo/leios-voting— Bump cardano-base for Leios voting ouroboros-network#5366 (cardano-base bump)ch1bo/leios-voting— Bump cardano-crypto-class for Leios voting cardano-api#1203 (same crypto-class bump)Test plan
cabal build allagainst pinned sibling SRPsLeiosVoteStateunit tests pass