How Mesh Security can help in scaling Cosmos

I am extremely fascinated by the new concept of Mesh Security, formally first presented by Sunny Aggarwal at Cosmoverse 2022. While it may seem that it shares some similarities with Interchain Security v3, I see it as fundamentally different in nature and novel with respect to any current design of Interchain Security (an explorative comparison and analysis here). I see it as a new form of “Interchain Security”, not focused on cross-chain validation. This is because Mesh Security — at least the way I see it — is not about Validation as a Service, but about Delegation as a Service.

In Mesh Security there is no need for sharing or cross-chain linking of validators

In Sunny’s presentation I think there was too much emphasis on the fact that validator sets across chains overlap, so much so that Sunny stated it was a feature, and should be exploited with Mesh Security by doing cross-chain correlation of validators. I argue the opposite. The overlapping of the validator sets does not bring any benefit, and should not be incorporated as a requirement or leveraged by Mesh Security. It is actually desireable — as always I would say — to have diverse and varied validators sets with as little overlap as possible.

As a matter of fact in the Mesh Security CosmWasm prototype this assumption is not relied upon anymore, and there is no cross-chain linking of validators performed, for all I can see. It’s entirely relying on the consumer chain validator set. And if this is true, this is the right approach in my opinion. As Sunny stated later in his presentation, delegations are the fundamental unit of Mesh Security, not validators. With Mesh Security you share security capital, but you re-delegate it to existing validators on the consumer chain. As a producer chain, you only share delegations and not validators. There is no “hosting” — and there is no sharing of validators, there is only sharing of security capital.

This key difference is what makes Mesh Security fundamentally separate from any current design of Interchain Security. With Mesh Security the focus is — again — on delegations, and increasing the security capital of the consumer chain by providing additional stake. This makes it inherently also less complex and hence easier to implement than for example Interchain Security v3.

To be clear, I am not arguing that Mesh Security makes Interchain Security v1, v2 and v3 obsolete (or any flavor of Validation as a Service). These two models will coexist as they present different benefits and trade-offs. Different forms of “hosting” will play a crucial role in achieving massive scaling — which means also smart contracting platforms are here to stay — but a model that allows to retain a higher degree of sovereignty I argue will be the dominant one. And this is Mesh Security.

Mesh Security allows to retain sovereignty

In a system like Mesh Security the way by which security is shared is flipped on its head: instead of relying on the sharing of validators, it relies on the sharing of delegations. This means that on a consumer chain the validator set is independent from the validator set of the producer chain, and perhaps it would even be preferable if they are completely disjoint (by this I mean no overlap with sybil identities). The sharing of security is achieved by allowing the bonded tokens on the producer chain to be double-staked also on the consumer chain, and this stake delegated to one of the validators there. This means that this double-staked security capital is also used to secure the consumer chain, and is potentially slashable there — but it is also rewarded as (or close to) if it was native stake. Risk is “doubled”, but “so is” reward.

How is this achieved? in a simplified way, we can imagine the delegations from the producer chain being converted to equivalent delegations on the consumer chain, let’s call them “synthetic staked tokens” (but more precisely “synthetic delegations”). This is achieved say through means of an oracle that provides conversion rates for other tokens — of connected producer chains — denominated in the native staking token, so to “easily” enable the conversion.

And what power does it give to the producer chain over the consumer chain? If we don’t count “synthetic staked tokens” for governance voting, i.e. towards determining voting power for the x/gov module (as also mentioned as a possibility in the README of the Mesh Security CosmWasm prototype repo), this added stake would only count towards determination of the voting power for block production (further discussion later). Governance voting could only be done with the native token, which allows for more independence and autonomy.

