Discover Unikname Network: Episode 2 – Delegated Proof of Stake with a twist
Consensus protocols are fundamental building blocks of any blockchain. A blockchain is healthy when its consensus works as expected. This means that transactions are ordered into blocks, new blocks are regularly added to the chain, and block validators are diverse enough to prevent centralization or censorship.
In this article, we will look at the current consensus protocol of Unikname Network. Unikname Network uses a Delegated Proof of Stake protocol that elects delegates by college. There are three colleges that correspond to the different types of UniknameID available: individual, organization, and network.
That was the short version. Keep reading for the details!
Why do we need consensus mechanisms?
A blockchain is a decentralized registry of transactions. These transactions go beyond sending money from A to B. They can be used to register a number of events with significance inside and outside of the blockchain: time-proofing documents, tracking the ownership of artwork or real estate, constructing an online identity, etc. The applications are endless.
For the system to work, all nodes in the network must agree on a common history: which of these transactions was sent first, did that transaction happen at all, did this transaction exist at that time, etc. And with no central entity to orchestrate it all, the network needs a consensus mechanism.
Pretty much all blockchain consensus mechanisms can be boiled down to selecting one node in the network to propose their version of what happened since the last synchronization, i.e. since the last block. When a new block is proposed and accepted by the network, it means that all nodes in the network have reached a consensus on this new page in their common history.
Both of the most famous consensus mechanisms, Proof of Work (PoW) and Proof of Stakes (PoS), work similarly to a raffle: participants are selected at random (not really but close enough) to validate the next block. Just like in a raffle, you can increase your chances of winning by buying more tickets. In PoW, it means committing more computing power. In PoS, it means committing more of your assets.
Both protocols have their own drawbacks. PoW is hard to scale, requires specialized hardware to keep up, and uses a combined massive computing power that translates to a large carbon footprint. PoS is prone to centralisation of the power in the hands of the wealthy as well as reduced liquidity as candidates keep their tokens to increase their chances of winning the raffle. Unikname Network has opted for another type of consensus: the DPoS.
Delegated Proof of Stake (DPoS)
DPoS is a consensus protocol in which a small number of nodes are selected to approve new blocks based on the votes of other actors in the network. The raffle is therefore replaced by elections.
In Unikname Network, we will prefer the term support over vote. Vote is usually used to refer to a one-time, scheduled event with long term effects whereas the act of supporting a delegate is continuous (i.e. it counts for more than one election cycle). An actor can choose to give or withdraw support for a delegate at any time.
DPoS requires considerably less computing power than Proof of Work. It also encourages the redistribution of tokens among supporters. In this system, actors with smaller amounts of tokens can still participate in the democratic election process. Similarly, big accounts can influence the governance of the network without the need to become delegates themselves.
Delegates depend on community support to keep their position. As such, they are incentivized to do a good job and maintain a good reputation. Malicious behavior can be sanctioned by a withdrawal of support for the malicious delegate. By deciding in advance which node will validate a given block, DPoS considerably reduces the amount of interactions required to generate a block. This enables shorter block time, and a faster validation process.
In Unikname Network, to participate in the consensus protocol, actors must have an active UniknameID. It is required to both offer support and to become a delegate.
Calculating support weight
How delegate supports are tallied varies greatly between different DPoS iterations. In designing its own DPoS, the Unikname Team has the following goals in mind:
- Actor stake – The weight of an actor’s support should be derived from its stake in the network.
- One vote per account – To reduce the influence of bigger stake holders, an account should only be able to support one delegate. Funds can be divided between accounts to support more delegates. But this should dilute the original weight.
- One seat per delegate – A delegate (i.e. a given UniknameID) cannot occupy more than one seat.
- People’s choice tie-break rule – In case of a tie, the UniknameID with the most supporters wins.
Let’s take an example: @maria has 100 000 freshly acquired $UNIK in her unikname.network crypto-account. She is new to the community and is voting for herself. @bob has 10 000 $UNIK in his crypto-account. He is very active in the community, campaigns on redistributing his gains to his supporters, regularly weighs in on community issues, etc. As such, @bob has amassed a following and is supported by over 100 people whose combined crypto-account balance comes at 90 000 $UNIK.
@maria has a supporting weight of 100 000 $UNIK behind her claim to become a delegate. With its own 10 000 and the combined 90 000 of his followers, @bob also has 100 000 $UNIK behind him. It is a tie. However, @bob is supported by 101 people whereas @maria is only supported by 1 actor. @bob wins the tie.
Three Colleges of delegates
A unique feature of the Unikname Network DPoS that you will not find in any other blockchain is its use of colleges. Unikname Network supports three types of UniknameID: individual, organization, and network. The actors behind each type of UniknameID defend very different interests. To represent the interest of each group equitably, we introduced the concept of colleges. Colleges have the added benefit of mitigating two common pitfalls of DPoS blockchains, centralization and cartelization. They also constitute an anti-fork measure.
A given UniknameID can only vote for a delegate belonging to the same college: UniknameID of type individual support individual delegates, UniknameID of type organization support organization delegates, and UniknameID of type network support network delegates.
Each college has a fixed set of representatives: 10 for individuals, 10 for organizations, and 3 for network entities. Seat allocations can be transferred between individuals and organizations if there are not enough delegates of a given type. This ensures that 23 nodes secure the network at all times.
For example, if only 5 organizations register as delegates, the 5 remaining seats become available for individuals, and 15 individual delegates will be selected instead of 10. The reverse is also possible when not enough individuals are registered as delegates. When an election occurs, the protocol always tries to fill the seats according to their original distribution (i.e. 10/10/3).
To better defend the interests of its different actors and to mitigate centralisation and cartelisation tendencies, Unikname Network has introduced the novel concept of colleges in its DPoS implementation. Today, the network is protected by 23 delegates divided into 3 colleges (individuals, organisation, and network) with a 10/10/3 split. But change is on the horizon.
In early 2022, Unikname Network will enter a new phase of its evolution. For more information about what is coming for Unikname Network and the Unikname project in general, consult our Light Deck. Stay tuned for more info on how this will affect the consensus protocol, coming in a future article. If you want to dive deeper into the inner workings of Unikname Network, the unikname.network documentation is the place to go. Or you can wait for the next installment of the Discover Unikname Network series. Next episode: supply.
Meet Unikname team to get a demonstration and help integration in your project