EDIT: Changed release name from “V8 Rho” to “V9 Lambda” due to the V8 release now being a bugfix happening prior to V9.
This proposal is a draft and we will be modifying and clarifying it according to feedback received here before putting it on chain.
Terminology note: Interchain Security is the name for a family of protocols. The feature being discussed here is in this family, but more accurately termed “Replicated Security”. In the past it has been referred to as Interchain Security v1, or ICS, but in this document we will refer to it as Replicated Security.
Note: When this proposal goes on chain, it will also include details about other small changes and bugfixes coming in Rho. They are not incorporated in this forum post, since its purpose is to discuss Replicated Security.
The Cosmos Hub is upgrading its security system with a new feature called Replicated Security. This will allow the Cosmos Hub to provide its strong security to other blockchains, which are called “consumer chains”. The cost to censor or control a consumer chain with an economic attack is the same as the cost to censor or control the Cosmos Hub itself. This means that consumer chains can benefit from the Cosmos Hub’s security without having to maintain their own validator sets.
Replicated Security works through the IBC (Inter-Blockchain Communication) protocol. Consumer chains receive periodic IBC packets containing the up-to-date validator set of the Cosmos Hub. They use this information to update their own validator sets, effectively replicating the Cosmos Hub’s validator set across all consumer chains. This means that the Cosmos Hub’s validators can validate multiple blockchains at once with the same stake.
In exchange for this service, consumer chains are expected to send a portion of their fees and inflation to the Cosmos Hub validators and delegators. These tokens will then be included as part of the Cosmos Hub’s staking rewards.
It is anticipated that consumer chains using Replicated Security will collaborate closely in an “ATOM economic zone”. This is expected to have a snowball effect, with the Cosmos Hub securing a growing group of high-value decentralized protocols. Already, some prominent projects such as liquid staking providers, a smart-contracting platform, an AMM and one of the world’s largest stablecoin issuers are planning to use Replicated Security from the Cosmos Hub.
Replicated Security can also be used to further the cause of “Hub minimalism”. Any new features to the Hub, even if they are core to the Hub’s functionality, can be launched as consumer chains. This allows the Hub to scale better and separate release cycles, enabling faster deployment of new features.
This governance proposal will not launch any consumer chains on its own. Instead, it will only add the necessary code to the Cosmos Hub to enable Replicated Security. In order to launch, each consumer chain must submit their own governance proposal to be voted on separately.
It is expected that before launch, a consumer chain will have participated in a Cosmos Hub Replicated Security testnet, conducted their own testnets, and undergone an audit by reputable auditors.
Once a consumer chain proposal passes, Cosmos Hub validators can begin running the consumer chain and receiving rewards. The chain will only start if more than ⅔ (by power) of the Cosmos Hub validators decide to run the consumer chain.
Once the consumer chain is running, validators can be slashed and jailed for consensus faults such as downtime and double signing on the consumer chain.
At any point in time, ⅓ (by power) of the Cosmos Hub validators will be able to stop running the consumer chain at once: the chain will halt, and none of them will be slashed for downtime.
The offboardings of consumer chains will have strong social norms to protect both sides, and any kind of forceful exit will only be coordinated in extreme cases such as protocol failures or attacks.
For normal cases, a separate governance proposal will be made to remove a consumer chain, which will allow Cosmos Hub validators to stop running it.
First, this proposal by itself does not start any consumer chains. Each consumer chain will need to be confirmed in a separate proposal. In other words, if you support Replicated Security but only want consumer chains that meet very high standards, it would be appropriate to use your “No” vote for the proposals of consumer chains that do not meet this standard.
Second, if more than ⅓ of the Cosmos Hub validators do not want to run a consumer chain, it will not run, regardless of how the governance vote went. This applies both to the start of the consumer chain, and continues to apply throughout its life.
For the avoidance of doubt, no validator will ever have to run, or will be slashed by a consumer chain which has not first been approved by governance, and then “accepted” by ⅔ of the validators intentionally choosing to run the consumer chain code.
Replicated Security is a long awaited feature that will put the Cosmos Hub at the center of a constellation of valuable ATOM-aligned consumer chains. The consumer chains who will be introducing proposals to launch over the next year are some of the most highly-anticipated projects in the Cosmos space.
Replicated Security incorporates some fee-split mechanisms where a percentage of the value-captured by each consumer chain is sent to the Cosmos Hub validators and delegators.
Over time the fees may be raised as the value of being in the exclusive set of Cosmos Hub consumer chains is recognized, or perhaps lowered as validators improve their infrastructure and practices to be able to spin up new consumer chains more cheaply.
Over the long-term, Cosmos Hub validators and delegators may also consider a possible appreciation of their staking rewards as replicated security establishes itself as an important value-capture mechanism for ATOM.
In any case, governance will need to look at each consumer chain separately and decide whether the fee split makes sense for the consumer chain in question.
There are multiple ways a consumer chain could remunerate the Cosmos Hub validators
Transaction fees: By default, 25% of the consumer chain fees will be distributed to the provider chain. This number can be set differently for each consumer chain. Note that validators also have control over the minimum fee they are willing to receive.
Token inflation: If the consumer chain has a token, they can allocate a portion of the inflation to the Cosmos Hub validators and delegators (in other words, “continuous airdrops”).
Application fees: If the consumer chain doesn’t have a token, a percentage of the swap fees, usage fees etc. can be distributed to the provider chain as well.
Each consumer chain will be responsible for putting up a governance proposal outlining a commitment to use a combination of these revenue streams to compensate the Cosmos Hub community for the replicated security service.
On the expense side, the hardware costs of running a new chain may range from $100 to $1000 based on the chain requirements and the technical setup selected by the operators. Informal Systems will be working with validators during 2023 to analyze resource usage and recommend cost-effective validator setups.
Another important component of the expense of running a chain is staying on top of upgrades and governance. For consumer chains upgrades, Hypha Coop and Informal Systems will establish a regular and predictable cadence of upgrades to each consumer chain to minimize time spent by validators. For consumer chain governance, Cosmos Hub validators will not need to participate in governance of any consumer chains, since they have their own governance mechanisms built.
If it turns out that a given consumer chain is no longer worth validating because it is unreasonably taxing on validator infrastructure, or because it does not have high potential for future growth, then it can be stopped by a governance proposal.
In the worst case scenario, such a low-performing consumer chain can be stopped by ⅓+ of the validators simply turning off their nodes. As discussed above, in this scenario, no validator will be slashed for downtime.
The protocol design of Replicated Security currently assumes that consumer chains are audited before they are approved for launch. Reputable independent auditors are expected to conduct these audits. Before approving any consumer chains, governance voters are encouraged to review the audit findings. Auditors of consumer chains are encouraged to include a section in their reports that details the code’s adherence to the correct Replicated Security protocol.
However, we have also taken the following steps to limit the damage that a malicious consumer chain could cause in several scenarios.
One potential issue is malicious slashing, in which a consumer chain sends instructions to the provider chain to unfairly slash validators. To prevent this, we have included a “slash throttle” that limits the number of validators that can be slashed at once, reducing the potential harm to the Cosmos Hub’s consensus. While a malicious consumer chain could still attempt to unfairly slash a few validators, this could be reversed through governance. As noted above, this will only need to come into play if the Cosmos SDK capabilities system has been compromised, and so is a last line of defense.
It should also be noted that the parameters around downtime slashing (e.g. how long a validator can be down on a consumer chain before being slashed) cannot be modified by a consumer chain’s governance. These parameters will be configured to be more lenient on consumer chains than on the Cosmos Hub.
Another potential issue is the misuse of validator keys. Validators can choose to use the same private key on both the provider and consumer chains, but this exposes them to the risk of their key being misused by a malicious consumer chain. To avoid this, validators can assign a different key for each consumer chain, which will prevent any potential misuse of their key.
Finally, the ability for Cosmos blockchains, including consumer chains, to use fully custom binaries could potentially be used to harm the underlying infrastructure. For example, a Cosmos chain binary could hypothetically erase the hard drive it was on. However, validators use virtualization technologies that allow them to run a different virtual machine for each chain, including consumer chains. This will prevent any harm to the underlying hardware.
Overall, while malicious consumer chains pose security risks, we have implemented measures to limit the potential damage they could cause.
The Cosmos Hub team at Informal Systems used a wide variety of approaches to ensure the correctness and security of the Replicated Security module. It was then audited by the Model Based Testing team at Informal, as well as several other teams.
Confidence in the correctness was increased of the ICS code through various testing approaches:
- Unit tests are useful for simple standalone functionality, and CRUD operations.
- End to End tests utilize the IBC Testing Package, and test functionality that is wider in scope than a unit test, but still able to be validated in-memory, i.e., code where advancing blocks would be useful, simulated handshakes, simulated packet relays, etc.
- Differential testing is similar to e2e tests, but they compare the system state to an expected state generated from a model implementation.
- Integration tests run true consumer and provider chain binaries within a docker container and are relevant to the highest level of functionality. Integration tests use queries/transactions invoked from CLI to drive and validate the code.
Worst-case scenarios circuit breakers were added to ensure the stability of the Cosmos Hub:
- Slash packet throttling – makes it impossible to jail more than x% (probably between 1-5%) of the power on the provider per hour. As a result, an attacker that compromises a consumer chain cannot slash and jail all the Cosmos Hub active validators at once and replace them with its own validator set. For more details, see github issue.
- Unbonding liveness – makes it impossible for un-delegations to never complete (which would result in users never getting their staked Atoms back).
Several audits were completed with multiple ecosystem partners:
- Protocol audit performed by the Apalache team at Informal Systems
- IBC audit performed by the ibc-go team at Interchain
- Informal Systems Audits team is providing continuous security feedback, and will conduct the final audit once the code is stable
An incentivized testnet was also run for 4-5 weeks (Game of Chains) and findings were analyzed.