How I Learned to Stop Worrying and Love the Sync Committee
Recently there has been some discussion about how the Ethereum sync committee does not get slashed for double signing or signing invalid block headers. We’ve been upfront about this for quite some time: see https://blog.succinct.xyz/blog/proof-of-consensus#security-analysis (opens in a new tab), published last October.
At Succinct, we're building Telepathy (opens in a new tab): a decentralized and secure zkSNARK interoperability protocol. Our core primitive is a gas-efficient on-chain Ethereum light client updated with zkSNARK proofs that validate that enough sync committee members have signed a particular block header.
With the mainnet launch of Telepathy (opens in a new tab), we've thought obsessively about the tradeoffs of the sync committee and have come to the following conclusion: while the sync committee has its shortcomings, we believe it provides greater security than most interoperability systems in production today.
A tl;dr about the Sync Committee
Ethereum's consensus protocol has ~500,000 validators that are responsible for signing attestations that attest to their view of the state of the chain. However verifying all 500,000 of these signatures in computationally restricted devices (such as mobile phones or other blockchains) is infeasible. Core Ethereum contributors prioritized supporting home and long-tail stakers, and thus support for a large number of validators, for the decentralization of the network.
To solve this issue, they introduced the sync committee (opens in a new tab): an in-protocol, randomly selected group of 512 validators that rotates every 27 hours and is responsible for signing off on block headers. The members of the sync committee generate these signatures in addition to their normal consensus duties and earn a small bonus for being part of the committee.
The sync committee does not get slashed for double signing or for signing fradulent headers! Because of this, 2/3 of sync committee members can collude and sign a fraudulent block header without any economic penalty. The Ethereum core devs' argument for not including slashing in the sync committee protocol is it would introduce extra protocol complexity and the economic security of 32 ETH * 512 validators would not be meaningful compared to the security of the entire chain.
When you verify a finalized block header via the sync committee, you are relying on a >1/3 honesty assumption of the sync committee members. In contrast, if 2/3 Ethereum validators decide to sign a header for a block that they have already signed a different header for, half their stake will get slashed (economic security).
With high probability, the sync committee is unlikely to be dishonest
Because the sync committee validators are randomly sampled every 27 hours, if we assume that some fraction of the Ethereum validators are honest, we can model the number of honest sync committee validators as a random variable.
Note that the Ethereum consensus protocol relies on a 1/3 honesty assumption. If we assume, in the worst-case scenario, that only 1/3 of Ethereum validators are honest, then we can compute the probability of honest members of the sync committee with the following formula:
Although the sync committee spec by the Ethereum core team recommends an acceptance threshold of 2/3 of the sync commitee validators, we set our parameters more conservatively in our protocol and require that 90% of the sync committee has signed off a particular header for our light client to accept the update. Thus in practice to submit a false update to our light client, this would mean that < 10% of the 512 randomly chosen validators (=52) in the sync committee are honest. When we set in the equation above, we get a chance, basically 0, that this would ever occur. In the case where less than 1/3 of the Ethereum stake is honest, there are more profitable attacks than attacking the sync committee--for example, finalizing incorrect blocks.
Using the sync committee as additive security
In the context of cross-chain bridging, where hacks are common and security is of utmost importance, preferring safety over liveness is the right choice for most cases. The current status quo is trusting a multisig of people to behave honestly and also not get hacked. While numerous hacks have occured due to implementation errors, it is important to remember that multisig keys do get compromised. Two of the largest bridge hacks (Ronin Bridge for $600M and Harmony for $200M) were both cases of multisig key compromise. Requiring the sync committee’s signature as an additive security measure to a multisig is strictly better than the status quo. The only thing this compromises is potential liveness (since the sync committee can collude to censor transactions), but in the context of cross-chain bridging where hacks are common and security is of utmost importance, preferring safety over liveness is worth it for most cases.
We believe all bridges currently secured by only a multisig would benefit greatly from also requiring a sign-off from 2/3 (or some higher fraction) of the sync committee.
Collusion is difficult as many node operators are public entities
While the sync committee does not have an economic penalty for signing false headers, there is extreme social consequences. Given signatures from the sync committee for a false header, we know which validators colluded to sign this header. There would likely be legal and social consequences for these actions. Given that centralized or semi-centralized node operators control greater than 40% of the Ethereum stake (Lido & Coinbase), these portion of validators would never manipulate the sync committee, already getting to a higher requirement than the 1/3 honesty assumption of Ethereum validators mapped out above.
A long journey
As a company, a succinct Ethereum light client verifying the sync committee is only the first step on our long journey. We plan on verifying full Ethereum consensus in a zkSNARK one day and believe that this is within reach with current techniques. The sync committee is an important first milestone in this journey. It is important to have intermediate milestones that improve the current status quo, even if they aren’t 100% of where we want to eventually be. Where would we be if we required all rollups to have totally permissionless fraud proofs and decentralized sequencers today?
Succinct light clients that can efficiently verify signatures from large validator sets using zkSNARKs is the future of making blockchains and cross-chain interoperability truly robust and ready for prime-time usage. Let’s celebrate the intermediate milestones on the way there.