bls.AggregatePKs is undefined in Altair spec

[ralexstokes]

The Altair spec currently uses a function bls.AggregatePKs to aggregate a batch of BLS pubkeys in the function get_sync_committee.

This function is defined internal to the pyspec code but is not specified in the IETF signature standard which, according to the spec, is our source of bls functionality.

I'd say it is worth considering defining a helper like eth2_fast_aggregate_verify for this routine for the completeness of the spec.

edit: implementation incorporating feedback below:

def eth2_aggregate_pubkeys(pubkeys: Sequence[BLSPubkey]) -> BLSPubkey:
    """
    Return the aggregate public key for the public keys in ``pubkeys``.

    NOTE: the `+` operation should be interpreted as elliptic curve point addition, which takes as input
    elliptic curve points that must be decoded from the input `BLSPubkey`s. 
    This implementation is for demonstrative purposes only and ignores encoding/decoding concerns. 
    Refer to the BLS signature draft standard for more information.
    """
    assert len(pubkeys) > 0
    result = copy(pubkeys[0])
    for pubkey in pubkeys[1:]:
        result += pubkey
    return result

[protolambda]

If we do so, can we be more explicit about pubkey copies here?

result = pubkeys[0] and result += looks like in-place modification of the pubkey, but it shouldn't look like it changes the inputs (even though it doesn't). We could change it to start at 0, or copy() it.

[hwwhww]

It makes sense to me. Maybe add a note/comment that the pseudo-code ignores the encoding?

Backlog: we should add eth2_fast_aggregate_verify and eth2_aggregate_pubkeys tests to the BLS test vectors.

[ralexstokes]

could change it to start at 0
the pseudo-code ignores the encoding

yeah, i would want to avoid making 0x00 * 48 as the initial value to avoid discrepancies w/ encodings...

copy seems like a nice way forward and i think adding a note about ignoring encoding issues is a good idea