Altair has no Light Client
ALC is a recursive acronym for "ALC is no Light Client" :)
Background Info
In the Altair hard fork, eth2 introduced an in-protocol system that enables beacon-chain light clients. A light client is a node that follows the consensus process, without validating and re-executing block contents. It’s a “headers-only” mode for syncing the blockchain. Light clients are attractive for people who can’t be bothered to keep a server running at all times, but still don’t want to just believe in Infura. The most notable eth2 light client implementation is Helios.
Light clients provide reduced security relative to full clients. Because it does not validate the bodies of blocks or user-facing state (only the headers and consensus state), a light client must assume that non-consensus state and state-transitions are correct. We call this the “SPV Assumption” for historical reasons. For an additional primer on light clients, the SPV assumption, and ZK light clients (ZKLCs) you can check out my talk at Starkware Sessions 2019.
Nobody, and I mean NOBODY has a credible design for on-chain eth2 light clients. They all suck. Someone needs to make a sensible, standardized, reviewable, reasonable, trustworthy specification.
The Altair Light Client
The Altair Light Client (I’ll call it “ALC”) has a very straightforward design. Every 256 epochs (about 27 hours) the consensus process selects a committee of 512 validators. These validators receive approximately 0.1 extra ETH (each) during that period if they sign and submit attestations to the latest beacon chain block. When the attestations are not included in the next block, they are penalized a corresponding amount of ETH. The proposer also receives a small additional reward if these attestations are included in the next block. The current and next sync committee are listed in the block header, so a light client can “look ahead” to the next sync committee.
In order to sync the chain, a light client keeps a local header, and records the current and next sync committee. They can then use sync committee signatures to update their local view of the chain state. Because the sync committee signs the header, which commits to the chain’s finality, a light client can easily discover the latest finalized header. This allows it to quickly get up to speed and join the network. I’m obviously glossing over a number of implementation details. If you’re interested in the full ALC specification, you can find it here.
Sync Committee Behavior is Unconstrained
The ALC design relies on the sync committee’s signatures. Light clients grab sync committee attestations and apply them to their local view of the chain. Unfortunately, there are no protocol constraints on what this signature can be. Sync committees are rewarded for producing valid attestations. They are not penalized for invalid ones. The committee can lie. Committee members are free to produce as many signatures as they want on anything. They cannot be slashed. And as long as they produce correct signatures in addition to the false ones, they receive full rewards. The dominant strategy for a sync committee is to blindly sign every header anyone presents them with, so that hopefully they hit the right one.
This allows sync committee members to coordinate to cause some degenerate scenarios:
A light client may receive many semantically invalid attestations, with valid signatures.
A ZKLC may receive a valid proof, with semantically invalid data.
A ZKLC may receive a valid proof, but have the data withheld.
In addition, sync committee penalties are small (capped at ~0.1 ETH per validator for the 27 hour period). Therefore, it is cheap ($82,000ish or 0.3% of stake) for a committee to just not produce any valid attestation during a period. For a tiny loss in returns, the sync committee can ensure that ONLY invalid attestations are available. Because sync committee behavior is unconstrained by the consensus process, the ALC design inherits no economic security from the base chain consensus process. Committees can just sign whatever.
Altair Can’t Bridge
On-chain light client bridges, like TBTC and IBC, require the SPV assumption. Validating a full chain on another chain is impossible (without recursive ZK chains (don’t hold your breath)). Light client bridges wait until they have high confidence that the remote chain has finalized before accepting cross-chain messages or transfers. They achieve this confidence by following the consensus process and making the SPV assumption. A faulty assumption is disastrous. Developers need a thorough understanding of the limitations of SPV assumption for a given consensus system.
The security of the SPV assumption for a given chain is always expressed as an either-or statement. “EITHER the state is correct OR [a specific failure has occurred].” We want this failure to be as costly and unlikely as possible. And we want consequences if things go wrong.
PoW: “EITHER the state is correct OR many dollars were spent on Proof of Work for fake headers”
Tendermint IBC: “EITHER the state is correct OR the entire chain has faulted.”
ALC: “EITHER the state is correct OR the sync committee decided to steal from us.”
PoW light client forgery has high costs. IBC light client forgery has significant consequences. The ALC, unlike other light client designs, permits the sync committee to simply sign a bad attestation without cost or consequence.
Suppose that a bridge uses the ALC system to update its state. The sync committee members could, at any time, choose to provide invalid information to the bridge without any penalty. The bridge relies on signatures from actors without constraints. The ALC is equivalent to a multi-sig. However, unlike a multisig, the ALC multisig changes every 27 hours, is randomly selected, and is not affiliated with the bridge in any way. The sync committee has no in-protocol reason NOT to steal from the bridge, and potentially a large financial incentive to steal. It would not be difficult to write a flashbots-like client modification that opportunistically fakes sync committee attestations and exploits light clients.
The ALC is indistinguishable from a multisig, however the bridge was not able to choose its participants. Random multisigs are worse multisigs. Never ever make honesty assumptions about unknown parties.
A quick aside
The ALC design works for off-chain light clients because they can use it to bootstrap a view of the consensus process. Rather than simply trusting the sync committee they must validate its update against their local view of the validator set. They must then validate historical epoch attestations and validator set drift to be sure that the sync committee’s attestation checks out. Which is to say, the sync committee is a multisig that aids syncing recent events.
If the light client does not validate epoch committee attestations, it has no defense against a malicious sync committee, and thus no economic security. The requirement that light clients validate historical epoch committee attestations to get economic security is not documented in the spec. It’s unclear whether the designers fully understand this requirement.
Light clients derive their security from the protocol, within the bounds of their SPV assumption. Because ALC does not derive any economic security from the protocol it is not a light client. Instead, I’d call it a bootstrapping mechanism for light clients. The ALC design represents a first for the Ethereum ecosystem: official endorsement of an honesty assumption without economic arguments. Not sure how I feel about this foray into Cosmos political theory.
Solutions
There are two reasonable solutions that light client bridges can implement to relay eth2 today.
First, they could follow epoch committee attestations, the way an off-chain light client does. Unlike the sync committee, the epoch committees are not explicitly committed in the block header. Therefore, this solution would require the light client to maintain a local view of the (very large) validator set, and check correct epoch committee selection for each epoch. Missing an epoch would require the bridge to be rebooted. Because this requires more expensive computation (tracking the validator set is haaaard) and more frequent computation (every 12 minutes instead of every 27 hours) this is a fabulous cost increase for an on-chain light client relative to a naive ALC sync-committee follower.
Alternatively, they could introduce their own multisig, with new bespoke incentives. The ALC committee is an unconstrained chain state oracle, so why not make your own chain state oracle, with constraints you like better? This seems likely to happen as it’s a great place to shoehorn in a token. A separate committee dedicated to serving the light client is especially necessary for on-chain ZKLCs, which are vulnerable to data-withholding attacks and need a DA committee in addition to their new incentivized blockchain state oracle committee.
Neither of these solutions spark joy.
The third option (yes, I said two reasonable solutions. This is the unreasonable one), is hard forking to add explicit epoch/slot committee commitments. Explicit commitments allow us to verify aggregate attestations directly, rather than relying on the sync committee. We would love it if we could connect the light client directly to slashable attestations. If hard forks are on the table, this problem is solvable. However, in the meantime, we kinda gotta deal with what we have
State of things
ALC is not suitable for bridges. They’re only suitable for off-chain light clients as a bootstrapping mechanism, and must be followed by epoch attestation validation. Altair is not a light client. It’s a quick-sync aid for new consensus-following nodes. While that is useful on its own, the bait-and-switch sucks. Light clients derive security from the consensus process. Altair derives security from a new honesty assumption.
Eth2 light client solutions for bridges all suck. It’s likely we’ll see messy hybrids. It’s unlikely we’ll see a real light client in a future eth2 hard fork. Honestly, I’d prefer a multisig to all this Eth2 light client mess.
Indeed, the Altair light client isn't accountable and so isn't secure enough for bridges.
>Therefore, this solution would require the light client to maintain a local view of the (very large) validator set
We spent rather a long time coming up with a good solution for avoiding that: https://eprint.iacr.org/2022/1205
and it works fine with a million BLS keys if Ethereum would be interested in adopting it.
>The ALC is indistinguishable from a multisig, however the bridge was not able to choose its participants. Random multisigs are worse multisigs.
I agree that it is a multisig, but is random multisigs truly worse than a fixed set of validators (solution 2)? Would a user put more trust on 512 rotating, randomly selected validators or 20-ish fixed validators (as in bridges nowadays)?
I also agree that ALC is not derived from the consensus process, but at least the randomness is. But it's still a step up from the fixed 20-ish validators we have right now.