<!-- omit in toc -->

CCV: Overview and Basic Concepts

↑ Back to main document

<!-- omit in toc -->

Outline

• Security Model
• Motivation
• Definition
• Overview
  • Channel Initialization
    • Channel Initialization: New Chains
    • Channel Initialization: Existing Chains
  • Validator Set Update
    • Completion of Unbonding Operations
  • Consumer Initiated Slashing
  • Reward Distribution

Security Model

↑ Back to Outline

We consider chains that use a proof of stake mechanism based on the model of weak subjectivity in order to strengthen the assumptions required by the underlying consensus engine (e.g., Tendermint↗ OPEN PDF, 1807.04938.pdf requires that less than a third of the voting power is Byzantine).

Background: The next block in a blockchain is validated and voted upon by a set of pre-determined full nodes; these pre-determined full nodes are also known as validators. We refer to the validators eligible to validate a block as that block's validator set. To be part of the validator set, a validator needs to bond (i.e., lock, stake) an amount of tokens for a (minimum) period of time, known as the unbonding period. The amount of tokens bonded gives a validator's voting power. When a validator starts unbonding some of its tokens, its voting power is reduced immediately, but the tokens are unbonded (i.e., unlocked) only after the unbonding period has elapsed. If a validator misbehaves (e.g., validates two different blocks at the same height), then the system can slash the validator's bonded tokens that gave its voting power during the misbehavior. This prevents validators from misbehaving and immediately exiting with their tokens, i.e., the unbonding period enables the system to punish misbehaving validators after the misbehaviors are committed. For more details, take a look at the Tendermint Specification and the Light Client Specification.

In the context of 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.

Similarly to the single-chain approach, when a validator starts unbonding some of its bonded tokens, its voting power is reduced on all chains (i.e., provider chain and consumer chains); yet, due to delays in the communication over the IBC protocol (e.g., due to relaying packets), the voting power is not reduced immediately on the consumer chains. A further consequence of CCV is that the tokens are unbonded only after the unbonding period has elapsed on all chains starting from the moment the corresponding voting power was reduced. Thus, CCV may delay the unbonding of tokens validators bonded on the provider chain.

Motivation

↑ Back to Outline

CCV is a primitive (i.e., a building block) that enables arbitrary shared security models: The security of a chain can be composed of security transferred from multiple provider chains including the chain itself (a consumer chain can be its own provider). As a result, CCV enables chains to borrow security from more established chains (e.g., Cosmos Hub), in order to boost their own security, i.e., increase the cost of attacking their networks.

Intuition: For example, for chains based on Tendermint consensus, a variety of attacks against the network are possible if an attacker acquire 1/3+ or 2/3+ of all bonded tokens. Since the market cap of newly created chains could be relatively low, an attacker could realistically acquire sufficient tokens to pass these thresholds. As a solution, CCV allows the newly created chains to use validators that have stake on chains with a much larger market cap and, as a result, increase the cost an attacker would have to pay.

Moreover, CCV enables hub minimalism. In a nutshell, hub minimalism entails keeping a hub in the Cosmos network (e.g., the Cosmos Hub) as simple as possible, with as few features as possible in order to decrease the attack surface. CCV enables moving distinct features (e.g., DEX) to independent chains that are validated by the same set of validators as the hub.

Versioning: Note that CCV will be developed progressively. This standard document specifies the V1 release, which will require the validator set of a consumer chain to be entirely provided by the provider chain. In other words, once a provider chain agrees to provide security to a consumer chain, the entire validator set of the provider chain MUST validate also on the consumer chain.

For more details on the planned releases, take a look at the Interchain Security light paper.

Definition

↑ Back to Outline

This section defines the new terms and concepts introduced by CCV.

• Provider Chain: The blockchain that provides security, i.e., manages the validator set of the consumer chain.

• Consumer Chain: The blockchain that consumes security, i.e., enables the provider chain to manage its validator set.

Note: In this specification, the validator set of the consumer chain is entirely provided by the provider chain.

Both the provider and the consumer chains are application-specific blockchains, i.e., each blockchain's state machine is typically connected to the underlying consensus engine via a blockchain interface, such as ABCI. The blockchain interface MUST enable the state machine to provide to the underlying consensus engine a set of validator updates, i.e., changes in the voting power granted to validators. Although this specification is not dependent on ABCI, for ease of presentation, we refer to the state machines as ABCI applications. Also, this specification considers a modular paradigm, i.e., the functionality of each ABCI application is separated into multiple modules, like the approach adopted by Cosmos SDK.

