The Problem

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.

Impact of Using Altair Light Client Sync Protocol As-Is

Current Sync Protocol

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.

Planned Sync Protocol Improvements

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.

Possible Attacks

There are 2 possible exploitations on sync committees that need to be handled:

  1. Equivocation: The sync committee signs a fraudulent header at the same slot number as the valid header. The light client can detect this by checking each received header and halting the bridge when a conflicting header is received, assuming there is at least ones honest relayer connected to a fully synced full node. This could be collusion between the sync committee and light client relayers. For example, a malicious relayer could share their private key and allow the party with the key to sign any fraudulent data and post it to the light client. The beacon chain won’t know about it because the header isn’t gossiped back to the network.
  2. Data Withholding Attack: In this scenario, the sync committee signs a fraudulent block header, and does not provide the valid header to the light client. This attack is harder to detect and protect against, because the light client has no way of knowing that the provided block is fraudulent (compared to the equivocation, where block collisions can be detected.

Possible Solutions for Data Withholding Attack