BACK

BACK

Articles

Cosmos Hub: From Replicated to Partial Set Security

May 14, 2024

Cosmos Hub: From Replicated to Partial Set Security

Introduction

Since its inception, the Cosmos Hub has been dedicated to overcoming industry challenges, including issues like interoperability, security costs, and scalability. However, Cosmos’s reliance on the Replicated Security (RS) version of the Interchain Security model (ICS) unveiled significant shortcomings that acted as hurdles to achieving its objectives. Despite RS providing a baseline for security and interoperability, it also led to increased node costs and imposed constraints on validators, as well as limiting the flexibility of consumer chains. In response to these challenges, the introduction of Partial Set Security (PSS) emerged as a strategic solution. PSS represents a paradigm shift, introducing new features such as opt-in consumer chains, top-n chains, and customizable validator settings. This transition from RS to PSS signifies a concerted effort to address past limitations and propel Cosmos toward a future of enhanced security, flexibility, and ecosystem growth.


Overview of the Cosmos Hub

Cosmos Hub, one of the first chains of the wider Cosmos ecosystem, was deployed in 2019 to overcome major obstacles faced by blockchain networks, including low scalability, lack of interoperability, and poor usability. By allowing each blockchain to remain sovereign and trustlessly communicate with one another, the Cosmos Hub has broken down the barriers between multiple ledgers, earning it the name of the “internet of blockchains”.

The philosophy behind Cosmos is underpinned by modularity. This approach breaks down a blockchain into smaller, independent components that can be easily replaced, upgraded, or extended. To accomplish the aims of modularity and interoperability, the Cosmos Hub has pioneered three core pieces of technology:

  • Tendermint: a pre-constructed consensus engine
  • Cosmos SDK: a comprehensive software development kit
  • Inter-Blockchain Communication Protocol (IBC): a network communication protocol
 

These technologies coexist between the two layers of the Cosmos blockchain: the application layer and the consensus layer. The application layer is built with the Cosmos SDK, which can plug into compatible consensus engines, such as Tendermint, while the IBC module is built into Cosmos SDK, enabling blockchains to connect and transfer data. Taken together, these pieces allow for unique blockchain applications to be built with granular control and standard security. 

Cosmos Hub runs on a Proof-of-Stake (PoS) network where the token holders secure the blockchain by staking the network’s coin, ATOM. Besides validators, delegators can also engage in ATOM staking. The former participate in network consensus by operating validator nodes, while the latter delegates their ATOM to trusted validators for staking. 

A validator must accumulate enough stake, including both self-bonded and delegated ATOM, to become active and earn rewards for participating in consensus. Currently, the Cosmos Hub is secured by 180 validators ranked by their stake. The rate at which stakers can earn rewards for participating in network consensus and governance stands as of today May 13th at 16.68%.

Besides the attractiveness of modularity and high staking rewards, Cosmos offers a high transactional capability of up to 10,000 TPS, allows the launch of EVM-compatible chains and holds Total Value Locked (TVL) of nearly $3 billion


The Interchain Security model

The Interchain Security model (ICS) is an interchain service that allows validators on chain X (the provider chain) to use their staked coins on chain X to secure chain Y (the consumer chain), in parallel. To break this down: 

  • a provider chain is a blockchain that allows its validators to secure another blockchain with its stake, 
  • while a consumer chain is a blockchain that allows another blockchain’s validators to participate in its consensus.

By way of illustration, the Cosmos Hub allows its validators to use their staked ATOM to validate the Neutron chain. In this example, Cosmos is a provider chain, and Neutron acts as a consumer chain, while ATOM is kept as a validation tool on both chains. 

The current version of the ICS model relies on RS, where the entire validator set of the provider chain is used to secure consumer chains. This approach brings solid benefits including security, community governance, and interoperability. 

  • On the security front, relies on shared security that originates from the  Cosmos Hub, meaning that the security of the provider chain would be replicated on the consumer chain, such as Neutron.
  • When it comes to governance, since every validator is required to run every consumer chain, each consumer chain must be approved by Cosmos Hub governance. Thereafter, fostering democratic and representative on-chain governance via discussion forums and voting. 
  • Concerning interoperability, since each consumer chain shares the same validator set and is built using the Cosmos SDK, instant IBC transactions and interchain communication are possible.

