Skip to content

Track received candidate manifests per validator index #4574

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

Closed
1 task
EclesioMeloJunior opened this issue Feb 26, 2025 · 0 comments
Closed
1 task

Track received candidate manifests per validator index #4574

EclesioMeloJunior opened this issue Feb 26, 2025 · 0 comments
Assignees
Labels
T-implementation this issue/pr is a new feature or functionality.

Comments

@EclesioMeloJunior
Copy link
Member

Issue summary

We should track incoming manifests (Full or Acknowledgement) per ValidatorIndex and per CandidateHash

The manifest has a single type independent of its kind (Full or Acknowledgement):

// ManifestSummary represents a summary of a manifest being sent by a counterparty.
type ManifestSummary struct {
	// ClaimedParentHash is the claimed parent head data hash of the candidate.
	ClaimedParentHash Hash
	// ClaimedGroupIndex is the claimed group index assigned to the candidate.
	ClaimedGroupIndex GroupIndex
	// StatementKnowledge is a statement filter sent alongside the candidate, communicating knowledge.
	StatementKnowledge StatementFilter
}

This manifest are received from a remote peer and we should track it in a map using CandidateHash as its key

type ReceivedManifests struct {
    Received map[CandidateHash]ManifestSummary
    // seconded counts is a limit of how many seconded statement
    // a given candidate can have, defined per session
    SecondedCounts map[GroupIndex][]uint
}

Functionalities

  • Import manifest summary:

    • To import the manifest summary in the map we should follow the conditions:

      • For new candidate hash we should check if the seconded in group respect the limit defined by the session, see statement-distribution/src/v2/mod.rs#L2414. This means that, the imported manifest should have the amount of seconded statements below the defined limit.
      • If the candidate already exists we can update it only if
        • the informations in the incoming manifest summary does not conflict with the current informations
        • the imported manifest should have the amount of seconded statements below the defined limit.
  • Retrieve StatementKnowledge for a given candidate hash

Other information and links

Acceptance criteria

  • New code is 60% covered with unit tests
@EclesioMeloJunior EclesioMeloJunior added the T-implementation this issue/pr is a new feature or functionality. label Feb 26, 2025
@haikoschol haikoschol self-assigned this May 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-implementation this issue/pr is a new feature or functionality.
Projects
None yet
Development

No branches or pull requests

2 participants