Development

GitHub metrics:

Developer activity (from Coinlib.io):

For the non-techies out there who want to learn how Unity works, the Aion team explains what makes this consensus algorithm tick! If you’re technically inclined, you can read the Unity pre-print.

Back in May, the team released the first draft for the Unity consensus algorithm; read this to learn more about why they’re excited about Unity and how it’s different from Aion’s current consensus. As implementation on Unity heads underway, the team wanted to answer the question that they most often get from the non-technical community: “how does Unity combine Proof of Stake (PoS) and Proof of Work (PoW)?”.

The authors assume you know what a Blockchain consensus algorithm is and at-least vaguely know the mechanics of Nakamoto’s consensus algorithm, popularly known as “Proof of Work” (PoW).

The first thing you need to know about Unity is that it’s a hybrid consensus. Depending on who you talk to, the term hybrid consensus carries a different meaning. In the context of Unity, hybrid describes the fact that both, the hash power produced by miners, and the stake owned by Aion coin holders, is combined into a mechanism that reaches consensus on the blockchain state.

They uses some simple abstractions, often employed in implementation, to describe key aspects of Unity consensus design:

Block production algorithm: This algorithm decides who gets to add the next block to the blockchain. Fork choice rule (FCR): This algorithm decides which chain is “the right one”, if multiple chains are simultaneously proposed. Difficulty adjustment algorithm: This algorithm adjusts some system parameter called “difficulty”, to get you a target block time (e.g. 10 seconds in Aion).

Block Production Algorithm

Proof of Work Block Production

Let’s start with the example you’re most likely to be familiar with: Nakamoto consensus. Blocks are “produced” via a lottery; your chances of being chosen to propose a block at any given height depends on the hash power you own, in-proportion-to the rest of the network. Based on the difficulty parameter, you’re going to have to perform a certain number of hash operations to get a “hit”. If we draw a box around this mechanism and call it a “block production algorithm”, we can visualize it like so:

Proof of Stake Block Production

Proof of stake (PoS) is yet-another term, that can mean different things to different people. There are several different strategies in the wild to incorporate stake into a consensus algorithm in order to secure a blockchain. Unity uses a particular PoS strategy that simulates a randomly determined process, in the spirit of Nakamoto consensus.

Let’s try to understand this particular flavor of PoS in isolation, before we talk about how Unity hybridizes it with PoW. So, assume you have a pure PoS blockchain; in this blockchain, blocks are “produced” via a lottery; your chances of being chosen to propose a block at any given height depends on the “staking power” you own in-proportion-to the rest of the network. As a function of your secret key, proportion of stake in the network, last block and difficulty, you are assigned a time randomly according to some distribution. To “win” this lottery, you need to have the minimum amount of time of all the online stakers for that block height, andbe online to propagate this block in a timely manner. Again, we can visualize this process like so:

Look familiar? Just like mentioned before, this flavor of PoS mimics the dynamics of the proof of work algorithm most people are familiar with. Here lies the key to achieving the hybridization proposed by Unity.

Unity Block Production

What unity does, is that it runs the PoW and PoS algorithms concurrently! Since the PoS algorithm is tuned to produce blocks with the same distribution as PoW, blocks produced by both algorithms can be interleaved into one chain. We can visualize like so:

Notice that there is no order imposed on PoS and PoW block sequencing, but at the end of the animation, the number of PoS and PoW blocks equals each other.

The FCR and the Difficulty Adjustment Algorithms

The authors are not going dive into exactly how the FCR and the difficulty adjustment algorithms are specified to work (please read the paper to learn more); instead they focuses on the problems these algorithms solve in the context of this design and why they play a key role in making Unity tick.

Due to the randomness involved in the block production algorithm, at any given block height, we might have multiple chains that contend to be “main chain”. The Fork choice rule (FCR) in Unity is designed to efficiently choose some heaviest chain based on the combined difficulties of the PoW and PoS block production processes.

Another problem that comes up in this hybridization work is how to keep the block production fair between PoS and PoW (i.e. both processes produce 50% of the blocks over time). The Difficulty adjustment algorithm makes the distribution of blocks equal over time by targeting a block time for each block production algorithm that is twice the target block time (e.g. 20 seconds in Aion-Unity); this way, due to the way the conjectured distributions of the block production processes “add together”, you end up getting a block produced at the target block rate (e.g. 10 seconds in Aion-Unity).

Check out Unity Consensus Feedback Form.