An overview of partial set security (Interchain Security 2.0)
Introduction to Interchain Security 2.0
Replicated security (or interchain security 1.0) allows anyone to launch a "consumer" blockchain using the same validator set as the "provider" blockchain by creating a governance proposal, and the first chains to become consumer chains of the Hub were Stride and Neutron. If the proposal is accepted, provider chain validators start validating the consumer chain as well. Consumer chains will therefore inherit the full security and decentralization of the provider. But the same teams have been working on Partial Set Security, or Interchain Security 2.0, which is expected to solve a few issues from v1.
Glossary
Provider Chain: The primary blockchain providing security and validator sets for consumer chains in an interchain network.
Consumer Chain: A blockchain within an interchain network that utilizes the security and validator sets provided by the provider chain.
Cross Chain Validation (CCV): The process by which validator sets from provider chains are used to secure consumer chains.
Replicated Security: A system allowing the launch of "consumer" blockchains using the same validator set as the "provider" blockchain. Consumer chains inherit security and decentralization from the provider.
Partial Set Security: An evolution of Interchain Security aimed at addressing issues from version 1.0, allowing each consumer chain to be secured by only a subset of the provider validator set.
CometBFT: A consensus algorithm (previously Tendermint) used in Cosmos blockchains.
ABCI/ABCI++ (Application Blockchain Interface): The interface between consensus and the application layer in a Cosmos blockchain.
IBC (Inter-Blockchain Communication): A protocol enabling communication and transfer of assets between interconnected Cosmos blockchains.
Consensus and CometBFT
First off, we need to understand the basics of how consensus is reached in the provider chain. Recall for there to be consensus, we must have agreement and finality:
Consistency: keeping the nodes in sync so local histories add up
Liveness: even in the event of outages or attacks, transactions are eventually processed
There are trade-offs to be made, and CometBFT based chains (previously Tendermint) favor consistency if needed. So in a regular situation, a user sends a transaction, where it sits in the mempool waiting for it to be processed. The block proposer (validator) is chosen in round-robin fashion such that validators are chosen with frequency in proportion to their voting power. It will then take that transaction and a bunch more from the mempool, bundle them together in a block and sign them. For more specifics on block commitment, see our previous post on block commitment here: https://www.imperator.co/resources/blog/tendermint-and-block-commitment.
All we need to know is that CometBFT is in charge of consensus, and is not concerned with the interpretation of transactions, that occurs on an application layer. There are at least two broad approaches to application-level concerns using blockchains:
1. Create an application-specific blockchain where everything that can be done is defined in the protocol.
2. Create a programmable state machine and push application concerns to a higher level, such as bytecode created by compilers interpreting higher-level languages.
Ethereum-like blockchains are part of the second category: only the state machine is defined in the on-chain protocol, which defines the rules of contract creation, interaction, execution, and little else.
A purpose-built or application-specific blockchain is different. There is no need to present a general-purpose, programmable state machine because application concerns are addressed by the protocol the developers create.
Finally, ABCI/ABCI++ is the Application Blockchain Interface, and is the interface between consensus (CometBFT) and the application itself. ABCI provides a socket for applications written in other languages. If the application is written in the same language as the CometBFT implementation, the socket is not used.
Cross Chain Validation
Consumer chain transactions are not executed on the provider chain. Validators are obligated to run a separate validator node for the consumer chain, once this chain has been approved through an on-chain governance process.
Using IBC protocol, packets are relayed to make sure the consumer chain knows which validators are securing the Cosmos Hub and how much voting power they have. At the same time, the consumer chains need to tell the provider chain when there is evidence of misbehavior so that validators can get slashed on their ATOM tokens on the Cosmos Hub.
In the context of Cross Chain Validation (CCV), the validator sets of the consumer chains are chosen based on the tokens validators bonded on the provider chain, i.e., are chosen from the validator set of the provider chain. When validators misbehave on the consumer chains, their tokens bonded on the provider chain are slashed. As a result, the security gained from the value of the tokens bonded on the provider chain is shared with the consumer chains.
Each chain that is part of the interchain secured network contains either a provider or consumer CCV module which is in charge of the following steps:
After proposal passes, the provider chain creates a light client on the consumer chain which relayers use to initialize the connection
Relayers then create the channel which is used for CCV
If a validator on the provider chain changes its voting power, this changes need to be communicated to all consumer chains
If a validator misbehaves on the consumer chain, the provider chain needs to be informed so that it can slash a portion of the staked atom
Consumer chains can have a native token that gets paid out as a block reward. At each block, a fraction of the block rewards is transferred to the consumer’s CCV module, which are then transferred to the distribution module on the hub through IBC token transfer, which then distributes the tokens to validators and delegators
For cross chain validated chains where we have a provider and a consumer chain, the transaction point of view for the consumer chain is depicted below. Users send signed transactions on the consumer chain, transactions go to mempool via ABCI, dedicated nodes (those additional nodes per validator that had to be initiated after the approval) take a bunch of them, communicate with CometBFT via ABCI, Comet performs all consensus logic, a block is executed in 7 seconds and it is finalized. Then, the new state of machine is communicated via ABCI and it moves on. Block rewards are accrued in distribution module, and are sent periodically to provider chain via IBC.
Additional steps only occur for:
IBC package sent form provider to consumer if a validator VP changes
This takes place at a block level; if I stake to 100 validators in 1 block and a second user stakes to 100 same validators, only 100 updates will go through to the consumer chain.
If a validator misbehaves on consumer chain -> IBC package to provider chain
Additional extraordinary changes (consumer chain wants to leave and become a standalone chain)
Partial set security
Doing a quick recap, we’ve refreshed how consensus is met, how application and consensus talk to each other, how Cosmos chains talk to each other, how cross chain validation works and how replicated security works. Thus, we have all the ingredients needed to learn how partial set security works.
Despite the great amount of advantages the Interchain Security v1 brings (value accrual for the Hub, easily launch a new chain, inherit hub security), it also has a major drawback: an extra cost for validators which might not want to validate a specific consumer chain. And in the current version of replicated security, all validators must run an additional node (with the exception of those validators allowed to opt out through the soft opt-out feature).
Partial set security tries to solve this problem, as it allows for every consumer chain to be secured by only a subset of the provider validator set. What is explained below is a first iteration of PSS, and future versions might vary.
A new parameter N is introduced for each consumer chain to specify, and this means that the top N% of the providers voting power has to secure the consumer chain. Those outside of that N% can opt in if they want. In particular, we can define two types of consumer chains:
"Top N" consumer chain if it has joined with N != 0. More specifically, it has to take values between 50 and 100.
"Opt-in" consumer chain otherwise (only secured by validators that have opted in), with N = 0.
In this specific case, the consumer chain can whitelist/blacklist specific validators, and set a power cap as well.
In the current version it is set to be permissioned to avoid spam.
Additionally, there’s a discussion on how to enable a permissionless deployment of new consumer chains, where a main issue is “chain squatting”, where someone “starts” a bunch of consumer chains just to reserve the chain IDs.
Conclusions
After doing an overview of Interchain Security 1.0 and 2.0, we see that onboarding of new consumer chains might be easier, since proposals are more likely to pass if not everyone is forced to validate. Additionally, smaller validators are not forced to validate chains anymore if they do not want to.
On the other hand, a consumer chain does will not receive the same economic security as with Replicated Security, unless it is a Top N chain with N > 95%. But different use cases can have different requirements, and with the specific parameters such as whitelisting for opt-in consumer chains, a set of locally close nodes can be chosen for instance, or the other way around.
Currently, each new consumer chain costs ~$513k yearly (avg cost per node = $250 per month) so $250*12 months * 171 validators = $513k yearly. We're taking into account 171 validators because of the feature "soft opt out". Up until today, according to data from Numia, we’ve seen:
$31.5k monthly revenue from Stride. Extrapolating to 12 months: $378k yearly revenue to the Hub.
$5.7k monthly revenue from Neutron. Extrapolating to 12 months: $69k yearly revenue to the Hub.
That means that the validators are running at a cost of -$579k yearly overall. However, that value can be reduced with partial set security via top N validators. We present a small simulation of the validator cost per year in each feature with different values.
With those numbers, and new potential chains being added as consumer chains, we might be able to see a more sustainable revenue for the Hub. A possible candidate would be Noble, which is running under Proof of Authority with a total of 20 validators. It could easily become an opt-in consumer chain with 20 validators, and additional nodes could join if they wish to.
It sure is a step on the good direction, and we’re excited to see new consumer chains joining the space!