Overview of Existing Cross-Chain Security Models

Limitations of Isolated Cross-Chain State Security:

Current approaches to messaging and bridging between EVM chains rely on isolated economic guarantees. These guarantees typically are k of n assumptions, where proving that a state exists or a transaction occurred on a different chain requires a plurality, k, of a set of n nodes to agree and sign. Examples of these approaches include multi-signature wallets, threshold signatures schemes across attestation sets, Tendermint proof-of-stake consensus and proofs of Ethereum’s light client sync committee.

While each of these approaches have distinct advantages, they all share a central flaw: each cross-chain protocol has a capped sized set of validators that can be attacked in isolation by compromising a plurality of its nodes. Empirically, we’ve seen isolated k of n security guarantees fail, including the well-publicized hacks of Ronin Bridge ($650m), where 5 out of a set of 9 validators were compromised and Harmony Horizon ($100m), where 2 out of a set of 5 validators were compromised.

Security across isolated k of n protocols is either constant or sublinear with respect to their staked collateral. In short, as the amount of available collateral increases, security increases at a diminishing rate as the validator set begins to cap out in size.

To improve on the limitations of isolated k of n security guarantees, newer cross-chain protocols, such as zkBridge, Polyhedra Network and Succinct Labs, have begun to generate proofs of the signatures by Ethereum’s light client sync committee members. While Ethereum’s light client sync committee provides a rough proxy for Ethereum consensus, its security has inherent limitations when used for proving Ethereum state on other chains.

Understanding Ethereum Sync Committee:

The sync committee of Ethereum is a group of 512 Ethereum validators that are chosen at random every 256 epochs (~27 hours). The sync committee is responsible for continually signing new block headers, so that Ethereum light clients can verify chain state, without having to know the entire validator set. Nodes are given 512 epochs (~54 hours) of prior notice before they become a sync committee member.

The security of light client bridges, ZK bridges and sync committee proofs are all based on verification of signatures from the Ethereum light client sync committee. As the size of the sync committee is fixed, the economic security that underpins it is also capped over a 27-hour window. Once slashing is eventually implemented for Ethereum sync committees, the economic security will be bounded as follows:

Economic Security of Sync Committee = 512 nodes * 32 Eth * $1650 USD/ETH = $27,033,600

Threshold to Compromise Sync Committee = $27,033,600 * 2/3 = $18,022,400

Limitations of Ethereum’s Light Client and ZK Light Client Bridges:

While light client bridges and ZK light client bridges are thought of as a gold standard for cross-chain interoperability, the amount of assets they can secure with randomized sync committees is severely limited. As previously shown, the amount of collateral that colluding nodes would have to burn to simultaneously compromise all Ethereum light client and ZK light client bridges is capped at $18m.

Consider a situation, where the sum of the value of all assets secured by all light client and ZK light client bridges is of an amount k. When k < $18m, all assets secured across the bridges are safe, as an attack is not economically viable.

As k grows such that k > $27m , it becomes profitable for a group of bad actors in the sync committee to attest to malicious blocks in order to compromise the secured assets. The only remaining security once this economic threshold is passed is the complexity of requiring 342 random nodes (2/3 of the sync committee) to communicate and coordinate an attack over an 81-hour window.

While collusion between randomly selected nodes over a ~3.5-day window is very difficult, it’s not impossible if the upside of the theft is high enough.

Despite the Ethereum light client sync committee having limited security, zkBridges lack a feasible alternative for proving correct Ethereum state. Generating a SNARK proof of the finality of an Ethereum block based on consensus (Casper-FFG) would require verifying an aggregated BLS signature and a set inclusion proofs for at least ⅔ of the active set of validators for each block. Given that the public keys of all active validators are stored within a contract on Ethereum, each set inclusion proof requires proving with the Keccak hash function and the RLP prefix encodings native to Ethereum. In total a SNARK proof of Casper-FFG for a single block would require at least ~400,000 individual set inclusion proofs, containing a total of ~5,000,000 Keccak hashes and RLP serialization proofs, making such a SNARK proof currently infeasible.

Given the limitations of the Ethereum light client sync committee’s security and the infeasibility of proving Casper finality, an alternative design is needed for trustless cross-chain state proofs.