Most shared security schemes other than Replicated Security suffer from a fundamental security challenge known as the “subset problem”. To put it simply, this is a situation where a malicious subset of the provider chain’s validator set control a consumer chain and attack it in a way that they cannot be slashed for. There are two attacks possible here- a safety attack using incorrect execution (breaking the rules of the protocol without double signing), and a liveness attack where the validators just stop signing blocks, halting the chain completely until it hard forks (likely disrupting all use of the chain for weeks).

The safety attack can be stopped by fraud or validity proofs (preventing money from being taken out of the chain if it has been attacked, and possibly slashing validators automatically), or a “fraud vote” where the guilty validators are slashed by a governance vote on the provider chain(s). Since this fraud vote mechanism is so open ended, it is easy to conclude that it can stop any problem, but in reality, these votes can become very contentious and complicated even in straightforward cases (like prop 818).

The liveness attack can only be stopped by a fraud vote, and not any kind of proof, since it is currently very hard to conclusively prove anything about liveness.

It’s notable that this subset problem also affects restaking protocols such as Eigenlayer, Mesh Security, and Babylon. Their solutions are currently incomplete AFAIK.

• Eigenlayer combats the safety problem by only intending to be used with fraud or validity proofs, although they have a multisig which controls slashing.
• Eigenlayer purports to combat the liveness problem by allowing projects to choose to only allow “decentralized” validators, like ones using RocketPool. This is extremely weak in theory, but may work OK in practice, but relies heavily on trust in whoever is certifying that the validators are really decentralized.
• Mesh Security does not have any more solutions to this problem than anyone else, and will advise that consumer chains get no more than 25% of their security from Mesh at first. They will also likely use fraud votes which will take care of it, but with the shortcomings discussed above.
• Babylon is in the same position as Mesh Security, but can’t use fraud votes on Bitcoin. The safety problem can be stopped by using fraud or validity proofs, but liveness may still be an issue.

Token toxicity and the restaking ratio

This problem does not affect Replicated Security (and standalone blockchains with their own staking token) because if the validator set colluded to attack a consumer chain or the standalone chain itself, the staking token would crash in value, costing the validators and their delegators a lot of money. This dynamic is known as “token toxicity”.

In Replicated Security, 100% of the power of the provider chain is securing the consumer chains. I’ll refer to this as the “restaking ratio”.

• It is clear that the subset problem does not affect systems with a restaking ratio of 100%, like Replicated Security and standalone chains.
• It is clear that the subset problem could affect systems with a restaking ratio of <10%.
• It is also clear that the subset problem is very unlikely to affect systems with a restaking ratio of, say, 99%, since that is basically the same as 100%.
• It’s less clear whether the subset problem affects systems with a restaking ratio of 66% or 50%, and it is also not clear how this could be determined quantitatively. It may be that low-ish restaking ratios are still pretty safe in real life.