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?
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.
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) 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).
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.
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.
This is isn’t very different from Cosmos’ DPoS, but here’s where things get interesting.
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.
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:
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.
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.
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.
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.
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.
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.
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 :)