Skip to content

Ideas on how to store votes for rewards #522

@akhi3030

Description

@akhi3030

Some ideas I had about packing aggregates into the block footer:

  • These s - 8 votes are not required for consensus, and we don't need to update or track any thresholds on these old slots
  • Ideally we could avoid requiring the consensus pool be shared between multiple threads
  • Instead what if we had a separate rewards container:
    • If sigverifier receives a vote > root send it to the ConsensusPool, if it's a notar or skip also send it to the rewards container
    • If sigverifier receives a notar/skip vote where we are leader for vote_slot + 8 > root send it to rewards container
  • This container doesn't have to do anything fancy, just store one vote per validator per slot
  • When the block creation loop is about to finish producing the block, it can call the BLS aggregation fn for s - 8 and record the result in the block footer
  • At this point we can clean up s - 8 from the rewards container

Separates the rewards tracking from the main consensus tracking so we don't have to mess with the ConsensusPool. Maybe wrap the VoteMessage in an Arc to avoid the overhead of sending it twice. Let me know what you think.

Originally posted by @AshwinSekar in #514 (comment)

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions