V9 Lambda upgrade (with Replicated Security)
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 going forward we refer to it as Replicated Security.
Changes to this proposal
This proposal went onto the governance forum in mid-December. Since that time, we have made one change to the protocol. In response to the only high-severity finding in the Informal audit report, and feedback from the community, we have made it so that the slashing and tombstoning of validators for offenses on consumer chains must be approved by a governance vote. This will have a very minimal impact on the operation and security of consumer chains while protecting the Cosmos Hub from possibility of an attack by a rogue consumer chain.
This governance gating is temporary until the Cosmos Hub is able to cryptographically verify proof of double signing in an upcoming release of Replicated Security. This does not give governance the ability to slash validators arbitrarily, but rather to approve slash packets that have already been transmitted from a consumer chain.
Summary
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.
The ATOM economic zone
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 a smart-contracting platform, an AMM, several liquid staking providers and others have expressed interest in using 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.
Onboarding a consumer chain
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.
Offboarding a 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.
FAQs
How will the community ensure the quality of the consumer chains?
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.
Why would a Cosmos Hub validator want to run a consumer chain?
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.
How should validators think about revenues and costs?
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.
Can the validators stop validating a consumer chain?
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.
What security problems could a malicious consumer chain cause?
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, where a consumer chain attempts to slash every validator on every validator on the Hub at once by falsely sending packets claiming that the validators equivocated (double signed) on the consumer chain. To prevent this, slashing for equivocation on consumer chains must additionally go through a governance process before the validator is actually slashed. This is an extra layer of safety, and will have very minimal effects on consumer chains (the only concrete effect is that they will need to set an IBC parameter known as the “trusting period” to 5 days). In the next version of Replicated Security, the Cosmos Hub will be able to verify equivocation evidence automatically, and we can remove the governance gating.
Another potential issue is malicious jailing, where a consumer chain attempts to jail every validator on the Hub at once by falsely sending packets claiming that the validators had downtime on the consumer chain. However, these jailing packets are throttled, so that only one percent of the Hub validator power can be jailed per hour. Combined with the fact that jailing only lasts 10 minutes, it will not be possible for a malicious consumer chain to cause anything worse than transient disruption.
It should also be noted that the parameters around downtime jailing (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.
How was the correctness of the Replicated Security ensured?
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:
-
Governance gating of slashing – Makes it so that slashing a validator for equivocation (double signing and related attacks) on a consumer chain must be ratified by Hub governance. As a result, an attacker that compromises a consumer chain cannot jail all the Cosmos Hub active validators at once and replace them with its own validator set, since the obvious fraudulent slashes will be voted down.
-
Jail packet throttling – makes it impossible to jail more than 1% of the power on the Cosmos Hub per hour. 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 has provided continuous security feedback, and has conducted an audit
An incentivized testnet was also run for 4-5 weeks (Game of Chains) and findings were analyzed.