• CCV Module: The module that implements the CCV protocol. Both the provider and the consumer chains have each their own CCV module. Furthermore, the functionalities provided by the CCV module differ between the provider chain and the consumer chains. For brevity, we use provider CCV module and consumer CCV module to refer to the CCV modules on the provider chain and on the consumer chains, respectively.

• CCV Channel: A unique, ordered IBC channel that is used by the provider CCV module to exchange IBC packets with a consumer CCV module. Note that there is a separate CCV channel for every consumer chain.

The IBC handler interface, the IBC relayer module interface, and both IBC channels and IBC packets are as defined in ICS 25, ICS 26, and ICS 4, respectively.

• Validator Set Change (VSC): A change in the validator set of the provider chain that must be reflected in the validator sets of the consumer chains. Every VSC consists of a batch of validator updates provided to the consensus engine of the provider chain.

Background: In the context of single-chain validation, the changes of the validator set are triggered by the Staking module, i.e., a module of the ABCI application that implements the proof of stake mechanism needed by the security model. For an example, take a look at the Staking module documentation of Cosmos SDK.

Some of the validator updates can decrease the voting power granted to validators. These decreases may be a consequence of unbonding operations (e.g., unbonding delegations) on the provider chain. which MUST NOT complete before reaching maturity on both the provider and all the consumer chains, i.e., the unbonding period (denoted as UnbondingPeriod) has elapsed on both the provider and all the consumer chains. Thus, a VSC reaching maturity on a consumer chain means that all the unbonding operations that resulted in validator updates included in that VSC have matured on the consumer chain.

Background: An unbonding operation is any operation of unbonding an amount of the tokens a validator bonded. Note that the bonded tokens correspond to the validator's voting power. We distinguish between three types of unbonding operations:

• undelegation - a delegator unbonds tokens it previously delegated to a validator;
• redelegation - a delegator instantly redelegates tokens from a source validator to a different validator (the destination validator);
• validator unbonding - a validator is removed from the validator set; note that although validator unbondings do not entail unbonding tokens, they behave similarly to other unbonding operations.

Regardless of the type, unbonding operations have two components:

• The initiation, e.g., a delegator requests their delegated tokens to be unbonded. The initiation of an operation of unbonding an amount of the tokens a validator bonded results in a change in the voting power of that validator.
• The completion, e.g., the tokens are actually unbonded and transferred back to the delegator. To complete, unbonding operations must reach maturity, i.e., UnbondingPeriod must elapse since the operations were initiated.

For more details, take a look at the Cosmos SDK documentation.

Note: Time periods are measured in terms of the block time, i.e., currentTimestamp() (as defined in ICS 24). As a result, a consumer chain MAY start the unbonding period for every VSC that it applies in a block at any point during that block.

• Slash Request: A request by a consumer chain to slash the tokens bonded by a validator on the provider chain as a consequence of that validator misbehavior on the consumer chain. A slash request MAY also result in the misbehaving validator being jailed for a period of time, during which it cannot be part of the validator set.

Background: In the context of single-chain validation, slashing and jailing misbehaving validators is handled by the Slashing module, i.e., a module of the ABCI application that enables the application to discourage misbehaving validators. For an example, take a look at the Slashing module documentation of Cosmos SDK.

Overview

↑ Back to Outline

CCV must handle the following types of operations:

• Channel Initialization: Create unique, ordered IBC channels between the provider chain and every consumer chain.
• Validator Set Update: It is a two-part operation, i.e.,
  • update the validator sets of all the consumer chains based on the information obtained from the provider Staking module (i.e., the Staking module on the provider chain) on the amount of tokens bonded by validators on the provider chain;
  • and enable the timely completion (cf. the unbonding periods on the consumer chains) of unbonding operations (i.e., operations of unbonding bonded tokens).
• Consumer Initiated Slashing: Enable the provider chain to slash and jail bonded validators that misbehave while validating on the consumer chain.
• Reward Distribution: Enable the distribution of block production rewards and transaction fees from the consumer chains to the validators on the provider chain.

Channel Initialization

↑ Back to Outline

The CCV Channel initialization differentiates between chains that start directly as consumer chains and existing chains that transition to consumer chains. In both cases, consumer chains are created through governance proposals. For an example of how governance proposals work, take a look at the Governance module documentation of Cosmos SDK.

Channel Initialization: New Chains

The following figure shows an overview of the CCV Channel initialization for new chains.

The channel initialization for new chains consists of three phases:

