Introduction
Horizen EON network is Proof of Stake, and already has a large quantity of ZEN providing security through staking to the EON forger nodes. In version 1.4 of Horizen EON, it is proposed to improve the usability of the staking system at the protocol level by automating the reward distribution among the forger hosting provider and the ZEN holders who stake their ZEN to the forger node. The goal of the upgrade is for the staking security system to calculate and pay the stake reward directly to the staker’s wallet address without first going through the forger node itself.
The current method of staking was designed for the EON staking early adopters, those who are able to run their own forger nodes for themselves, with the staking reward of all delegated ZEN paid to the forger node operator, who then distributes it to those who delegated to the node. This system works, but it requires the hosting provider to calculate and distribute the stake reward, possibly leading to both misunderstandings and potential regulator issues.
This update would allow users to delegate stake to forger nodes, with the ability to have visibility over the return they would receive. When forgers are instantiated they would set the percentage of rewards they receive for running a forger (reward share). Delegators would receive the remaining rewards. Forgers will set a contract address to handle the distribution of the rest of rewards to delegators (smart contract address). These two variables (reward share and smart contract address) cannot be changed once set by a forger.
The distribution of rewards from the delegator’s partition will be handled by a smart contract on the EON chain. When setting up a node forgers will be able to choose a contract that will handle distribution for the delegator’s partition. Horizen will provide a standard contract for forgers to use, however any contract can be used. Horizen’s contract will distribute rewards according to the percentage of stake users contribute to a single forger. Any user will be able to claim rewards after it is distributed to a forger for staking on the network.
This new method was chosen to allow forgers to develop their own strategy for distributing rewards to delegators.
Technical Updates
We propose to introduce the following changes:
- Introduce a preliminary registration step for forgers: will be performed by executing a transaction declaring the forger public keys (VRF key and block sign key), the percentage of rewards to be redirected to a smart contract responsible to manage the delegators’ rewards (named “reward share”), and the address of that smart contract. (The last two fields will be optional).
- A minimum amount of 10 ZEN will be required to be sent with the transaction: it will be converted automatically into the first stake assigned to the forger.
- The registration step will not be required for existing forgers owning a stake before the hardfork: they will be automatically added to the list of registered ones, with “reward share” = 0 and “smart contract address” = none.
- Introduce an updateForger() method to allow forgers with “reward share” = 0 and “smart contract address” = none to update the fields .
- The update will be allowed only one time: once set, the values will be immutable. This protects delegators from distribution mechanisms being changed without their knowledge.
- Modify the consensus lottery to consider only forgers owning an amount of stakes (directly or delegated) equals or over to 10 ZEN.
- Modify the reward mechanism to redirect the above declared percentage of the total rewards assigned to each specific forger to the smart contract (if specified). This will include all the existing reward components (forger’s tip, forger’s base fee pool, 5% coinbase from the mainchain). Note there is a delay of two epochs from when ZEN is staked until it is included in the calculation.
- Modify the stakes behavior from an “UTXO-like” to an “account-like” representation: each delegate and withdrawal operation will cause to increment/decrement a total stake balance assigned to the specific key delegator+forger. This will eliminate the notion of “stakeid”, allowing delegators to withdraw funds more easily (the additional signature will no longer be required for withdrawals) and also (optionally) to perform only partial withdrawals of previously staked amounts.
- Add additional methods on the stake native smart contract to allow a fair distribution from a smart contract. These will include methods to return:
- Current consensus epoch.
- Total rewards assigned to the smart contract at a specific consensus epoch.
- Total stakes present at a specific consensus epoch, optionally filtered by stake owner and/or by forger.
- List of all registered forgers.
Benefits
We believe this update will provide the following benefits:
- Provide an easy way to distribute rewards to delegators, without forgers needing to take responsibility for distribution.
- Provide visibility to delegators and the rewards they are likely to receive.
- Protocol changes are not needed if reward distribution mechanics need to be updated.
- Allow for custom reward distribution by forgers. Creative mechanisms can be used to encourage further participation.
- Reduce attacks on the network by providing a minimum staking requirement.
Looking forward to hearing everyone’s thoughts about this update.