# Week 8 This week, I began work on the issue: [Implement /eth/v1/beacon/pool/sync_committees](https://github.com/ReamLabs/ream/issues/215). To understand how a sync committee signature is validated and published on applicable subnets, I started by reading the [Consensus Specs Altair -- The Beacon Chain](https://ethereum.github.io/consensus-specs/specs/altair/beacon-chain/). The function `process_sync_aggregate` details how the `sync_committee_bits` & `sync_committee_signature` of a `SyncAggregate` are verified. I then continued with the [Consensus Specs Altair -- The Beacon Chain Honest Validator](https://ethereum.github.io/consensus-specs/specs/altair/validator/), which explains that sync committees are divided into 4 sub committees. For each slot, 16 aggregators from each sub committee are selected dynamically to aggregate signatures. This dynamic selection helps prevent denial-of-service (DoS) attacks by keeping the identities of aggregators secret until they broadcast their aggregations. The aggregated signatures are collected by the block producer, who aggregates them into a single signature for inclusion in a new block. Finally, I reviewed the [Consensus Specs Altair -- Networking](https://ethereum.github.io/consensus-specs/specs/altair/p2p-interface/), which describes how sync committee messages are disseminated. `SyncCommitteeMessage`s directly from sync committee validators are disseminated on topics `sync_committee_{subnet_id}`, while aggregated `SignedContributionAndProof` messages are disseminated on the topic `sync_committee_contribution_and_proof`. After digesting the above documents, I began implementing the endpoint of the issue. ## Resources [Consensus Specs Altair -- The Beacon Chain](https://ethereum.github.io/consensus-specs/specs/altair/beacon-chain/) [Consensus Specs Altair -- The Beacon Chain Honest Validator](https://ethereum.github.io/consensus-specs/specs/altair/validator/) [Consensus Specs Altair -- Networking](https://ethereum.github.io/consensus-specs/specs/altair/p2p-interface/)