Unity Consensus — Zero to Hero

Edit: The contents of this post refers to the original Unity consensus algorithm. Please refer to this blog post to learn about the “interleaved” implementation of Unity in the Aion main-net.

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

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

I’m going to 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.

We’re going to use some simple abstractions, often employed in implementation, to describe key aspects of Unity consensus design:

1. Block production algorithm: This algorithm decides who gets to add the next block to the blockchain.
2. Fork choice rule (FCR): This algorithm decides which chain is “the right one”, if multiple chains are simultaneously proposed.
3. 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 (probabilistically) perform a certain number of hash operations (by incrementing the nonce on the block) 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 (stochastic) 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” (network coins) 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, and be online to propagate this block in a timely manner (just like in PoW). Again, we can visualize this process like so:

Look familiar? Just like we 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 (randomly determined process) 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 (roughly) equals each other.

The FCR and the Difficulty Adjustment Algorithms

We’re 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 we’ll focus 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 (forks) 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).

Do You Feel Like a Hero?

That’s it! A lot of details were omitted in this presentation, but hopefully, you walked away with a better intuition for how the Unity consensus algorithm is designed to work.