Kusama Documentation

Kusama Introduction

 

Kusama (KSM) is referred to as a canary network to the Polkadot blockchain. Just as a canary signals potential danger in a coal mine, Kusama is built to live as a test-bed for Polkadot’s innovations and developments before they go-live, to signal any potential pitfalls. 

 

Kusama is described in the words of Dr. Gavin Wood, pioneer of the two projects, 

 

“It is an early, unaudited and wholly experimental pre-production trial network, designed to help understand how the various cutting edge technologies introduced in areas including governance, staking and sharding work under “real” economic conditions.”

 

This means that while Kusama and Polkakdot share the same DNA, they are fundamentally different entities. Kusama was originally soft launched in 2019, beginning as a Proof of Authority (PoA) controlled by a small number of validator nodes run by the Web3 Foundation. This centralized control lasted long enough to get at least 50 to 100 validators bonded and ready to take over the network. The transition from a centrally controlled PoA network to the decentralized network resulted in the launch of Kusama’s Genesis Governance apparatus and enablement of the Nominated Proof of Stake (NPoS) staking system. Today, Kusama is highly decentralized with 900 validators

 

Kusama is pioneering interoperability through building a network which supports a constellation of independent blockchains. These self-sovereign blockchains are referred to as parachains, and will be discussed further in this documentation. The Relay Chain acts as the central backbone of the Kusama network. Parachains create blocks of transactions which are sent to validators operating on the Relay Chain. These validators confirm that the blocks can be added as a permanent addition to the ledger. The result is that all parachains enjoy the same level of rigorous security guarantees. 

 

Kusama is enabling developers to launch application specific blockchains (parachains) tailored to their specific needs. These custom blockchains are designed to be interoperable with one another, allowing for seamless cross-chain communication and transfers of value. Communication is enabled by Cross-Chain Message Passing (XCMP), while transactions take place across bridge parachains in the network. Kusama operates a sharded blockchain model in which transactions are processed in parallel rather than sequentially, vastly improving the number of transactions per second. 

 

The Kusama project was pioneered by Dr. Gavin Wood, a co-founder and former CTO of Ethereum, architect of the Solidity programming language and author of the first formal specification of a blockchain, the Yellow Paper. Kusama is the network for testing, iterating and experimenting with features that may or may not make it onto the main Polkadot chain. While Dr. Wood’s groundbreaking Solidity language laid the foundation for the use of custom smart contracts on the Ethereum blockchain, Kusama is going a step further by allowing any developer the ability to create their own custom blockchain. 

An Overview of Kusama’s Network Architecture

 


(Source – Polkadot — An Early In-Depth Analysis — Part One — Overview and Benefits by Kevin Sekniqi)

Fast Facts 

Token ticker: KSM

Inflation: 10% (the year of network launch)

Annual return (approx): >13%

Number of validators as of May 2021: 900 

Token unbonding period: 7 days 

Quick start guide: How to stake on Kusama

Step 1: Generate Stash and Controller accounts.

 

This step can be done using a Ledger hardware wallet, or the Polkadot extension. Once you create your account, within settings you can change the address format of your account to Kusama. 

  1. Stash Account is a cold wallet that holds funds. It decides how much funds are bonded and has its stored funds bonded to a Controller Account.
  2. Controller Account acts on behalf of the Stash Account to nominate and validate. It also sets preferences such as payout accounts and commission, and acts as signing accounts that dictates governance. 

 

Step 2: Bond Tokens via Polkadot-JS UI 

  1. Selecting the amount you wish to bond 
  2. Choose payment destinations for reward distribution, such process will be executed with the Controller Key while the tokens will be bonded in Stash key
  1. If choosing “Stash account (increase the amount at stake)”, reward will be compounded, bonded and hence subject to 28 days of bonding period
  2. If choosing “Stash account (do not increase the amount at stake)”, “Controller account” or “Specified payment account” for payment destination, reward will not be bonded and will be liquid
  1. Once bonded, staked principal will be subject to 28 days of bonding period

Step 3: Nominate a validator via Polkadot-JS UI

  1. A nominator can nominate up to 16 validators 
  2. Once selected validators, nominations will be active in the next era, which will be the period when validators are elected for block production. 
    1. Only the elected validator and its pool will receive rewards