Shortcomings of Replicated Security

Despite the mentioned benefits, this approach has several concerns. 

First of all, a large number of validators might be obliged to validate consumer chains they are not interested in, due to various factors such as on-chain activity and the level of competition between validators. 

Additionally, it is costly for small validators to secure additional chains due to resource requirements and operational complexities associated with the simultaneous management of stakes on various chains. This concern is only partially addressed through soft opt-out, which is a mechanism that allows small validators to opt-out from validating consumer chains. Soft opt-out may not provide sufficient flexibility for smaller validators to dynamically adjust their participation based on changing resource availability or economic conditions. 

Moreover, for the above reasons, the RS does not grant consumer chains the flexibility to select the level of security that they need initially and incrementally improve it as they grow their TVL. Pressure on consumer chains to prioritise validator rewards risks stifling innovation and creativity, leading to stagnation, reduced user engagement, and potentially diminishing validator rewards.

Last but not least, consumer chains need to undergo a voting process before they can launch. This involves validator voting to determine whether a chain is fit to enter the ecosystem, which can take several weeks, cause delays, and add an extra step to the process of launching the chain. This, in turn, can act as a barrier for the developers who wish to enter the Cosmos network and deprive the ecosystem of growth opportunities. 


Partial Set Security

As a solution to the aforementioned issues of RS, Partial Set Security (PSS) has been introduced, which allows for every consumer chain to be secured by only a subset of the provider validator set. To accomplish this, PSS introduces four main concepts including opt-in consumer chains, validator set settings, top-n consumer chains, and permissionless chain launch.

Opt-in consumer chains

With opt-in consumer chains, unlike with RS, validators can choose whether or not to secure a particular chain. This means that no validator is compelled to validate a given chain and can choose its set of chains based on individual metrics. Additionally, validators can choose a different commission rate for every consumer chain, therefore covering expenses on the consumer chains that they run without affecting their Cosmos Hub commission rate.

Validator set settings

Consumer chains can set up specific validator configurations to match their unique needs through the following features: 

  • Whitelists and blacklists: Consumer chains can choose to exclude certain validators, or propose to only include others (if they were to opt in).

  • Power cap: Consumer chains can impose a cap on the amount of power a large validator can migrate to their ledger. For instance, they could set it so that no validator could have more than 20% of the power on their chain, even if some validators were much larger than others.

  • Active set: A consumer chain can opt for a smaller active set compared to the Hub’s active set to improve performance via faster consensus and easier governance. 
 

Top-n consumer chains

Some consumer chains need to guarantee security levels that are much higher than others. These would most likely be those chains that have used RS to date. PSS facilitates this by the top-n feature. 

The top “n” percent of Cosmos Hub validators are automatically opted in the consumer chain. A top-n setting of 95% percent functionally mirrors the RS, which is what existing RS consumer chains, such as Neutron and Stride, will be migrated to.

Consumer chains can adjust the top-n as needed. For instance, 63% top-n has comparable security to 100%, yet only requires around the top 25 Hub validators to run the consumer chains (others can still opt in if they choose so). However, it is expected that the majority of new chains will launch as opt-in chains.

Permissionless launch

Consumer chains that opt-in will have the ability to launch without the current necessity of a governance proposal as mandated by Replicated Security. Once validators begin to opt-in, the consumer chain will be able to initiate operations. However, in the initial version, consumer chains will require clearance for launch by governance. This is a precautionary measure that aims to prevent the creation of spam consumer chains. Following the post-launch update, the database will be restructured to enable consumer chains to launch permissionlessly.

Reflection

PSS offers a solution to the issues with Replicated Security by allowing consumer chains to be secured by a subset of validators. Opt-in chains give validators a choice to secure specific chains and set commission rates, while validator set settings allow customisation such as whitelists/blacklists and power caps. Top-n chains ensure optimal security levels by including a predetermined number of validators and Permissionless launches enable chains to start operations without governance proposals, promoting flexibility while preventing spam chains.


Evaluating PSS 

Current State & Sentiment 

The concept of PSS was introduced at the beginning of 2024 to cover the shortcomings of RS and has been actively debated by the Cosmos community since then. 

