-
Notifications
You must be signed in to change notification settings - Fork 33
Open
Description
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