Comparing Replicated, Opt-in, and Mesh Security
The Cosmos Hub is leading the way in the development of shared security with the launch of Replicated Security. In our current thinking, Replicated Security stands alongside two other main varieties of shared security: Opt-in Security and Mesh Security. In this article, we will explore:
- How do these different varieties of Interchain Security compare to one another
- How the Hub is positioned with respect to Mesh Security
- How the Hub needs to capitalize on this position
- And how the Hub can bring exciting concepts from Opt-in Security to Mesh Security
Comparing Replicated, Opt-in, and Mesh Security
Replicated Security
In Replicated Security, every validator on the Hub (or almost every validator) runs a consumer chain. This provides very strong guarantees. Every Replicated Security consumer chain has exactly the same security as the Cosmos Hub. Since every validator is required to run every consumer chain, each consumer chain must be approved by Cosmos Hub governance. On the other hand, they do not need to assemble their own validator set. Since each consumer chain shares the same validator set, features such as synchronous IBC should be possible. This could allow for instant IBC transactions and features such as flash loans between Replicated Security consumer chains. There are currently some performance concerns about Replicated Security. Because Tendermint currently has a high-performance overhead of around $600/mo and each consumer chain requires each validator to run a separate Tendermint node, every consumer chain that is approved needs to be profitable enough to sustain this cost. As the performance of Tendermint improves, this will become less of an issue.
Opt-in Security will allow validators to opt into running consumer chains individually. This has two main benefits. First, if a validator does not feel that a consumer chain will be profitable to run, they do not need to run it. Second, it enables the permissionless launch of consumer chains without a governance proposal. However, it also has drawbacks. The security story is not as simple as in Replicated Security. As validators opt in and out, the security of a given consumer chain could fluctuate from day to day. Also, Opt-in Security consumer chains (along with Mesh Security consumer chains) are vulnerable to something called the “subset problem”. While the entire set of validators and delegators of the Hub may be considered secure, any given subset might be malicious. In an extreme example, if only one validator has opted in, they would control the entire chain. The subset problem can be mitigated by using fraud proofs which allow validators to be slashed on the Hub for producing invalid blocks, but the problem will always exist for liveness. A malicious subset of the Hub opting into a consumer chain will always be able to stop it without being punished. Opt-in Security really shines when it comes to launching consumer chains. Unlike Replicated Security, no governance proposal is required. And unlike Mesh Security, consumer chains do not need their own validator set. Using Opt-in Security on the Hub, consumer chains should be able to attract a very respectable level of security to their project with a single permissionless transaction.
Mesh Security
Mesh Security works a little bit differently in that it allows delegators to delegate to validators on other chains. The Cosmos Hub validator set would not be involved at all in running a consumer chain. If a validator on another chain commits a consensus violation, anyone delegating to it gets slashed. This design allows chains to increase each other’s security bidirectionally, which is why it’s called Mesh Security. Like Opt-In Security, Mesh Security has the subset problem and so needs fraud proofs to work securely. Unlike Replicated Security and Opt-in Security, Mesh Security requires consumer chains to have their own validator sets. This makes it less of an easy option for new chains launching, but may make it more attractive to chains that already have their own validator set.
The Hub’s position with respect to Mesh Security
A misconception exists that Mesh Security competes with the Hub. Nothing could be further from the truth. The Hub is very well positioned to participate in a security mesh. It has a very high stake, and so any mesh-secured chain that adds the Hub as a security provider will see a big increase in its total security level. In a Mesh Security world, the Hub’s default position is one of great success. However, there are two things that must be true for this success to be born out.
Users must have accurate information about security
First, users must have accurate information about how much security different blockchains actually have. Not much attention has been paid to this so far because currently, it is trivial to derive the security of a chain from its total stake. If a chain has $100m staked, then it will take ~$66m (⅔+) to control the chain and ~$33m (⅓+) to censor transactions or halt the chain. These numbers are so simple to derive that most people don’t even think about them. However, with Mesh Security, it is not that simple. A naive approach would be to simply sum up the staked tokens of all chains providing security to a given chain and consider that the total staked. But this does not take voting power into account and it is not accurate. We have created a mathematical model that does take all factors into account. It is important that block explorers and wallets use an accurate metric for security, since that will allow users to accurately assess the security level of chains using mesh security. We’ve created a javascript plugin that can be used by wallets and block explorers, and they should be encouraged to use it. Here’s an example. Try deleting the Hub as a Mesh Security provider and see how much the security drops!
The Hub must run Mesh Security
Second, and more importantly, the Hub must actually run Mesh Security. This is obvious but it needs to be discussed. Mesh Security is currently being developed as a CosmWasm app. Currently, the Hub does not run CosmWasm. I will discuss three possible solutions.
- Add CosmWasm to the Hub
This is the simplest and easiest solution. Doing this will make it so that the Hub uses the exact same Mesh Security implementation as every other chain, and will allow it to adopt improvements immediately. A note that there is a governance precedent that rejected CosmWasm on the Hub, see proposal #69. Considering the past event, a new proposal could still find resistance within the community.
2. Develop an alternate Mesh Security implementation in Go
This would be a large engineering effort and would duplicate a lot of the work that is already going into the CosmWasm implementation. The risk here is that the Go implementation falls behind the main CosmWasm implementation, putting the Hub at a disadvantage. There is a small possibility that the Go implementation would become the main implementation, but trying to fight this fight instead of building on the Hub’s advantages seems like a misallocation of effort. Perhaps other chains that don’t run CosmWasm could use this as well, but that doesn’t seem to benefit the Hub at all.
3. Run Mesh Security on a Replicated Security consumer chain
It could be possible to run Mesh Security written in CosmWasm on a Replicated Security consumer chain running CosmWasm, without the Hub itself needing to run CosmWasm. This would require a few changes to Replicated Security. This consumer chain would need to be a trusted consumer chain. It would need to have the ability to slash the stake of individual delegators by sending an IBC packet, with no additional verification. This is possible to build into Replicated Security but it will likely require some minor changes on the consumer side as well to send a slash packet instead of slashing validators directly. There is also the possibility that as Mesh Security evolves, this trusted consumer chain will need additional changes in Replicated Security, adding additional overhead.
Which of these options is best?
Option 1 is simple and accomplishes exactly what we need, although it may have some governance issues, and running CosmWasm on the Hub is indeed a big decision although it has been thoroughly tested in production at this point.
Option 3 is more complicated but lets us continue to use mainline Mesh Security with a few changes. However, changes that are made to Mesh Security may require changes to be made to the Replicated Security running the trusted Mesh Security consumer chain. This might be a lot more work than option 1.
Option 2 is by far the most amount of work and carries the risk of the Hub’s Go implementation falling behind mainline Mesh Security. There are benefits to a Go implementation existing, for example for other chains that do not want to run CosmWasm, or purely for the increased level of technical specification that having two implementations demands, but these do not directly benefit the Hub. Also, having multiple implementations of a decentralized protocol is not trivial. To my knowledge, neither Tendermint nor IBC have fully interoperable implementations in different languages.
As I alluded to above, one of the most exciting things about Opt-in Security is its ability to act as a launch pad for new Cosmos projects. New projects will be able to create a permissionless transaction establishing their project as an Opt-in consumer chain. Then Hub validators can opt in to validating these chains. Opt-in consumer chains will be able to permissionless launch a chain with a high level of security from a diverse validator using the Cosmos Hub.
Opt-in Security will be ready soon, but Mesh Security will likely take a little longer. The Hub can expand this permissionless chain launchpad to Mesh Security when it is ready. Mesh Secured chains will start with a permissionless transaction on the Cosmos Hub. This will allow Hub validators to opt into the new mesh-secured chain’s validator set, and allow Atom delegators to delegate to them.
The Hub is the best place to do this since new mesh-secured chains will be able to start off with a quality validator set and a high level of security. Once the chain is launched, it can go and connect to other Mesh Security chains.
About the Author:
Jehan Tremback is the product owner for the Cosmos Hub at Informal Systems, where he works on exciting new features for the Hub.
