-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Committee-aware attestation packing #14245
Conversation
061445c
to
9d607eb
Compare
9d607eb
to
2c5028f
Compare
d5ab01a
to
bbeed7f
Compare
if err != nil { | ||
return nil, err | ||
var sorted proposerAtts | ||
if features.Get().EnableCommitteeAwarePacking { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not move this logic withing the sort() method?
sa.selected = make(map[primitives.CommitteeIndex]proposerAtts) | ||
sa.leftover = make(map[primitives.CommitteeIndex]proposerAtts) | ||
for ci, committeeAtts := range sa.candidates { | ||
sa.selected[ci], sa.leftover[ci], err = committeeAtts.sortByProfitabilityUsingMaxCover_committeeAwarePacking() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a test where we check for leftovers? I think that with the parameters passed to MaxCover
the leftover map will always be empty unless there are contained aggregation bits, in which case anyway we would drop them. I suspect that with these parameters you can simply ignore the leftovers from MaxCover and just consider the selected ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
atts := getAtts([]testData{
{4, bitfield.Bitlist{0b00000001, 0b1}},
{4, bitfield.Bitlist{0b11100001, 0b1}},
{1, bitfield.Bitlist{0b11000000, 0b1}},
{2, bitfield.Bitlist{0b11100000, 0b1}},
{4, bitfield.Bitlist{0b10000011, 0b1}},
{4, bitfield.Bitlist{0b11111000, 0b1}},
{1, bitfield.Bitlist{0b11100000, 0b1}},
{3, bitfield.Bitlist{0b11000000, 0b1}},
})
want := getAtts([]testData{
{4, bitfield.Bitlist{0b11111000, 0b1}},
{4, bitfield.Bitlist{0b10000011, 0b1}},
{3, bitfield.Bitlist{0b11000000, 0b1}},
{2, bitfield.Bitlist{0b11100000, 0b1}},
{1, bitfield.Bitlist{0b11100000, 0b1}},
{4, bitfield.Bitlist{0b11100001, 0b1}},
{4, bitfield.Bitlist{0b00000001, 0b1}},
{1, bitfield.Bitlist{0b11000000, 0b1}},
})
This is an example of a test where we check that left over aggregates are sorted last. I agree that in all such tests each leftover atts has bits that are already covered.
bbeed7f
to
92a2e52
Compare
92a2e52
to
2768038
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Max-Cover is executed on all attestations for a slot bundled together, without considering committees. This is very bad because an attestation for committee
C0
with bits11111110
and an attestation for committeeC1
with the same bits will be treated as equal, meaning that Max-Cover will treat the attestation forC1
as not improving coverage, even though it's an entirely distinct set of votes. As a result it will most likely place this attestation after an attestation with bits00000001
(for whatever committee).If the number of attestations in the block is less then
MAX_ATTESTATIONS
, then this a non-issue because all attestations will get into the block anyway. But for blocks that hit the maximum number of attestations, which is 128, the packing can be made more optimal.The new algorithm:
The new algorithm is hidden behind a feature flag called
EnableCommitteeAwarePacking
(although it does more than dividing attestations into committees)