In the Ethereum light client sync protocol, the sync committee was introduced in the Altair hardfork to support light client consensus verification. The sync committee is a randomly selected subset of validators (512 validators form part of the sync committee on duty at any point in time) that signs blocks. The light client then verifies the aggregated signature produced by the sync committee to verify blocks, along with the beacon state proofs.
At face value, it seems to provide an adequate blueprint to implement an on-chain light client to track Ethereum consensus relatively securely. However, two major considerations have highlighted that the Ethereum Altair Light Client protocol alone may not be an adequate implementation for a bridge use case:
💡 The problem boils down to the sync committee protocol not providing the same, or even reasonable security as a fully synced consensus node against sync committee members signing fraudulent block headers.
The impact of using the Altair sync protocol in its current state is a light client that will be vulnerable to sync committee fraudulent header updates, especially as the bridge collateral grows.
As it stands, with there barely being any penalties for sync committee misbehaviour, the bridge would be completely vulnerable to attack. The current ALC spec works for low-risk, experimental use cases only.
The only current penalty for sync committees (with the current spec) is not producing valid attestations and is capped to 0.1 ETH on a 27 hour period. 512 * 0.1 ETH = 51ETH = around $80 000. To fool the bridge, the sync committee can fool the light client by producing a single, fraudulent block header and withhold any other valid header updates (incurring the max loss of $80k) and the light client will be none the wiser.
There are plans to make sync committee offences slashable: https://github.com/etan-status/consensus-specs/commit/lc-slashing This is only planned for hardfork E (after Capella, Deneb). Even if it is released, at the harshest slashing rule at 32 ETH per violation (which is very unlikely) it would still limit the max bridge value.
The total sync committee stake would likely be less than bridge collateral value, negating the incentive to behave honestly in the sync committee. At the absolute best case, if slashing was implemented slashing the max validator stake for misbehaviour, the total risk of a slashing event would be 32 ETH * 512 = 16384 ETH = $26 398 720,00 and so would cap the max value of the bridge.
A more likely rule would be 1 ETH slashing penalty, which would render the max total sync committee slashing at 512 ETH = $800 000.
There are 2 possible exploitations on sync committees that need to be handled: