Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(node): migrate vote tally #1139

Open
wants to merge 23 commits into
base: feat/topdown-enchancement
Choose a base branch
from

Conversation

cryptoAtwill
Copy link
Contributor

@cryptoAtwill cryptoAtwill commented Sep 20, 2024

Following previous PR, this one migrates the vote tally process over.

In this PR, the following key changes are made:

  • Migrating current main VoteTally over. Most of the logic is unchanged. The key changes are removing the stm module, removing chain field (not relevant to vote tally anymore) and remove pause_votes (not needed). Also dump_votes that dump all the votes currently collected is added. This is mainly to aid debugging in case of stuck finality.
  • Implemented the VoteTallyClient that utilises tokio channels to communicate with the underlying reactor.
  • Introduced VoteStore trait that stored votes collected. Currently it's in memory store by default. Will merge with Add persistent top-down finality cache #897 when recovery modes are introduced.
  • Introduced GossipClient trait that vote tally uses to communicate with the underlying libp2p gossip channel. Previously it's using ipld-resolver directly. But that crate is under utilised and quite heavy. Introducing this trait to decouple with ipld-resolver for easier testing as well.
  • Added RecoverableECDSASignature to validate signed votes from peers and sign votes for peers.
  • Vote is now versioned. The first byte is the version number, the rest of the bytes are the payload depending on the version.

@cryptoAtwill cryptoAtwill requested a review from a team as a code owner September 20, 2024 12:15
@cryptoAtwill cryptoAtwill marked this pull request as draft September 20, 2024 12:15
@cryptoAtwill cryptoAtwill changed the title feat(node): vote tally initial commit feat(node): migrate vote tally Sep 20, 2024
@raulk raulk added the topdown label Oct 14, 2024
@cryptoAtwill cryptoAtwill marked this pull request as ready for review January 10, 2025 13:24
fendermint/crypto/src/secp.rs Show resolved Hide resolved
/// A self-certified observation made by a validator.
#[derive(Serialize, Deserialize, Debug, Clone, Eq, PartialEq)]
pub struct CertifiedObservation {
observation: Observation,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate more on why both the inner and the envelop signatures are needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's required in Observation because we need it to publish a cert. But for certified_at field, we also need it to be nonforgeable but no need to be part of the certificate. In the future, there might be more fields to be added to counter different attacks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the latter is just part of the messaging protocol for authentication, perhaps it's better to abstract it away from that struct which defines the message content.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried something like:

struct RecoverablePayload<T> {
  t: T,
  sig: RecoverableSig
}

But it becomes more nested than the above. If there is a use case for reuse, I think it's worth changing, but so far I feel not that much though

fendermint/vm/topdown/src/vote/mod.rs Show resolved Hide resolved
fendermint/vm/topdown/src/observation.rs Outdated Show resolved Hide resolved
},
Ok(vote) = self.handler.gossip_rx.recv() => {
Ok(vote) = self.handler.gossip_rx.recv_vote() => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does the Vote::v1_checked validation is taken place?

Copy link
Contributor Author

@cryptoAtwill cryptoAtwill Jan 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When it's deserialized, it's checked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Backlog
Development

Successfully merging this pull request may close these issues.

3 participants