Step 4: Reward Distribution

  1. Reward is distributed to validators in each era (~24h) 
  2. Equal block rewards are paid to validator pools regardless of total amount staked in the individual validator pool, meaning pools with less stake will generally pay more to the nominators than pools with more stake. A pool is the term for a validator and its nominators. 
    1. A percentage of the total reward from Blockdaemon’s validator pool is paid to Blockdaemon as commission.
    2. The remainder is paid proportional to the amount staked by nominators.
  3. Reward compounds or not
    1. If you choose payment destinations specified in step 2.b.i, rewards are compounded and subject to a 7 day bonding period. 
    2. If you choose payment destinations specified in step 2.b.ii, rewards are not automatically compounded, but such settings can change at any point and time. 

Step 5: Claiming rewards via Polkadot-JS UI (manual reward trigger and unbond)

  1. Rewards are claimed and distributed to nominators by the Blockdaemon team once a week.
    1. You will be able to self claim your rewards more often by using the polkadot-js UI. You will be responsible for paying the transaction fees for the claim, if done this way.
    2. If you choose to compound reward in step 2.b.i, the selected amount of reward will be subject to a 28 days unbonding period, during which the unbonded KSMs cannot be transferred nor accrue staking rewards.

What is a staking proxy account? 

With the controller account’s permission, a staking proxy account can sign for the controller account in staking and governance votes but not transfer funds. At any time the controller account can replace its staking proxy account. 

 

Polkadot era rewards are validator proportional, not stake proportional. By staking with us, you don’t have to set Blockdaemon as a proxy. Where Blockdaemon is designated as a staking proxy for you, we apply best practices to balance nominations efficiently with the intent to maximize your rewards. Blockdaemon provides no guarantees on rewards earned through its best efforts.

Key features of Kusama

Parachains

Parachains are the key to Kusama’s scalable, multichain architecture. The introduction of parachains on Polkadot’s mainnet represents the fifth and final phase of Polkadot’s launch. As Kusama is the testbed for new Polkadot features, it will support parachains on its network first. Kusama will test that the parachain logic works on a decentralized network, by successfully executing an auction involving crowdloans and hosting at least one functional parachain. An auction is necessary to connect parachains to the network by leasing a slot on the Relay Chain. These auctions will be hosted on Kusama for testing and optimization. 

 

A parachain must inhabit an available parachain slot in order to be added to Kusama. There are a limited number of such parachain slots available in the network and it is possible that only a few slots may become unlocked every few months to host parachains. It is hoped that there will eventually be 100 parachain slots available. Occupying a slot is necessary to guarantee that blocks produced will be included at every Relay Chain block. Who gets to occupy a parachain slot is determined by a parachain auction

 

As of 1st June 2021, Kusama parachains are set for launch soon, in advance of the Polkadot parachain rollout. 

What is a parachain auction? 

A parachain auction is a variation of a candle auction, where bidders submit increasingly higher bids until an amount of time has elapsed and a winner is declared. A team bids on at least one range of 1 – 8 lease periods (each period representing 6 weeks) and the amount of KSM tokens they want to lock up for the duration of this range. Bidding for a slot on Kusama takes place publicly, meaning all participants have full visibility of what other teams are bidding. The end time of an auction is determined randomly by a Verifiable Random Function (VRF). The successful winner is onboarded at the beginning of the lease and their bid remains locked until it ends. A lease can be extended by winning another auction before the occupancy of their allocated slot expires. 

 

Crowdloans for Funding Parachain Auctions

Crowdfunding bids to win a parachain auction can be facilitated by Kusama’s on-chain crowdloan mechanism. This allows anyone to contribute towards a project’s auction bid by agreeing to lock up their own KSM tokens until the end of the parachain lease. Such contributions can be submitted until an auction is won up to the maximum amount required by the team creating the campaign is fulfilled. By participating in the crowdfunding, loaners can be rewarded financially with tokens on the blockchain. Crowdloans can be hosted either on Kusama or a 3rd party platform. At the end of a lease period, all tokens are returned. This is also applied in the event of a slot auction bid being unsuccessful. 

Governance

The initial Kusama governance system is known as ‘Genesis Governance’. This is how the community implements changes on a decentralized network. Such governance is made up of three chambers:

 

  • Referendum Chamber

