This article was first published on Stories by Aion on Medium
At the heart of the Unity Consensus are the staking and stake delegation mechanisms, which are responsible for managing staker registrations and stake updates. In this article, I will walk you through the design considerations we’ve made and the implementation details. The source code is available at https://github.com/aionnetwork/protocol_contracts.
NOTE: This article is an overview of the current state of the Unity Protocol Contracts, which are still in their infancy stage and are constantly evolving.
Any Proof-of-Stake(PoS) based system needs a way of managing the stake state, i.e. the registered staker list and the amount of stake of each staker at any time. This piece of information decides the eligibility of a staker to produce a PoS block, and has to be agreed on by the whole network.
The stake management is traditionally implemented within the client (software that a node uses to connect to the network), using purpose-specific transaction types, with the utilization of databases or data storages. This is mainly due to the lack of programming capability above the protocol. The consequence of such a design is to make the protocol itself heavy and fat. As a result, it’s very difficult to implement such a system, given that there might be multiple clients in different programming languages.
In the Unity Consensus, we implement the staking and stake delegation mechanisms in AVM smart contracts. Such a design choice gives us two advantages:
- The execution and storage model of a smart contract is well defined, so it will be cost-free to ensure consensus on the stake state;
- The user interaction will be simple, as a user can interact with a smart contract using existing transaction infrastructure (no extra tool is required).
Staker Registry Contract
First, let’s take a look at the staker registry contract, which is the endpoint to all ...
To keep reading, please go to the original article at:
Stories by Aion on Medium