- Kusama is an unaudited Polkadot — used like a testnet, economics of a mainnet
- Expectations to migrate from centralized PoA to decentralized NPoS delayed for fixes
- Own DOTs? You’re entitled to KSM tokens. Learn about nominating validators, because this is a different game than standard DPoS!
- As of Sep 18, 2019, DOT-holders have claimed 41.85% of the network’s potential supply (issuance)
- I’ve been informed that the Web3 Foundation will control <11% of the supply. Want some? Apply for a grant!
- The staking algorithm optimizes for decentralized stake. There is no quick take — you’ve gotta read this part!
- We’ve got initial staking reward estimates here. Thanks Joe!
- On-chain governance is dictated by token-holders, not validators
- Almost any parameter of the network (and the code!) is updated on-chain
- Launching without parachains
- Figment’s first look at Kusama
- How Nominated Proof-of-Stake will work in Polkadot
- Joe Petrowski’s staking reward estimates
Kusama: a canary network
Bill Laboon has been working on technical education at the Web3 Foundation since April 2019, including Kusama documentation, workshops, and more.
Joe Petrowski is a research analyst at Parity, working on Substrate and Polkadot since December.
Kusama is being called a canary network — an early, unaudited release of Polkadot. Kusama is like Polkadot, and though unique, it will be possible to use it for all of the things that Polkadot will be used for. Such as?
Such as anything you would want to do on the Polkadot mainnet release. Kusama’s architects expect to see people trying out running validators, (eventually) connecting parachains, trying out governance, and more. Parachain (inter-blockchain) capability won’t be available at launch — more on that later!
Kusama is currently running a PoA (Proof of Authority) network, meaning its control is centralized in the hands of its creators. But not for long. In a few weeks (max three weeks according to Bill, AMA took place Aug 29, 2019), control of the Kusama network will be decentralized. That means that coin voters and the validator set will run Kusama. For now, the Kusama creators are awaiting enough addresses to signal an intent to validate, which you can observe here: https://polkadot.js.org/apps/#/staking
Since this site is also used for other networks, ensure you have changed to the Kusama network in ‘settings.’ If you have any specific questions for the teams involved, head over to the Kusama watercooler. I wrote this brief ‘first look’ article about Kusama last month — there’s a lot to break down here, so while expecting chaos, expect Figment to make sense of it all.
We expect that people will want to use Kusama for many things, like staking, buying parachain slots, and testing new features or any upgrades slated for the Polkadot network — all of which will require KSM tokens. Since it’s not a testnet, and there are no free tokens being distributed, KSM may have some economic weight. I wrote a bit more about that potential here. If KSM aren’t free, how are they minted and distributed?
Supply & Distribution
During the soft launch, all transfers have been disabled, so there’s no way to obtain KSM except through the claims process. The total supply is dictated by the claims process, which may continue in perpetuity until all KSM has been claimed. DOT holders may claim KSM at a 1:1 ratio of DOTs they own.
- 4.185M KSM have been claimed as of Sep 18, 2019, 5.815M remain
- The Web3 Foundation is entitled to claim up to 2.8M KSM
(but likely won’t, because their 2.8M DOTs include employee, advisor, grant distributions and the final 10% sale for DOTs)
- I’ve been informed that the W3F will control <11% of the KSM supply
We expect more claims to be placed, with the potential for the total issuance (ie. supply) to be up to 10M. The W3F’s sizeable portion of the KSM supply is intended to be used to fill a “frictional faucet” and award grants.
If 50% of KSM is staked, then each validator will reportedly receive approximately 20% annual KSM returns, provided they are not punished for breaking protocol rules. As noted in ‘first look’ article, we don’t yet know the returns for staking KSM, but it will also be based on the total issuance (ie. supply), which changes as KSM are claimed. Check out Joe Petrowski’s initial staking reward estimates.
NPoS (Nominated Proof of Stake)
NPoS (nominated proof of stake) is an innovation that deserves some unpacking. If you’re a stakeholder and you haven’t read Alfonso Cevallos’ April 2019 explanation of NPoS, you should.
I’m writing an article dedicated to explaining this entirely, so for now I’ll keep this simple and compare Kusama/Polkadot’s NPoS with Cosmos’ DPoS (delegated proof of stake).
Ways that NPoS is similar to DPoS
You may back more than one validator with your tokens, and your validator(s) may set a fee amount for their service. You are rewarded and punished for the actions of the validator that you delegate to / nominate, so select wisely. Because of what’s at stake, the reputation of validators will be very important. Joe noted that it may be valuable to profile validators off-chain, a project that could be awarded a W3F grant.
Ways that NPoS is different
My understanding is that NPoS incentivizes a more equal stake-backing distribution, and thus incentivizes single validator entities to run multiple nodes. How?
Phragmen’s algorithm is optimized to allocate nominations such that 1) the validators with the maximum amount at stake are selected as the active set and 2) the most equally-distributed stake possible. Web3 Foundation’s documentation explains it in detail here.
- there are a limited number of validator slots
- each token-holder nominates a list of validators that they are willing to stake their tokens with
- the algorithm assigns the most supported (token-backed by nomination) validators to the active slots
This is isn’t very different from Cosmos’ DPoS, but here’s where things get interesting.
- each active validator node gets the same rewards as all of the others (makes sense to have multiple nodes, then, right?)
- each nominator gets rewards proportional to what they have staked (makes sense to stake with the smaller validators, right?)
Phragmen will automatically allocate stake from nominators to make it as equal as possible amongst validators. In order to maximize your rewards, the algorithm will pair you with the validator(s) from your list with the lowest token backing. Thus, as a token-holder, it’s in your interest to nominate as many trustworthy validators as possible. And you may nominate up to 16 validators.
Your fav validator will likely run multiple nodes
My prediction is that you won’t be trying to decide which 16 validators you think you can trust. For example, rather than putting 15 unique validator services on your nomination, you may instead nominate Figment1 through Figment5, Iqlusion1 through Iqlusion5, and the same for Chorus. Then Phragmen’s algorithm will automatically distribute your stake to maximize your returns.
The most important part will be nominating only the most trustworthy validators. Since you share the risks as much as the rewards, your validators’ behaviours will determine your potential rewards and punishments.
For Kusama, initial slashing parameters have been decided upon, but it’s worth noting that these parameters are subject to change via the on-chain governance mechanism. The larger the number of validators involved in an episode, the higher the slashing percentage.
There are three main categories of slashing:
- BABE equivocation
- GRANDPA equivocation
The first two are punished the most severely, compared with the third. A validator can be offline for perhaps two hours (not straightforward — email@example.com for more info on risks) without being slashed, unlike Cosmos, for which a validator could be offline for over 15 hours without being slashed.
Perhaps the most important thing to remember is that you are potentially exposed to the risks of every validator that you nominate.
The two major types of nodes in Polkadot are validators and collators. They are both full nodes. Validators are full nodes on the relay chain and light nodes for the parachains. Collators are the inverse — full nodes on a parachain and a light client to the relay chain. Currently, participants can run a full node or a light client, and after migrating from PoA to NPoS, they will be able to run validator nodes.
Validators may operate with two different accounts
- Stash account
The stash account is designated for storing your KSM — think of it like the bank. The W3F recommends using cold storage for the stash account.
- Controller account
The controller account actually issues commands.
eg. turning off/on validating or intention to validate
These actually may be the same account, but having the option of using these two different accounts allows operators to run their validator more securely. Speaking of security..
For stash and controller accounts, Kusama is very much like other networks. You may keep your keys in a paper wallet, an offline machine, or your desktop machine (encrypted with a strong password, Joe reminds us!). According to Joe:
For Session keys, which are only relevant to validators, these are stored in your client. They are generated within the client (although there is an option to generate them yourself and inject them to the client). Then you must tell the chain your public session keys by signing and submitting an extrinsic from your controller account.
Considering that Kusama will use ‘nominated proof of stake (NPoS)’, it may be difficult to estimate what the minimum stake to be in the active set could be, but we are fortunate to have Joe’s estimates here:
There are a lot of variables and assumptions here, including the number of validators and the amount of the network at stake, but it’s a start to get an idea.
Aurel (Dokia Capital) raised the issue of increased operational costs when incentivizing one entity to run multiple validators. He noted that doing so doesn’t appear to make the network more resilient, though Joe noted that slashes are proportional to the number of simultaneous offenders.
Unbundled from governance
Perhaps most interesting of all is that validators do not play a direct role in Kusama’s governance, because they do not get any extra voting power from any stake nominated to them
The key principle of Kusama’s governance is that the majority of KSM holders can always direct the network. Just because you’re nominating doesn’t mean you default your voting rights to the validator that’s doing work on your behalf.
Token holders can directly delegate their voting power — they can delegate their vote to a proxy account, which can be controlled by someone else. Token holders also vote for members of the Council. The Council has some power to represent passive holders. According to Bill:
And for a planned-but-not-yet-implemented feature, Spontaneous Subject Committees — smaller subsets of the population involved in particular aspects of the system — they will be able to delegate votes.
What is the Council?
This didn’t come up in the AMA. Actually, I’m planning to host another AMA dedicated specifically to Kusama and Polkadot governance. In the meantime, this is from our own research, based on Polkadot documentation.
Anyone can make a proposal. Anyone can add deposits to a proposal. The proposal with the largest deposit becomes a referendum to be voted upon. The Council votes to schedule referenda to be voted upon beyond publicly scheduled referenda, and these referenda are biased (via adaptive quorum biasing) toward a ‘yes’ vote, whereas the publicly-introduced are biased toward a ‘no’ vote.
It depends on the voter turnout. The greater the turnout, the lower the bias.
The Council may also cancel potentially dangerous referenda. A new Council member is elected every two weeks and each member’s term lasts for one-year, unless removed prematurely by referendum. Again, more on this in a future article.
What if Kusama dies? Canaries being death prone..
The governance mechanism being on-chain, if the Kusama network dies, how do the creators expect the community to coordinate to resurrect it? There are many kinds of “death.”
In a case of absolute force majeure, which we don’t expect to occur obviously, the Technical Committee and Council can work in tandem to set Kusama back up. But in most cases, issuing a runtime upgrade should be enough to bring it back into working order if there are any issues.
Probably in a similar fashion to the way many current chains exist. The only thing that would require off-chain governance is if the node panics. If the state gets totally corrupted, but the nodes have not panicked, then they could be upgraded on-chain through a state update. And a corrupted state is OK as long as everyone _agrees_ that it’s corrupted.
Can on-chain governance change everything?
Most (if not all) parameters can be changed via runtime upgrade, which can be enacted with on-chain governance. According to Bill:
Doing something very deep (like changing how data is stored on disk) would require an actual software update. But parameters involving anything around the state transition of the blockchain can be done via governance, up to just replacing the whole runtime code.
There’s the Polkadot / Kusama runtime environment, but it is running a Wasm blob called a runtime. This Wasm blob is what handles the actual state transitions of the Polkadot/Kusama chain. So anything related to that can be upgraded over the network.
A parachain cannot (yet) connect to Kusama and Polkadot, and Bill is not aware of any plans for a Kusama-based parachain yet — but if you do know of someone planning to connect a parachain to Kusama at launch, let him know. The creators are working on Cumulus, which according to Joe, will allow parachains to connect (hopefully with just one line of code).
So technically the interface exists in Kusama to have a parachain, but practically speaking, you would have to build a collator node to do it, so it would be very difficult at this time. But we do expect to eventually have parachains on Kusama.
Is Cumulus similar to Cosmos’ IBC (Inter-Blockchain Communication)?
No. Cumulus is an implementation of a collator node. It doesn’t specify how messages are passed, it implements the interface between parachain collators and relay chain validators.
We’re not sure about this, but it might handle the transition from independent chain to parachain/parathread ie. when you become a parachain, you will have to issue a runtime upgrade that switches your finalization rule to follow the relay chain of Polkadot.
Kusama’s creators presented us with a substantial amount of innovation, so I think that one hour was not enough time for this AMA. We’d love to have the Parity team and Web3 Foundation back for another chat in the future.
Special thanks to Bill and Joe for spending an hour with Staking Hub to answer our many questions. Thank you to Andrew Cronk for co-hosting.
Thanks to our Staking Hub community for the thoughtful and impactful questions that inspired high-quality answers. Since you’ve read this far, you might as well join us over in the Staking Hub Telegram channel 🙂