With Mesh Security, dependency from a producer chain is limited: if the producer chain experiences issues up to having the synthetic stake going to 0, the consumer chain would default back to only relying on its native staking token for security (and potentially delegations from other producer chains?). But this would not affect the native staking token itself. Since synthetic delegations are not liquid, nor can be liquified in its synthetic form, it is hard for me to imagine how manipulation of the producer chain token price could affect the consumer chain token price. There is a risk of the producer chain possibly taking over, but this is another sort of risk.
Seemingly, disruption of a producer chain should also not affect operations for the consumer chain, with the proper mitigations in place, as there is no reliance on other validators for block production other than the local validator set.
On the contrary, Interchain Security v1, v2 and v3 bank on the fact that consumer chains are willing to give up on validator set independence to borrow security from the producer chain by means of its validators. And if these validators are affected or act maliciously (or simply against the consumer chain) it would be easier for the chain to arrive to a halt. This implies though that giving up on independence is a feature in Interchain Security v1, v2 and v3 (and it could be beneficial for certain applications) while for Mesh Security this could be treated as an undesireable effect that need to be mitigated or disincentivized.
In some sense, Mesh Security is more akin to ICS2B as defined in the ATOM One constitution. In the document, Jae Kwon proposes an alternative taxonomy to Interchain Security beyond v1 that is a bit more abstract and generic to the current canonical versions of Interchain Security (disregarding the discourse around PHOTON and replacing it with “bonded ATOM”) since it is not focused only on cross-chain validation.
While ICS1 and ICSv1 are the same, ICSv2 can fall into the more abstract definition of ICS2A and ICSv3 into the more abstract ICS2B. To the same extent, as I mentioned Mesh Security also falls into ICS2B. However, Mesh Security and ICSv3 aren’t the same thing, as we discussed previously.

Enabling sovereignty — and interoperability via IBC — is what makes Cosmos so powerful. I argue that sharing capital for security (with proper risk mitigations) while retaining a higher degree of autonomy and independence is going to be the dominant cross-chain security-sharing model. And while seemingly in competition with the current Interchain Security versions, it is actually a different approach that could be implemented in parallel and exploited even from an ICS-focused chain like the Cosmos Hub. Actually, given the substantial security capital allocated to the Cosmos Hub through staking, this could be an interesting “reuse” of this capital that however strictly retains its role of securing also the Cosmos Hub.

Mesh Security provides resilience without central points of failure

On a pure delegation-based system, without validators correlation across chains involved in the mesh, handling slashing events with multiple consumer chains involved should be as hard as handling the case of being connected with only one consumer chain, where the slashing has occurred. After the slashing event has been processed by the producer chain, the new token amounts are relayed to all the consumer chains involved, and each of them updates its internal state accordingly. The complexity in my opinion “only” lies in the linearly-growing amount of IBC communication required, which is however definitely non-trivial.

For a producer chain, cross-chain slashing should have impact on delegators’ stake, not validators.

Enabling this technically — as other necessary changes such as removing synthetic delegations from counting for x/gov— might require modifications to the x/staking module to treat a cross-chain slashing event differently from a native slashing event.
When a cross-chain slashing event occurs, involved cross-delegators should be individually identified and handled. As it is a delegator-based slashing, the slash amount computed for each involved cross-delegator would:
1. be equally distributed across underlying local delegations used for the affected cross-delegations
2. be computed as a burn of tokens for the affected delegation pools, but with a corresponding burn of delegations from the delegator, so that the burn is absorbed only by the affected delegations and not distributed across all existing delegation shares.

Another — simpler and probably preferable— approach (currently used in the CosmWasm prototype) would be to abstract on top of x/staking and use regular unbondings to handle cross-chain slashing events. This can be achieved with an additional module to enable lockup of producer chains’ delegations, that can then be used also for cross-staking, so that these delegations are managed by the producer chain itself until cross-delegations exist. If a slashing event occurs from a consumer chain, the tokens from the point of view of x/staking are regularly unbonded, and would be burned afterwards and separately. This would not remove the need from other necessary modifications to x/staking such as the removal of synthetic delegation from counting towards x/gov.

