How does the Kin Consensus Protocol (KCP) work?
As we move towards the launch of the Kin blockchain main network launch, there have been a lot of questions regarding the need for ‘7 federation nodes’ to start the official decentralized network.
At the core of that need sits some mathematical and regulatory theory, based on how Kin’s Consensus Protocol (KCP) works.
What is a Consensus Protocol?
Every blockchain is made up of entities we call “nodes.”
Nodes are essentially computers that have chosen to download and run the network software. Each of these nodes monitor transactions on the network and choose to validate or invalidate each transaction based on a series of mathematical computations. (For a more in-depth look at how nodes work, consider reading our guide: “What is a Blockchain?“)
Each of these nodes are given a vote within the network, and with those votes we aim to reach a ‘consensus,’ or decision. In any situation where voting occurs, we have a ‘consensus protocol’- a formal set of rules that help us to decide when a satisfactory decision has been made.
The most common consensus protocol that most people are familiar with is “majority rules.” We might use this in a classroom setting when a teacher is asking her students which activity they wish to do. She’ll ask for a show of hands and the activity with the most votes wins.
However, in our every day lives, we do deal with much more complicated consensus protocols, such as voting in elections, where all votes may not be voted equally.
When it comes to a blockchain network, consensus protocols are very important as they need to:
- Validate the authenticity of transactions and balances infallibly.
- Define a ‘safe’ majority that both prevents network attacks, but also prevents a tyranny of the majority.
- Create a network that can be considered fair and decentralized from a regulatory perspective.
- Ensure that no minority (counted either by votes, or by entities/people) can control the will of the network and out vote the majority.
- Prevent stalemates or failures.
- Prevent breaks or hard forks within the network.
- Incentivize good actors (users).
- Disincentivize bad actors (users).
Each of these criteria result in an increasingly complicated set of rules being applied to reach consensus. The challenge is that reaching consensus is costly. If you had to poll 100% of nodes in the network each time and figure out the majority vote it would be extremely resource intensive- and depending on how you define a node (such as by hashpower, or number of computers run), it could be easy to manipulate the votes financially.
Given all this, nearly every blockchain network in development currently has set out with the goal of creating a unique consensus protocol that they feel can address these challenges.
What is the Kin Consensus Protocol (KCP)?
Our understanding of the Kin Consensus Protocol is still forming. As of right now, we know that the Kin network is based on a fork of Stellar and the Stellar Consensus Protocol (SCP).
The Kin team is currently discussing and exploring additional features they aim to implement regarding the ability to incentivize good actors, and disincentivize bad actors, but beyond this, we believe that the KCP will operate in a manner very similar to Stellar’s SCP model.
But, we can walk through the features of the Stellar Consensus Protocol and look at how they interact.
Understanding the Landscape of Kin Consensus Protocol (KCP):
#1 – Byzantine Fault Tolerance (BFT):
A “Byzantine Fault” or “Byzantine Failure” is when an individual node, or nodes, act arbitrarily or unexpectedly within a network.
Imagine a scenario with four voters: “User A,” “User B,” “User C” and “User D.”
All four voters are told they can pick between ‘Chocolate’ or ‘Ice Cream’.
A, B and C all pick between the choices that were provided to them. User D, however, says their vote is for ‘Potatoes.’
Now we have a very basic byzantine fault within the network. Luckily, we don’t need full unanimous consent in order to reach consensus. But, if we don’t require complete consensus, then we must have a specific model in place to decide what the minimum consensus is and how we deal with byzantine faults.
In a BFT system, validators send messages back and forth, and will confirm a transaction to be true if more than 66% of the validators vote in favor of the issue. (The BFT model is much cheaper and faster than ‘Proof of Work,’ but it does sacrifice decentralization in favor of a more centralized authority.)
Classic BFT, which is used by blockchains like Ripple, require a pre-set validator list, which is often defined by the company behind the blockchain. Anyone can create a validator, but you can only partake in consensus if the central authority adds you to the list.
While blockchains like Stellar attempt to shift away from this model, they still often ship with a recommended list of validators in the node code in order for a new node to connect to the network, who become overly powered and essentially mimic classic BFT behavior.
Kin will likely use the Stellar alternative to BFT, called “Federated Byzantine Agreement (FBA),” which we’ve outlined below. But this still relies on principles of BFT, and is likely to ship with a starting list of validators that most people won’t change, making it much closer to classic BFT models.
#2 – Federated Byzantine Agreement (FBA):
The specific model for dealing with byzantine faults within Stellar, and therefore Kin, is a Federated Byzantine Agreement (FBA). FBA is a decentralized alternative to BFT.
Within an FBA network, rather than relying on a list of approved validators, each node decides which validators it wants to trust. These validators are referred to as a ‘quorum slice.’ Quorum slices of each validator overlap throughout the network, and eventually result in a quorum (or network wide consensus) on any decision.
The important part of an FBA model in its pursuit of decentralization is the ability for anyone to create a validator on the network, and for users to be easily able to change and manage their own quorum slices.
FBA models have received some criticism due to the complexity or cost associated with both of these tasks. Some blockchains that are being run on FBA models have changed the functionality of their validator nodes to make it cost prohibitive for the average user to run a node, thus centralizing this process.
Configuring a quorum slice within your validator node’s configuration file is also a complicated process that requires knowing the IDs of various nodes, and listing mathematically balanced quorum slices. Since most users are not capable of this, the validator code that users run on their system often ships with a set of pre-defined quorum slices set by the developer. Since most users do not change from the default (or can’t), and tools are not provided to allow users to easily create their own slices, these default nodes become very powerful within the network.
#2 – Vote & Accept:
In most voting systems, we’re used to two scenarios:
- We can vote for or against something (“Do we want to ratify this agreement? Yes, or no?)
- We can pick one choice within a set (“Do we want to go to Germany, France, or Mexico for Vacation?)
In the byzantine agreement system used by blockchains like Ripple, Stellar, and Kin we actually have a third option. We can choose to vote for a specific answer, as well as note which answers we will accept.
So, if it was the vacation question, I could cast my vote as “I vote for Germany, but would accept going to Mexico.” This becomes a critical concept as we delve into quorum slices.
#3 – Quorum Slices:
In any decentralized network, we have something called a “quorum,” which is the set of nodes that is sufficient to reach an agreement.
In our example above, perhaps we decided that as long as 75% of users placed a valid vote, then we met our minimum quorum. This means we could simply ignore the invalid vote from “User D.”
Within Ripple, Stellar, and now Kin, we’ve shifted from simply using quorums to using ‘quorum slices.’
A quorum slice is a subset of a quorum, a trusted group that can convince one particular node to agree with it.
Within this example, the yellow node (the first circle in our diagram) has the other three nodes within a quorum slice.
From these slices, it can create a series of rules where the yellow node says:
- If two-thirds (66%) of nodes within this quorum slice agree with an option I “accept,” then change my vote to that option.
- If 100% of nodes within this quorum slice agree with an option I didn’t accept, then change my vote to that option.
- If 66% of nodes within >66% of the quorum slices I follow agree with an option I didn’t accept, then change my vote to that option.
Quorum slices are essentially groups of nodes that the user trusts. The rules a user sets for their quorum slices allow different layers of trust and influence for each quorum slice.
Perhaps within the Kin network, a node decides that they are going to create three quorum slices they trust. One consisting of the nodes hosted by Kik, the Kin Foundation and IMVU. The second slice consisting of all the developers from the Kin Developer Program, and the third consisting of community hosted nodes.
When a transaction gets made, the node sees that Kik and the Kin Foundation are voting “No” on that transaction, but IMVU is voting “Yes.” At this initial stage, the node assumes that “Yes” is the accurate vote.
As it checks with the two other quorum slices that are within its defined Byzantine Fault Agreement, it realizes that 100% of these other two quorum slices are voting “Yes.” At this point the node changes its mind, realizing there must be an issue with the votes from Kik and Kin, and it now decides to vote “Yes” as well.
#4 – Quorum Slice Overlap:
The final important factor for us to note before we can walk through an example of a Kin Consensus Protocol decision is ‘quorum slice overlap.’
As we’ve noted, each node will ultimately have multiple quorum slices that it trusts. In order for the network to operate, these quorum slices all need to layer together in a manner that allows the entire network to reach a quorum consensus (>66%).
However, if users are able to create their own validators, and define their own quorum slices, we can run into what I call “the faction trust problem.”
The faction trust problem is when a portion of the network trusts one quorum slice, but no nodes outside that quorum slice, and another portion of the network trusts a different quorum slice but none outside of that.
These two opposed quorum slices could both reach different conclusions on a vote and leave the network stuck at a standstill. We refer to these quorums as “disjointed quorum slices.”
Given the fact that these quorum slices are disjointed, it is impossible for the network to come to a complete consensus. Even though 5 nodes are voting one way, they only add up to 55% of the network vote. Since their quorums do not overlap there is no way to convince one of the other three nodes and reach 6/9 votes (66%).
In some blockchains, this type of situation could cause a hard fork wherein the blockchain splits into two chains that diverge and continue to process separately. This would ultimately produce a risk of a double-spend attack and other challenges.
Since protocols like Stellar and Ripple are designed to be used by real-world financial institutions and support tangible underlying assets, it is crucial that the chain never splits. For this reason, the Stellar network (and all FBA networks) are designed to halt any new transaction until a network consensus (>66%) is achieved.
This is why it is crucial for the quorum slices to overlap, so there is always a connection between slices, and the network can never be divided into two camps.
The Journey of a Kin Transaction:
For a very simple example of how a Kin transaction might work within the KCP, let’s pretend that Dillon and I have invited Ted out for a coffee. We’ve decided to vote on where we want to go for coffee using the Kin Consensus Protocol and our Kin validator nodes. Each node is named for the person it represents.
In this scenario, we will assume:
- Dillon has voted for Starbucks. He has not voted for, nor voted to accept any other answers.
- Adam has voted for Starbucks. He has also voted to accept Tim Horton’s.
- Ted is undecided at the start of our scenario.
- Ted’s quorum slice consists of Dillon and Adam’s nodes.
Voting and Accepting:
When Ted is asked to place a vote, he sees that the options before him are “Tim Horton’s,” “Coffee Time,” and “Starbucks.”
Being the true Canadian that he is, Ted decides to vote for Tim Horton’s- but he also decides he can accept going to Starbucks as it is near his office and provides good quality coffee. He decides that he isn’t willing to accept Coffee Time because, quite frankly, it’s terrible coffee.
Ted is now broadcasting the following to any quorum slice that he is a part of:
- Vote(Tim Horton’s)
- Reject(Coffee Time)
Now he checks the quorum slices he follows (which consist of Dillon and Adam). Ted’s node notices that both of the nodes in his quorum slice (100%), are voting for Starbucks. Since Ted has listed that he is opening to accepting Starbucks, he won’t argue against it.
Once every member of a quorum slice has voted for the option, they in turn “ratify” the decision. The ratification of a decision means that that entire quorum slice is now represented by the vote. So in this case, because >66% of the quorum slice voted for Starbucks, and Ted noted he would accept Starbucks, the vote is ratified. In this case, anyone who follows Ted, Dillon and Adam as one quorum slice would now see that the slice is voting for Starbucks.
Voting for Starbucks doesn’t assert Starbucks as the right option. Instead, Starbucks will be accepted as the right option only if it is ratified.
Confirmation is the final step of the voting process, and is used to ensure system-wide agreement (quorum consensus).
Once there is an agreement, the nodes begin to exchange confirmation messages. Each node is asked to agree to an statement, and once sufficient messages are delivered and processed to show that the network has reached consensus then every live node on the network after that is forced to accept the decision.
In our example, Adam and Dillon may send out the message “accept(Starbucks).” When Ted sees that more than 66% of nodes within the network are agreeing with “accept(Starbucks),” his node is now forced to do the same, and begins to broadcast the message “accept(Starbucks).”
The BFA system has additional features for dealing with breakdowns among quorum slices and other bad actors, but this process of vote, ratify and confirm outlines the basic model of BFA in a consensus protocol, and the primary model we expect the Kin blockchain to be using.
NuFi.io is an independent publisher aimed at providing quality journalism in the cryptocurrency space. NuFi is not associated with, paid by, or employed by any cryptocurrency project. We rely on subscriptions from readers like you!
To help keep NuFi.io creating quality content consider:
- Subscribing on Patreon for only $2.99/month
- Donate ETH, Kin or ERC20 tokens to our address.
- Or donate most cryptocurrencies via CoinPayments using the following button: