Add note about aggregate key in SyncCommittee

specs/altair/beacon-chain.md

@@ -211,6 +211,8 @@ class SyncAggregate(Container):
 
 #### `SyncCommittee`
 
+*Note:* The `aggregate_pubkey` field is computed but is not currently used in the specifications. Typically, sync committee signatures are verified by summing up the public keys of the subset of committee members that signed to obtain their aggregate public key. Notably, this key is different from `aggregate_pubkey`, as it only represents a subset of the committee. The `aggregate_pubkey` field can be used in the following optimization: If more than half of the sync committee members have signed, their aggregate public key can be derived more efficiently by subtracting the keys of the missing members from `aggregate_pubkey`.
+
 ```python
 class SyncCommittee(Container):
     pubkeys: Vector[BLSPubkey, SYNC_COMMITTEE_SIZE]

specs/altair/light-client/sync-protocol.md

@@ -444,6 +444,11 @@ def validate_light_client_update(store: LightClientStore,
     assert bls.FastAggregateVerify(participant_pubkeys, signing_root, sync_aggregate.sync_committee_signature)
 ```
 
+*Note:* `bls.FastAggregateVerify` internally computes an aggregate public key by summing individual keys from `participant_pubkeys`. There are two potential optimizations:
+
+1. If `len(participant_pubkeys) > sync_committee.pubkeys - len(participant_pubkeys)`, computing the aggregate public key can be more efficient by subtracting the non-participating keys from `sync_committee.aggregate_pubkey` instead of summing the participants.
+2. Assuming the same sync committee members participate across sequential slots, one can optimize further by caching the aggregate public key from the previous slot(s) and incrementally updating it (by adding and subtracting individual keys) for the next slot, where we consider two slots with the same sync committee.
+
 ### `apply_light_client_update`
 
 ```python