With Mesh security, there might be more powerful chains with more connections, but there isn’t necessarily a single point of failure. Most importantly, failure of a chain would be less impactful than when an ICS-provider chain fails. If a producer chain fails, other connected consumer chains would see their security capital (and cost of corruption) potentially decrease, but it’s hard to envision a scenario where the failure of a producer chain could impact actual operations of a consumer chain (i.e. causing halting). This unless the consumer chain itself “misused” Mesh Security and loosened its base security (i.e. counting only its native staked tokens) to dangerous levels. And the limited ability for disruptions in producer chains to damage consumer chains is especially true if some form of TWAP — and/or a risk adjusdment factor— is used in determining actual conversion rates (similarly to what is done / will be done with superfluid staking).

The mesh could survive and recover from the failure of potentially any chain in the mesh.

For a producer chain there is an inherent incentive in providing stake to as many consumer chains as possible, especially if consumer chains are capping the achievable voting power. There is no point in limiting how many times bonded tokens can be cross-staked to other consumer chains, as the increased risk of slashing and the diminished rewards if “overstaked” to a consumer chain with respect to the power cap (as explored later) represent already a sufficient disincentive to excessive cross-staking. But again, this means that producer chains would be incentivized to connect to as many chains as possible. Of course, connections should always be established by governance after proper scrutiny and evaluation of the consumer chain, as delegators from the producer chain would put their stake at increased risk of slashing.

Seemingly, for a consumer chain there is an incentive to connect to as many producer chains as it’s reasonably meaningful, because collectively each producer chain could provide enough synthetic stake to sufficiently increase the chain security capital, without any of the producer chains being able to take over. I am again assuming here that the added voting power from each producer chain is capped to a percentage of the native stake — as discussed later when discussing the risk of delegators collusion — and that it does not count towards x/gov. But I am not necessarily seeing as a requirement to force a ratio between the local voting power and the total exogenous stake from all the connected producer chains. The limitation should come from chosing wisely the number of producer chains to connect to in order to achieve the desired level of security. Proper governance scrutiny should also happen when allowing a new producer chain to be connected, as the added benefits might be minimal otherwise, or it might even be detrimental and introduce security risks.

It is clear that a system based on Mesh Security has the potential to organically scale into a big and complex mesh structure, with many sovereign chains involved and many connections. In this system each chain is relying on some of the others for its security, but there is no strict dependency.

Bi-directionality is cool and important, but always optional

The fact that Mesh Security allows for producer-consumer relationships to be seamlessly instantiated bi-directionally is a natural byproduct of its design.

In practice, Interchain Security v3 could also be implemented to be bi-directional (and by extension any form of ICS2B) — although enlarging the validator set on the Cosmos Hub this way should be done so that it prevents these added validators from participating in Interchain Security v1 or v2.

For Mesh Security, bi-directionality makes even more sense as what is shared is only security capital (delegations), and not validators.
However, bi-directionality is not enforced, and always optional. But at the same time there is no apparent downside in allowing it (when it makes sense), nor it adds any apparent system complexity as it only entails replication of the system in the other direction. Having bi-directional cross-staking could actually even help mitigate the risk of hostile takeover from one of the two chains, due to the existence of this interpendence on each other shared security capital.

The risks and challenges of Mesh Security

There are many risks and challenges with using Mesh Security. Some are explored below.

Conversion rates and oracle data

It is important to note that how cross-stake from a producer chain is converted to voting power on the consumer chain is ultimately to be determined by the consumer chain itself, and requires to be accepted “as is” by the producer chain. There is no strict requirement on how this conversion should be performed.

However, to provide conversion rates so that delegations from the producer chain can be converted into local voting power, one alternative that comes to mind is to use oracle data, behind some sort of TWAP mechanism — and/or the usage of a risk adjustment factor — to provide the final usable rate (so it’s more resilient to extreme price fluctuations). To retain full independence and have a mechanism to incentivize honest behavior, the oracle system could be integrated on the consumer chain itself and have local validators submit oracle data. The best system to this date is the x/oracle module, that is part of the classic-core repo from the Terra project, and it could be used as a basis for building the oracle system for Mesh Security.
However I still have some questions about potentially using this module.
What happens if a sufficient number of validators collude? Can they use manipulated pricing data to alter power distribution in a way that favors them and gives them an edge, up to giving them the ability to take control of the chain? Would this only happen when chain’s security is already compromised (absence of honest majority) and therefore is not really an — or rather the — issue? These are all open questions for me — some of them possibly due to lack of knowledge or understanding — that would require further exploration.

