Over at the ARRT team at Aion we’ve been grovelling over some definitions regarding blockchains. This time the debate occurred while we were seeking designs for a Proof-of-Stake implementation approach. It starts with a very simple question, what is a blockchain? What traits and attributes must a network contain to warrant this definition? With the varying implementations and security assumptions made by different networks nowadays, it becomes difficult for us to speak clearly to the defining trait of these networks. In fact, everyone in the team has varying opinions on how they should behave.

Are we to believe it is the immutability of the ledger? If so we should opt for more traditional BFT designs that favour finality and immutability. Or rather is it the probabilistic finality that Nakamoto Consensus offers, which favours a highly available network over consistency and immutability? Within the team, there was no clear agreement. Nonetheless, we could be guided by our intuition: that the design of our system should try to adhere to the environment it operates in.

Our previous experiences taught us that consistency favouring network protocols demands increased communication complexity, and may be incongruent with the inconsistent channels that existed between nodes. This is especially exacerbated if one chooses to enable random sampling (thus require dynamic reconfiguration of network routes) and indirect links between nodes through gossip protocols.

Another point of view we had was a focus on the degradation of the protocol. This is best illustrated by a question one of my colleagues asked:

What happens when no one participates?

We wanted to build something that degrades in a manner consistent with expectations, changes in the network are reflected eventually by changes in the protocol, and a stable equilibrium is at some point reached without external assistance. The system should scale to handle the capacity of users it encounters, not make any demands on a minimal or maximal set. From here, we had clear goals on what we wanted to achieve with Unity:

• Increase the security of the network by introducing economic security via Proof-of-Stake.
• Adaptable to network size and topology.
• Lower barrier of entry to participate in network security via staking.
• Represent a progression in Aion, simple to implement.
• Retain probability distribution introduced in PoW (see below).

The main property we want to preserve from the traditional PoW protocol is that the function of network security is linked to the relative “power” of the adversary as opposed to a function of the network (assuming a well-defined configuration). For Proof-of-Work that it would be linked to hash power.

And that led us to Unity.

Unity

At its core, Unity removes direct ties between chain weight (and therefore network security) and a singular resource. Instead, we abstract the idea of chain weight and tie it to an intermediate unit that consolidates both the computational power of miners on the network, as well as the relative stake of the active staking set on the network. This mostly relies on changes to the fork selection rule to account for both hash and staking power.

We make no additional assumptions about the network itself and introduce a new state mapping that represents the amount of active stake an address currently holds. Additionally, no assumptions about the structure of the blockchain are made, PoW and PoS blocks are mined and created by miners and stakers respectively, and arrive in random order. In this schema, Proof-of-Work (PoW) remains the same. It is the game of deriving a successful solution against some difficulty parameter that is being dynamically adjusted to adhere to some pre-determined network configuration. One of the challenges we face here is in experimenting with different adjustment algorithms and finding a fit.

On the other side, we adopt a protocol that uses private random number generation for a Proof-of-Stake (PoS) process that emulates the stochastic process of PoW. This is done by having each staker generate a unified random variable that remains private until the publishing of the block. This unified random variable is applied to a function that biases “winning” the block proportional to their stake. The result is a randomly generated ranked list at each new block, with the winner unknown until the result (the block) is published. This preserves the unpredictability property similar to PoW. To prevent the network from being flooded by every staker publishing, the selection of stakers eligible to publish grows by the second. This mechanism provides similar properties and emulates a PoW setup, where the luckiest account (the first to hit the lowest nonce) wins the block. Here, the luckiest account is explicitly chosen by the protocol. We can also see from this emulation that similar to PoW, there must be a dynamic parameter to be adjusted by the network as active stake fluctuates. Similar to PoW, this difficulty parameter shifts in responses to change in stake (inferred by change in time).

Our simulation results indicate that the probability distribution of this protocol (assuming the same expected value as PoW) is also an exponential distribution.

The initial results seem promising, both PoW and PoS systems depict a roughly exponential distribution inferring that both are Poisson processes as both processes roughly adhere to the exponential distribution in block time deltas (see figures above). By combining the two, the end result we obtain is yet still a Poisson process. Assuming that the fork selection rule holds, we obtain a blockchain:

• Whose security derives from both PoW (hardware security) and PoS (economic security). Making the network resilient to attackers without sufficient investments in both.
• That maintains the randomness from PoW systems and can be argued to be still close to a Poisson process.
• Scales well regardless of the size of the network.
• Has a low barrier to entry, as we don’t require any delegation (but it is available if wanted), and the barrier to entry on both sides is minimal.

In conclusion, we set out with a specific goal at hand primarily influenced by the teams previous experience with different consensus protocols. While the initial groundwork is now done on Unity, the team is working hard on simulations to further verify our results in more realistic settings and possibly working on a PoC TestNet running Unity. There is still work to be done on fork selection and slashing mechanisms for Unity, something we touch upon more in the draft paper available here. Once we’re comfortable with the results, we will immediately shift gears to merge Unity into its own TestNet and make it available for you to play with.