• Create clients: Once the provider CCV module receives a proposal to add a new consumer chain with an empty connection ID, it creates a client of the consumer chain (as defined in ICS 2) and a genesis state of the consumer CCV module. Then, the operators of validators in the validator set of the provider chain must each query the provider for the CCV genesis state and start a validator node of the consumer chain. Once the consumer chain starts, the application receives an InitChain message from the consensus engine (for more details, take a look at the ABCI specification). The InitChain message triggers the call to the InitGenesis() method of the consumer CCV module, which creates a client of the provider chain. For client creation, both a ClientState and a ConsensusState are necessary (as defined in ICS 2); both are contained in the genesis state of the consumer CCV module. The genesis state is distributed to all operators that need to start a full node of the consumer chain (the mechanism of distributing the genesis state is outside the scope of this specification). Finally, the consumer CCV module initiates both the connection handshake (as defined in ICS 3) and the channel handshake (as defined in ICS 4).

  Note that at genesis, the validator set of the consumer chain matches the validator set of the provider chain.

• Connection handshake: A relayer (as defined in ICS 18) is responsible for completing the connection handshake (as defined in ICS 3).
• Channel handshake: A relayer is responsible for completing the channel handshake (as defined in ICS 4). The handshake consists of four messages that need to be received for a channel built on top of the expected clients. Note that the channel handshake is initiated on the consumer chain.
  • OnChanOpenInit: On receiving a ChanOpenInit message, the consumer CCV module verifies that the underlying client associated with this channel is the expected client of the provider chain (i.e., created during genesis).
  • OnChanOpenTry: On receiving a ChanOpenTry message, the provider CCV module verifies that the underlying client associated with this channel is the expected client of the consumer chain (i.e., created when handling the governance proposal).
  • OnChanOpenAck: On receiving the FIRST ChanOpenAck message, the consumer CCV module considers its side of the CCV channel to be established. Also, if a transfer channel ID was not provided in the governance proposal, the consumer CCV module initiates the opening handshake for the token transfer channel required by the Reward Distribution operation (see the Reward Distribution section).
  • OnChanOpenConfirm: On receiving the FIRST ChanOpenConfirm message, the provider CCV module considers its side of the CCV channel to be established.

Channel Initialization: Existing Chains

The following figure shows an overview of the CCV Channel initialization for existing chains.

The channel initialization for existing chains consists of three phases:

• Start consumer CCV module: Once the provider CCV module receives a proposal to add a new consumer chain with a valid connection ID, it creates a genesis state of the consumer CCV module. Then, the existing chain must upgrade by adding the consumer CCV module and initialize it using the CCV genesis state created by the provider. Once the consumer CCV module starts, it initiates the channel handshake (as defined in ICS 4).

• Channel handshake: A relayer is responsible for completing the channel handshake (as defined in ICS 4). The handshake consists of four messages that need to be received for a channel built on top of the expected clients (i.e., the clients used by the connection provided in the governance proposal). Note that the channel handshake is initiated on the consumer chain.

  • OnChanOpenInit: On receiving a ChanOpenInit message, the consumer CCV module verifies that the underlying client associated with this channel is the expected client of the provider chain.
  • OnChanOpenTry: On receiving a ChanOpenTry message, the provider CCV module verifies that the underlying client associated with this channel is the expected client of the consumer chain.
  • OnChanOpenAck: On receiving the FIRST ChanOpenAck message, the consumer CCV module considers its side of the CCV channel to be established. Also, if a transfer channel ID was not provided in the governance proposal, the consumer CCV module initiates the opening handshake for the token transfer channel required by the Reward Distribution operation (see the Reward Distribution section). Finally, the consumer CCV module makes a requests to the Staking module of the existing chain to replace its validator set with the initial validator set from the CCV genesis state created by the provider.

    Note that this is the same as the provider validator set when the governance proposal was handled.

  • OnChanOpenConfirm: On receiving the FIRST ChanOpenConfirm message, the provider CCV module considers its side of the CCV channel to be established.

• Transition to consumer chain: Once the validator set on the existing chain is replace by the initial validator set (from the CCV genesis state created by the provider), the existing chain becomes a consumer chain.

Note: For both new and existing chains, as long as the assumptions required by CCV hold (e.g., Correct Relayer), every governance proposal to spawn a new consumer chain that passes on the provider chain results eventually in a CCV channel being created. Furthermore, the "FIRST" keyword in the above description ensures the uniqueness of the CCV channel, i.e., all subsequent attempts to create another CCV channel to the same consumer chain will fail.

Note: For both new and existing chains, until the CCV channel is established, the initial validator set of the consumer chain cannot be updated (see the Validator Set Update section) and the validators from this initial set cannot be slashed (see the [Consumer Initiated

Excerpt (19991 of 32933 characters). Read the whole page on cosmos/ibc (ICS specifications) ↗