Moreover, updating the conversion rate for a token might trigger a cascade of voting power updates that could grow to be unmanageable and poorly performant. It is essential that how synthetic delegations are updated and the performance implications of this process are carefully evaluated.

Cross-delegators collusion

Another problem with Mesh Security is that it could allow delegators collusion from the producer chain to influence voting power distribution on the consumer chain, and potentially even spawn a validator themselves and perform an attack.

As also discussed by Sunny in its presentation, we could imagine to mitigate this risk by capping the total voting power that exogenous stake from a specific producer chain can be converted to, relative to the native stake. Then if more capital value from the producer chain is staked to the consumer chain than the nominal cap, the synthetic equivalent can be discounted at the conversion to correct and still allow for this additional “inefficient” capital to be staked (with diminished rewards for cross-chain delegators). This “overstaking” would then become a problem of the producer chain that is not allocating security capital efficiently, instead of a takeover risk for the consumer chain.
In practice, say A is the staking token of the producer chain, and B the staking token of the consumer chain. The cap on the consumer chain is set at 30% and there are 1000 token B staked. This means that the additional stake allowed from the producer chain is only of 300 synthetic token B. If token A is worth 5 token B, and the producer chain cross-stakes 100 token A on the consumer chain, the initial conversion would give 500 synthetic token B. However with the cap being 300, these 100 token A would be converted to synthetic token B at a conversion rate of 3 instead of 5, hence at a 40% discount. This would result in lower reward rates for the 100 token A, that would be counted as if they were 60. Diminished rewards might lead to potential undelegations from the producer chain, resulting in a more effective security capital allocation. And if this doesn’t happen, it would only result in diminished rewards for the delegations of the producer chain (while retaining the same level of risk of slashing), as there is no possibility for more stake from the producer chain to gain more voting power on the consumer chain than the cap. By adding stake, cross-chain delegators would only dilute other cross-chain delegators’ voting power.

It is worth noting however that preventing synthetic delegations above a certain ratio — with respect to native delegations — for individual validators could also be worth considering, as it might help preventing attacks with validators majorly relying on using synthetic stake. In practice a dual cap for the ratio of total native stake to exogenous stake as well as a cap on the ratio of native stake vs exogenous stake on each validator might actually be preferrable.

Validators conflict of interest

If validators overlap between two chains using Mesh Security, there is a potential risk of conflict of interest to arise and negatively impact one or both chains. As I stated previously, in my opinion the fact that validators sets across Cosmos chains overlap is fine, but more decentralization is always desirable. And the correlation of validators across chains is not necessarily needed for Mesh Security to work.

Coordination and Interoperability

Mesh Security will require efficient coordination and interoperability. Slashing events by themselves would represent a complex situation to handle if many chains are affected. Fortunately, Cosmos has IBC, and IBC is great. But IBC is also just a protocol, it is not “alive” by itself. When a message is sent from a blockchain to another, someone has to relay it. As we scale Cosmos, it seems to me many are assuming that the IBC infrastructure will expand accordingly to accomodate this scaling. This is especially true for complex IBC-based scaling mechanisms like Interchain Security v1, v2 and v3 and Mesh Security. Unfortunately, the reality is that the IBC infrastructure is barely on its feet as there is no sustainable incentivization mechanism currently deployed (but there is work). For Mesh Security (and for Cosmos as a whole) to work, a lot of IBC messages relaying will need to happen (and efficient delivery is important). And a lot of focus on sustainability and efficiency of IBC should be put for any initiative around the evolution of Interchain Security.