All changes to Kusama’s logic must be approved by the chamber, which is made up of an assembly of KSM token holders. Each vote is weighted to the amount of tokens one owns. Each referendum has a specific proposal associated with it. All referenda have an enactment delay, which is the time between when a referendum has ended, approved and changes implemented. Kusama allows seven days for token holders to vote on referendums followed by an enactment period of eight days, after which the referendum will be enacted on the chain.

 

  • Council Chamber

The council is composed of elected community members, which helps keep the network secure as they have a stake in the network. The council is voted in by Kusama token holders, meaning they are typically well-known community members. Kusama will have a fixed number of 19 seats for council members. 

 

Kusama council members have control of the treasury, and have three primary governance related responsibilities: proposing sensible referenda, cancelling dangerous referenda and electing the technical committee. 

 

  • Technical Committee Chamber

The Technical Committee is made up of teams that have successfully implemented or specified a Polkadot/Kusama runtime or Polkadot Host. Along with the Council, Technical Committee members can produce emergency referenda, fast tracked for voting and implementation. These are used for critical bug fixes, or rapid implementation of new and battle tested features into the runtime. Fast tracked referenda means they can be active alongside other active referendums. 

Treasury

Kusama hosts a treasury, which is a pot of the native KSM token, topped up through transaction fees, slashing, left overs from Kusama’s token issuance inflation that is not used for block rewards, and deposits which are lost. The goal of the Kusama treasury is to fund the development and growth of the ecosystem. 

 

Suggestions for spending the money owned by the treasury can be put forward by anyone, with a 5% non-refundable deposit for the amount to be spent. Kusama’s council determines if the proposal is to be rejected or approved. Approved proposals are moved into a queue each budget period (24 days). 

 

A lack of spending proposals will result in a burning of KSM funds, causing a slight amount of deflation. This burn amount is currently 0.2% on Kusama. 

Substrate

Substrate is a core pillar of Kusama. The word substrate is defined by the Oxford English Dictionary as a substance or layer which is under something or on which something happens. This definition fits the use case for Substrate as the technology layer underpinning Polkadot and all of its connected blockchains. Parity created Substrate as a way to build custom blockchains quickly and easily. Substrate’s FRAME (Framework for Runtime Aggregation of Modularized Entities) runtime system is what lets developers build out their own blockchain logic. Runtime, in the context of blockchain, refers to the business logic which defines a blockchain’s behaviour. FRAME makes it easy to construct a runtime by giving developers access to modulus known as ‘pallets’. Such modules are the building blocks for constructing a unique blockchain, with each pallet containing its own domain-specific logic. This can refer to governance, treasury, assets and more. The advantage that this brings to developers is eliminating the need to build a custom chain from scratch, although FRAME grants the option to create a custom module. Substrate provides a solid foundation for developers to build on.

 

Substrate also facilitates smart contracts on the Kusama blockchain. Smart contracts are possible because FRAME contains a module (‘pallet’) which implements an API for typical functions that smart contracts need. This module is the contracts pallet, and enables functions such as storage, querying information about accounts, etc. ink! is a Rust based eDSL (Domain Specific Language) which is specifically for the contracts pallet. It is in this language that Polkadot smart contracts are written.

 

Substrate runtime is compiled into a native executable and a WebAssembly (Wasm) binary. ink! contracts are compiled to Wasm, meaning anyone can build a smart contract in a Wasm compatible language. This is the same technology used by many blue-chip organizations as a faster alternative to JavaScript for the web. By utilizing Wasm for on-chain logic and smart contracts, Kusama is taking advantage of the thousands of hours worth of development time which went into building the technology by the W3C, the organization behind WebAssembly. 

Nominated Proof of Stake (NPoS)

Kusama’s Nominated Proof of Stake (NPoS) selects the validator set. The two key parties involved in NPoS are validators and nominators. Nominators nominate validator candidates they trust to participate in block production. Each nominator can submit a list of up to 16 validators that they support with their stake. In the following epoch (a standard timeframe for block production, lasting 4 hours), validators with the most amount of KSM staked to them become elected for block production. Anyone can help secure the network by running their own validator node, while there are no particular requirements to become a nominator. Kusama aims for proportional justified representation, meaning no validators and their associated nominators are over or under represented. To achieve this, Kusama gives elected validators equal voting power in the consensus protocol. 