On February 15th, under the Cosmos Hub Improvement Process (CHIP), the PSS cleared the spike phase and signaling phases, before being successfully voted in with 99.6% positive sentiment.

 

Rationale Behind the PSS Adoption

There are several reasons why the Cosmos community decided to adopt PSS. 

Choice: PSS allows validators to choose whether or not to secure a particular chain, unlike Replicated Security (RS) where validation is mandatory for all chains. This provides flexibility for the validator to reallocate resources to chains that align with its expertise and preferences while removing the unnecessary costs of validating sub-optimal ones.

Commission Rate Flexibility: Validators can choose different commission rates for each consumer chain it validates under PSS, thus covering expenses specific to those chains, without affecting their Cosmos Hub commission rate. This would not only allow validators to manage their resources more efficiently and cultivate fair compensation but also use their market share and established reputation to propose a competitive rate and secure more delegation. Commission rate flexibility benefits delegators as well because competition is poised to bring prices down, translating into attractive yields for users.

Top-n Feature: Assuming that consumer chains would strive to keep at least 50% of Cosmos Hub security, most of the validators would have the opportunity to validate the majority of the ledgers, while users will have the ability to make strategic tradeoffs between security and other variables such as yield and scalability.

Early opportunities: As the Cosmos Hub evolves, new use cases and markets will be brought on-chain by consumer chains. Permissionless launch would streamline this process and present validators and users with frequent and innovative candidates to choose from. This can be an opportunity for the community to identify promising consumer chains early on and capture new use cases, staking surfaces, and tokens for future rewards. 

Community Support: Besides three new consumer chains. including AetherEVM, Elys Network, and Lorenzo Protocol, being lined up to leverage PSS, the analysis of Cosmos’s X and the Hub Forum show strong community support for PSS. 


Mitigating Risks

Despite PSS bringing obvious benefits to the community, power cap constraints, variation in security levels, and permissionless chain launch introduce some risks. However, these risks can be mitigated.

Power Cap Constraints: Consumer chains can impose power caps on validators, limiting their influence within the chain. Validators with significant power may find their capabilities constrained, affecting their incentives to participate in these chains. However, this should not be a concern for a validator if the staking power is at the mid-spectrum.  

Security Level Variability: Top-n consumer chains determine the percentage of top validators from the Cosmos Hub. Validators securing these chains may face security risks if the top validators are not consistently participating or if the threshold is set too low, compromising the overall security of the chain. However, a validator can evaluate the chain and simply abstain from validation, hence mitigating security risks. 

Permissionless Launch Risks: While permissionless launch offers flexibility, it also poses risks of spam chains entering the network without adequate governance oversight. Validators may need to assess the security and legitimacy of newly launched chains before participating, potentially impacting their workload and resources. Arguably, this should not be a concern because spam chains will be quickly abandoned by both validators and users. 

Centralisation Risks: There is a risk that consumer chains will set settings to attract the biggest validators and exclude smaller ones, therefore establishing duopolies in chain validation. This could lead to several issues such as unhealthy commission rates, heightened node-side downtime risks, and so on. However, it is sensible to assume that leaving security in the hands of a few validators is suboptimal for consumer chains themselves. This is because these chains would impose their infrastructure to the same centralisation and downtime risks mentioned above. Additionally, it is in the chain’s interest to offer competitive rates to onboard more users and source liquidity.

What’s Next for PSS?

After the finalisation of the development stage, it has been announced that Informal Systems is planning to launch PSS to mainnet as a part of their 2024 Q2 Cosmos Plan.


Conclusion

PSS presents a robust solution to the limitations of RS by offering flexibility, customisation, and efficiency in securing consumer chains. With opt-in chains, customisable validator settings, and the top-n feature, PSS ensures optimal security levels while allowing for permissionless launches, fostering innovation and agility within the Cosmos ecosystem. The community’s endorsement of PSS aligns with Comsom’s strategic interests, providing opportunities for resource optimisation, revenue diversification, and community alignment. While risks exist, proactive measures and market dynamics mitigate potential drawbacks, thus making PSS a compelling choice for the broader Cosmos community.


**Architecture Decision Records (ADR) describing PSS can be accessed here.