Den

State Pruning

Here are four strategies for pruning state. These strategies apply only to state and do not apply to block storage. A node operator may want to consider custom pruning if node storage is a concern or there is an interest in running an archive node.

everything: Prune all saved states other than the current state.
nothing: Save all states and delete nothing.
default: Save the last 100 states and the state of every 10,000th block.
custom: Specify pruning settings with the pruning-keep-recent, pruning-keep-every, and pruning-interval parameters.

Sync Option

Historic Data	Quicksync	State Sync	Blocksync
Minimal	✅	✅
Moderate	✅
Full	✅		✅

For operators interested in bootstrapping a pruned node, either Quicksync or State Sync would be sufficient.

To enable state sync, visit an explorer to get a recent block height and corresponding hash. A node operator can choose any height/hash in the current bonding period, but as the recommended snapshot period is 1000 blocks, it is advised to choose something close to current height - 1000.

Replicated Security

Replicated Security is a shared security model. The Cosmos Hub will be able to offer security to new projects launching as Hub-secured consumer chains. The Consumer Chain is a blockchain that leases security from the Hub. This means that the entire Cosmos Hub validator set is required to validate a consumer chain. So the Cosmos Hub Validator Set is “Replicated” on the Consumer Chain, providing security. For using this service, the Consumer Chain shares revenue with the Hub. 📄 The consumer chain can also allocate a portion of their native token inflation to the Cosmos Hub validators and delegators, as “continuous airdrops” 📄

the Cosmos Hub Validator Set is ‘’Replicated” on the Consumer Chain, providing security. 📄

With Replicated Security the Cosmos Hub will give birth to the Atom Economic Zone. A Consumer Chain can distribute revenues through: Transaction Fees - Token Inflation - Application Fees Transaction fees are generated by the Consumer chain activity, the % distributed to Atom delegators is by default 25%, but it can be increased and is subject to governance 📄

Replicated Security offers a potential solution to the chicken-or-the-egg problem of starting a new blockchain — a blockchain’s security usually derives from validators who need to hold a project’s native token to secure the network. If that token is cheap, as it often is when a project begins, a malicious actor can potentially gain control of the new blockchain at a relatively low cost.📄

Using the Inter-Blockchain Communication Protocol (IBC), the provider chain sends a series of messages to the consumer chains’ consensus engine (Tendermint). These messages will notify the consumer chain of the validators participating in its validator set as well as the share of voting power that these validators obtained by staking on the provider chain. In exchange, the provider chain receives a percentage of the gas fees from the consumer chain as part of a flexible security agreement. As with any Proof-of-Stake (PoS) consensus mechanism, the Cosmos Hub’s native validators are required to stake ATOM tokens and risk having their stake slashed in the event of misbehaviour on a consumer chain. 📄

This revenue will be shared with #ATOM delegators/validators. So the Atom delegators will not only benefit from getting ATOM staking rewards, but also will receive additional revenue from consumer chains using Hub security. These will be claimable as ordinary staking rewards 📄

Onobard Consumer Chain

Submit an AssignConsumerKey transaction on the Cosmos Hub Run the consumer chain binary at the spawn time.

Addresses

BIP-32 (seed is usually created from a 12- or 24-word mnemonic)
A single seed can derive any number of PrivKeys using a one-way cryptographic function.
A PubKey can be derived from the PrivKey.

Keys

	Address length in bytes	Public key length in bytes	Used for transaction authentication	Used for consensus
secp256k1	20	33	yes	no
secp256r1	32	33	yes	no
tm-ed25519	not used	32	no	yes

AccAddress - identifies users (the sender of a message).
ValAddress - identifies validator operators.
ConsAddress - identifies validator nodes that are participating in consensus.

Validator nodes are derived using the ed25519 curve. Address construction algorithm is defined in ADR-28 (opens new window) Reference

valconspub address could be converted to valoper address using Cosmos SDK

package main

import (
	"fmt"
	"os"

	sdk "github.com/cosmos/cosmos-sdk/types"
	"github.com/cosmos/cosmos-sdk/types/bech32"
)

func main() {
	// Check if a command-line argument was provided
	if len(os.Args) < 2 {
		fmt.Println("Please provide a consensus public key as a command-line argument.")
		os.Exit(1)
	}

	// Get the consensus public key from the command-line argument
	consPubKey := os.Args[1]

	// Decode the public key
	_, bz, err := bech32.DecodeAndConvert(consPubKey)
	if err != nil {
		panic(err)
	}

	// Convert to a ValAddress
	valAddr := sdk.ValAddress(bz)

	fmt.Println(valAddr.String())
}

Validator operations

Slashing conditions

If a validator misbehaves, their delegated stake is partially slashed. Two faults can result in slashing of funds for a validator and their delegators:

Double signing: If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, and if chain A and chain B share a common ancestor, then this validator gets slashed by 5% on chain A. Downtime: If a validator misses more than 95% of the last 10,000 blocks (roughly ~19 hours), they are slashed by 0.01%.

Unbonding

If you wish to stop delegating all together, the Cosmos network enforces a 21 day period for your ATOM to unbond. In that period, you will not be earning interest on your unbonding ATOM and will not be able to withdraw them.