Staking Rewards

Validators that are successfully elected and produce blocks are rewarded with the native KSM token. Nominators who back a validator and earn such a block reward share in the return. These rewards are distributed automatically to the nominators at a protocol level. Validators are paid the same regardless of how much stake they have, meaning pools with lower stake will pay proportionally more to nominators than pools with larger stake. This incentivizes nominators to distribute their stake to smaller pools, in order to maximize their rewards. This intends to align what’s best for the network (avoiding control by a few powerful validators) with what’s best for the individual (maximizing financial rewards). 

 

While staking rewards remain constant, the amount of rewards distributed to nominators will also be influenced by the commission fee the validator charges. This is a variable fee set by the validator to cover their operating costs. Lower commission validators will distribute higher rewards to nominators. Rewards are recorded approx. every hour on Kusama and calculated per era, every 6 hours. In Kusama’s native web wallet, rewards can be claimed by triggering a payout for all unclaimed eras.

 

Staking rewards are kept available for 84 eras, which is approximately 21 days on Kusama.

Kusama’s Consensus Mechanisms

Consensus refers to how a group of distributed, independent actors participate and agree on the state of the blockchain. Polkadot uses a hybrid consensus mechanism to split finality and the block production mechanism. This ensures probabilistic finality (ability to produce new blocks) and provable finality (having everyone agreeing on the state of the chain). Both mechanisms combined ensure blocks are produced rapidly, with a provable way to finalize the state of the chain, without any slow down in transactions being processed. The two mechanisms are called BABE and GRANDPA.

BABE

BABE (Blind Assignment for Blockchain Extension) is Kusama’s block production mechanism. In Kusama, BABE sessions are every hour. 

 

It determines which validator nodes will produce blocks. BABE uses a verifiable random function (VRF) to randomly select a validator among all eligible candidates. This VRF is based on research published in the Ouroboros Praos paper, which is the current consensus mechanism used by the Cardano blockchain. This election is totally private, ensuring no validator can be coerced by an attacker. 

GRANDPA

GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement) is the mechanism used to finalize blocks in the Relay Chain. This works by having ⅔ of the validators acting honestly. As long as ⅔ validators attest to a chain containing a block, all blocks leading up to that are finalized. 

Slashing

Slashing penalizes a validator for misbehaving. Slashing removes a percentage of the validator’s stake, rather than a fixed amount. Validators with higher stake will therefore receive higher penalties. Slashed KSM is added to the treasury to help fund the growth of the ecosystem. Nominators who support slashed validators also have their own stake proportionally removed. 

 

Chilling removes a validator from the active validator set, and takes them out from the pool of eligible candidates in the next NPoS election cycle. Validators can do this themselves (when they know their services will be offline, for example) to eliminate the risk of slashing. This voluntary chilling lets them keep active in the current epoch, but not in the following. Chilling can also be used as a punishment to disable validators from taking part in consensus. 

Why should I participate in Polkadot staking with Blockdaemon? 

  1. Secure validator nodes

PoS networks are heavily dependent on network participation and validator integrity. Blockdaemon makes it easy to run your own dedicated validator node or stake your tokens to Blockdaemon’s validators to earn participation rewards. With regional and data center diversity and node redundancy, Blockdaemon takes an engineering 1st approach to provide best-in-class uptime. We have deployed over 1,000 full nodes – making us the most battle-tested provider in the node infrastructure industry.

 

  1. Failover Safeguards

Blockdaemon has manual failover with a trained and battle-tested team to eliminate risk of double signing. Blockdaemon manages all of this for you automatically, so you don’t have to worry about staying online, in sync, and up to date. Just follow our easy delegation instructions for your preferred protocol, and monitor your balance.

 

  1. Enhanced monitoring 

Blockdaemon monitors all machine and protocol metrics with 24/7 human and automated monitoring to avoid downtime-related slashing. With engineers distributed globally, protocol-specific failover strategies are in place to eliminate risk of double-signing, and hot-spare and fully-synced backup nodes exist for fast recoveries when needed.

 

  1. Slashing Guarantee

If slashing does occur due to any fault on the part of Blockdaemon, we ensure 100% loss coverage. However, Blockdaemon do not cover slashing losses that result from network malfunctions, as these are outside of our control.