Informal Systems has been building out Interchain Security v1, which we'll refer to here as "replicated security". There are also several other forms of Interchain Security- opt-in security, and layered (or "mesh") security. In this post we will explore the differences between these forms of Interchain Security. We'll look at the logical differences, and we've also built a mathematical model to explore the economic security of different approaches.
When analyzing the economic security of a blockchain, there are two important numbers: cost to censor and cost to control. However, blockchain economic security is usually discussed in terms of a single number: total staked. 33% of this amount is the cost to censor, and 66% of this amount is the cost to control.
An attacker in control of an amount of stake equivalent to the cost to censor can censor any transaction, and even make the chain stop producing blocks entirely. An attacker who has enough stake to meet the cost to control can completely take over the blockchain, making it do anything, and is able to steal any value stored in it. For example, they could empty all connected IBC bridges.
Replicated security will go live on the Cosmos Hub in January 2023. This system is very easy to understand: Consumer chains get the entire security of the Cosmos Hub validator set. The cost to censor and the cost to control a consumer chain are equal to the cost to censor or control the Cosmos Hub itself.
This is accomplished by the validator set of the Cosmos Hub running the consumer chain's code as well, and being subject to slashing for downtime or double signing.
I won't get into all the details and features here, but along with this high level of security, consumer chains still have their own governance token which controls settings and upgrades on the consumer chain, and whose holders receive the majority of the fees generated by the consumer chain.
Before we dive into mesh security, we want to give an update on ICS v2… Opt-in security is exactly the same mechanism as replicated security, but validators on the Cosmos Hub can choose whether or not they want to validate a given consumer chain. This was originally a highly anticipated feature (hence "v2"), but after careful analysis we have found that it has a fatal flaw.
This flaw is the "subset problem". Stated simply, this is the problem that even if a validator set as a whole is secure, that does not mean that any subset of that validator set is secure. This means that any set of validators opting into a consumer chain could have a malicious majority.
Here's a simple example of this problem: A new consumer chain is created, and several small Cosmos Hub validators start validating on the chain. Then, a large validator opts in. Depending on the powers involved, the large validator might have 66% of the power at this point and control the chain. It can then do anything, including emptying all the money out of the chain.
In the cost to censor/control framing, the cost to control a consumer chain that not many validators have opted into can be low, even if the Cosmos Hub's overall cost to control is very high. Additionally, the attack is much easier to carry out than usual. To control 66% percent of a chain's stake normally would require buying it on the market, which is difficult to accomplish without the price spiking. With opt-in security, 66% of the stake could be seized instantly by a large validator opting into a small consumer chain.
It is true that there are endless mechanisms one can think of to mitigate this issue. For example, making a rule that no one validator on a consumer chain can have more than 10% of the total power. However, to the best of our knowledge, each one of these mechanisms can be circumvented by an attacker making multiple validator accounts.
Is opt-in security likely to be insecure in the majority of cases? No. There are many hypothetical scenarios where opt-in security may be perfectly secure. But on the Cosmos Hub, we are not in the business of kinda-sorta-maybe security. Opt-in security's fatal flaw is that it is impossible to tell when the system might shift into an insecure state, and until a solution to the subset problem is found, we won't build it.
Another long-awaited feature is the ability for a consumer chain to get security from multiple providers. We've called this "layered security" or "v3" in the past. Accomplishing this while avoiding the subset problem has proved to be tricky. Cosmos chains run on the Tendermint consensus protocol. Validator sets which are too large begin to have poor performance due to network overhead and other factors. Once you have one consumer chain being validated by the validator sets of multiple provider chains, the consumer's validator set could quickly grow quite large, even if you deduplicate validators that appear on multiple provider chains.
The naive solution to this is to throw away some validators by limiting the consumer chain's active set to 200. But if you do this, you run afoul of the subset problem explained above, because now you only have a subset of the validators from each provider. This may be less likely to lead to an insecure scenario than in opt-in security, but it is still an issue.
Recently, Sunny Agarwal, the CEO of Osmosis, came up with a great way to accomplish layered security without the subset problem. Sunny's insight is that instead of taking the validator set of the provider chain(s), you can allow delegators on those provider chains to delegate to validators in the consumer chain's own validator set, using the provider chain's token (which remains bonded on the provider chain). Since there is no longer any need to take a subset of provider validators, you avoid the subset problem.
We've analyzed this carefully from many angles, and at this point we can say that it seems secure in theory. The security of any potential implementation is a different matter. There are some factors and settings which need to be considered carefully which I won't get into here, but it can work in principle. Of course this is not a final determination, but if nothing unexpected comes up, we foresee a future with Mesh Security on the Cosmos Hub.
We've created a mathematical model which encompasses both replicated and mesh security (and other types of shared security). Using this model, we can get an objective view of the security that various configurations of replicated and mesh security provide. We've also turned the model into an app that you can use to explore these scenarios yourself. We'll go over a few scenarios below, but you can also click on the links to experiment with them yourself.
Let's look at replicated security first. This is what will go live in January 2023. A consumer chain using replicated security has the same cost to censor or control as its provider chain, in this case the Cosmos Hub. The Cosmos Hub grants a very high level of security.
Next is mesh security with a 10% power cap. This is what Sunny suggested in his talk on mesh security at Cosmoverse 2022. Even though there are some very large chains (including the Hub) providing security, the security is constrained by the power cap. The cost to censor is $83mm and the cost to control is $273mm. Without mesh security, the consumer chain's $100mm stake would give $33mm and $66mm. It's a solid improvement, but compared to their size, the provider chains are able to add little security.
By taking the power cap off, we can really boost the security. The security is almost 9 times higher than with the 10% power cap. Now, we have even more security than what was provided by replicated security in the first example. The cost to censor and the cost to control are both about 25% higher than what you can get with replicated security. Nice.
Projects can launch very high security blockchains today (well, in January) using replicated security and the Cosmos Hub. Mesh security can improve on this somewhat. But the numbers aren’t the only story. Mesh security is really only a way to increase the amount delegated to the validators on a chain, and the numbers in our model won’t be reached without every delegator on every provider chain delegating to the consumer chain. To have full mesh security, the chain’s team will need to have a big outreach push to make this happen.
Additionally, if the Cosmos Hub itself is using mesh security, the full security it gets from mesh will go to all of its replicated security (ICS v1) consumer chains. It will be a lot easier to get delegators on other chains in the mesh to stake their token on a single Hub validator, and thereby secure all of the Hub’s replicated security consumer chains.
If a chain still wants to use mesh security when it is available, we are working on a protocol to seamlessly transition the security model. The chain will still need to find validators, get itself added as a consumer chain to other mesh security chains, and then persuade delegators on those chains to delegate. But the process of actually exiting the Cosmos Hub replicated security zone will be smooth and easy.
We've shown that mesh security is a great idea which increases economic security. But is it "more decentralized" than replicated security? That's very hard to answer, since the definition of decentralization is notoriously fuzzy. Mesh security is certainly more complicated, and there are more blockchains involved.
But as Sunny showed in this tweet , most Cosmos blockchains have around a 70% overlap in their validator sets. I'm guessing it's a similar amount of overlap in their delegators and token holders. So, the number of people and entities involved in running mesh security is not drastically higher than on a single chain.
Blockchains are already decentralized systems, and their validators are connected in a mesh. This is as true of the Cosmos Hub as any other blockchain. Additionally, the Cosmos Hub is exceptionally decentralized among blockchains. It may be the most decentralized chain since Bitcoin. The Cosmos Hub has no central leadership team, and no CEO. Governance proposals, and additions to the governance system itself, are debated with great vigor among a large number of people, and decided by the community. The Cosmos Hub is a vibrant democracy among blockchains, many of which are still run like VC funded tech startups.
With replicated security, projects can tap into the Hub's extremely high economic security, as well as its vibrant decentralized community. Once it's ready, projects using replicated security can enable mesh security to gain a bit more economic security (25% in the above example), and get a bit more decentralization as well!
We use the following model to reason about different designs. This model backs the app used in the examples above:
$$1 = \alpha\cdot TotalStaked_C + \sum_{i}{\beta_i\cdot CrossStaked_{Pi}},$$
where \(1\) is the normalized voting power on the consumer chain, \(TotalStaked_C\) is the dollar value of the total amount of staked native tokens on the consumer chain and \(CrossStaked_{Pi}\) is the dollar value of the stake delegated from the provider chain \(Pi\) to the consumer chain. \(\alpha\) and \(\beta_i\) are multipliers used to compute the voting power you can buy with one dollar equivalent of that particular token. Note that computing \(TotalStaked_C\) and \(CrossStaked_{Pi}\) requires a price oracle.
Note the following special cases that are covered by this model.
A sovereign chain without any shared security: \(\alpha = \frac{1}{TotalStaked_C}\) and \(\beta_i = 0, \forall Pi\).
A consumer chain secured by replicated security: \(\alpha = 0\), \(\beta_1=\frac{1}{CrossStaked_{Pi}}\), \(\beta_i = 0, \forall Pi \neq P1\), and \(CrossStaked_{P1} = TotalStaked_{P1}\)
In addition, to be able to reason about the security provided, we introduce the following inequality:
$$\forall Pi, \exists q_i: 0\leq\beta_i\cdot CrossStaked_{Pi} \leq q_i \leq1,$$
i.e., the token of the provider chain \(Pi\) controls at most \(q_i \cdot 100\%\) of the consumer chain's voting power. Consequently,
$$\alpha\cdot TotalStaked_C \geq1 - \sum_{i}{q_i}.$$
The <strong>goal of cross-staking</strong> is to increase the security (i.e., the price of corruption) of a consumer chain. An essential <strong>requirement of cross-staking</strong> is for the security of the consumer chain to never go below the security provided only through the native token (i.e., when the consumer is a sovereign chain without any shared security). This requirement entails that for every provider chain \(Pi\) there is a crossing point from where increasing \(CrossStaked_{Pi}\) does not increase \(\beta_i \cdot CrossStaked_{Pi}\). This is given at the boundaries of the inequality above. Until that point, as you don't want to decrease the price of voting power on the consumer chain, the amount of power you can buy with one dollar of consumer tokens must be equal to the amount of power you can buy with one dollar of \(Pi\) tokens, i.e., \(\alpha=\beta_i\).
For brevity we use \(S_C\) to denote \(TotalStaked_C\) and \(S_{Pi}\) to denote \(CrossStaked_{Pi}\).
We consider the following configuration:
\(C\) is the consumer chain
\(P\) is the provider chain
\(1 = \alpha \cdot S_C + \beta \cdot S_P\)
\(\beta \cdot S_P \leq q\), with \(0 \leq q \leq 1\)
\(\alpha \cdot S_C \geq q\)
Not all the tokens staked on \(P\) must be cross-staked. Thus, \(\alpha\) and \(\beta\) are not static. The more \(P\) tokens are cross-staked, the more the \(C\) tokens are diluted. After enough \(P\) tokens are cross-staked to account for \(q\) of the voting power, the \(C\) tokens are no longer diluted.
We have the following two extreme cases:
$$ \left\{ \begin{array}{lcl} S_P = 0 & \Rightarrow & \alpha = \frac{1}{S_C} \\ S_P \rightarrow \infty & \Rightarrow & \alpha = \frac{1-q}{S_C}, \beta = \frac{q}{S_P} \end{array} \right. $$
Note that for \(S_P = 0\), \(\beta\) is irrelevant as this is the special case with no shared security.
To find the crossing point where increasing \(S_P\) does not increase \(\beta \cdot S_P\), we must solve the following system of equations:
$$ \left\{ \begin{array}{lcl} \alpha \cdot S_C & = & 1-q \\ \beta \cdot S_P & = & q \\ \alpha & = & \beta \end{array} \right. $$
Thus, the crossing point is
$$ S_P = \frac{q}{1-q}S_C \Rightarrow \alpha = \frac{1-q}{S_C}, \beta=\frac{q}{S_P}=\frac{1-q}{S_C} $$
And the values for \(\alpha\) and \(\beta\) for \(S_P \in [0, \frac{q}{1-q}S_C]\) are \(\alpha = \beta = \frac{1}{S_C+S_P}\).
To sum up:
$$ \left\{ \begin{array}{lcl} 0 \leq S_P \leq \frac{q}{1-q}S_C & \Rightarrow & \alpha = \beta = \frac{1}{S_C + S_P} \\ S_P > \frac{q}{1-q}S_C & \Rightarrow & \alpha = \frac{1-q}{S_C}, \beta = \frac{q}{S_P}, \textrm{with } \alpha > \beta \end{array} \right. $$
Note that \(\alpha\) and \(\beta\) are indicators of a tokens dilution, i.e., the higher they are the more power you can get with the corresponding token.
We consider the following configuration:
\(C\) is the consumer chain
\(Pi\) are the provider chains
\(n\) is the number of provider chains
\(1 = \alpha \cdot S_C + \sum_{i=1}^{n}{\beta_i \cdot S_{Pi}}\)
\(\forall Pi, \beta_i \cdot S_{Pi} \leq q_i\), with \(0 \leq q_i \leq 1\)
\(\alpha \cdot S_C \geq 1 - \sum_{i=1}^{n}{q_i}\)
We have the following two extreme cases:
$$ \left\{ \begin{array}{lcl} S_{Pi} = 0, \forall Pi & \Rightarrow & \alpha = \frac{1}{S_C} \\ S_{Pi} \rightarrow \infty & \Rightarrow & \alpha = \frac{1 - \sum_{i=1}^{n}{q_i}}{S_C}, \beta = \frac{q_i}{S_{Pi}} \end{array} \right. $$
Note that for \(S_{Pi} = 0, \forall Pi\), \(\beta_i\) are irrelevant as this is the no shared security special case.
Let \(\mathcal{P}\) be the set of all provider chains \(Pi\) that are below the crossing point, i.e.,
$$ \beta_i \cdot S_{Pi} < q_i, \forall Pi \in \mathcal{P} $$
Then,
$$ \left\{ \begin{array}{lcl} \beta_i & = & \alpha, \forall Pi \in \mathcal{P} \\ \beta_i & = & \frac{q_i}{S_{Pi}}, \forall Pi \notin \mathcal{P} \end{array} \right. $$
As a result,
$$ \alpha(S_C + \sum_{Pi \in \mathcal{P}}{S_{Pi}}) = 1 - \sum_{Pi \notin \mathcal{P}}{q_i} $$
We can find the values of \(\alpha\) and \(beta_i, \forall Pi\) iteratively using the following approach:
Initially, all the providers are not capped, i.e., \(\forall Pi \in \mathcal{P}\).
Compute \(\alpha\), i.e., $$\alpha = (1 - \sum_{Pi \notin \mathcal{P}}{q_i}) / (S_C + \sum_{Pi \in \mathcal{P}}{S_{Pi}})$$
Cap providers, i.e., $$ \mathcal{P} = \mathcal{P} - \{Pi: \alpha \cdot S_{Pi} > q_i\} $$
If \(\mathcal{P}\) was modified, go back to step 2 and recompute \(\alpha\).
Note that if \(\alpha > 0\), then \(\beta_i < \alpha, \forall Pi \notin \mathcal{P}\). As a result, every iteration will result in higher values for \(\alpha\).