-
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
Add Aggregated Public Key Method #14178
Conversation
pubKeys := make([][]byte, len(idxs)) | ||
for i, idx := range idxs { | ||
var v *ethpb.Validator | ||
if features.Get().EnableExperimentalState { |
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.
This case is not tested at all, is it expected?
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.
I think its fine in this particular case as its simply for the experimental state, we don't do the same for a few other methods too. Also the experimental state has been tested in e2e, so these paths are tested, just not in the current unit tests. Once we flip the flag, it will get tested as it becomes the default path
pubkeys[i] = pubkeyAtIdx[:] | ||
} | ||
aggP, err := bls.AggregatePublicKeys(pubkeys) | ||
aggP, err := beaconState.AggregatedKeyFromIndices(indices) |
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.
Nit: The previous function is AggregatePublicKeys
. Should'nt this function name AggregateKeyFromIndices
?
What type of PR is this?
Optimization
What does this PR do? Why is it needed?
Currently for each attestation aggregate we allocate memory for each individual public key when trying to derive the aggregated key. To optimize this process we simply collect all the keys in the state's receiver and aggregate it there itself. The main benefit of this is to completely avoid memory-allocation in a known hot-path in gossip.
Which issues(s) does this PR fix?
N.A
Other notes for review