- Author(s): @evanmcc, Helium Team
- Start Date: 2021-01-11
- Category: economic, technical
- Original HIP PR: #110
- Tracking Issue: #111
Add a new class of actors to the network, called Validators. These will be staked actors, with the intention being to run them on stronger hardware with better network connections than the current Hotspots. They will serve the dual purpose of being eligible for block production and also, in the future, acting as proxies for lightweight (non-chain-following) gateways.
At the current rate of growth, running block production directly on the Hotspot network is rapidly becoming unsustainable. Gossip network usage grows linearly with the size of the network, and slow addressing updates are a common cause of long block interval times.
Legacy hardware power and size also put sharp limits on the size of the group (and hence its security). The fact that addresses aren't static also makes it difficult to reconnect when a Block Producer crashes, also leading to longer block times. Low powered hardware on consumer-grade internet backhaul is much more subject to DoS attacks than high-end servers on cloud-grade connections.
There are also several sub-optimal measures the core team has had to take in order to keep block times consistent on the current hardware, such as a timeout on PoC transaction validation and adjusting the PoC challenge interval, that have led to undesirable side effects.
Lastly, the network is today heavily dependent on our libp2p implementation and its ability to navigate consumer firewalls, proxies and NAT configurations. Given the complexity and variety of these setups, as well as the design of the PoC system, this has led to an appreciable percentage of all PoC challenges failing to have a corresponding receipt. While not all of these can be attributed to this situation, we believe a significant number of them are. By moving to the Validator model (and eventual changes to PoC challenge construction), Hotspots will no longer be dependent on delivering PoC receipts to other Hotspots via libp2p.
While this HIP affects everyone in the network, the only real effect is that ordinary Hotspots will not be able to participate in block production, leading to a loss of the “random” HNT flow (6% of total HNT mined) to the Hotspot pool. The participants most affected by this change are those interested in running Validators.
We also expect the Testnet process, wherein we will stand up a separate network of Validators for testing purposes and to allow Validator runners to gain operational experience, to generate interest from outside of the community, as there exist professional Staking and Validator Pools for other blockchains.
To make this happen, we would make a new ledger entry type for the Validators. This entry would have the Validator's stake level and the owning account, and any other required metadata. All HNT earned by the Validator will go into the owning account.
We would also add 7 new transactions (the exact details of which are likely to change):
gen_stake: validator pubkey, owner pubkey, initial stake, description: genesis-only txn creating a validator for testing.stake_validator: validator pubkey, owner pubkey, initial stake, description. Owner account is the funding account and description is a short public string that can be used to identify the validator., creates the validatorchange_description: validator pubkey, new description. Changes the validator's public description string.add_stake: validator pubkey, amount. adds stake to the validator, requires the owner's signature, funds come from the owner's account.reduce_stake: validator pubkey, amount. removes stake from the validator, cannot bring it below the threshold. The removed stake will be returned to the owner's account after the cooldown period; requires the owner's signature.transfer_stake: new validator pubkey, old validator pubkey: moves a stake from key to key, keeping the same owner and metadata, in the case a key gets compromised.unstake_validator: validator pubkey: this starts the unlock process for the stake, returning it to the owner's account after some cooldown period. the validator is immediately unable to join block production groups, but re-staking will restore the validator to eligibility.
- Activation Threshold: minimum number of staked Validators to start using them for elections. After the Activation Threshold is met, the next election will produce a list of Validators rather than draw from the full Hotspot pool. After the Threshold is reached and the chain variable is active, we will no longer go back to selecting from the Hotspot pool. The initial proposed value here is 100 Validators.
- Activation Delay: the number of blocks after which (once the above threshold has been met) the group will start moving to the Validator pool. Unstaking to below the activation threshold during the delay period will cancel activation.
- Minimum Stake: the minimum number of HNT that need to be staked before the Validator can be created and considered for Block Producer elections. The proposed initial value for the minimum stake is 10,000 HNT.
- Cooldown Period: The number of blocks after staking when the stake is returned to the owner's account. Proposed initial value is 250,000 blocks, approximately 5 months.
Stake is unlimited, and any stake over the threshold adds to the chance that a spot gets elected as a block producer. In order to reduce the ability of overstakers to dominate block production, additional stake will need to have diminishing returns. Eventually a mechanism will be added to delegate Hotspots credibility to Validators which will also influence elections.
Please see open questions for how overstake may be applied to returns. We expect a discussion in the community to help resolve exactly how this should work and will update the HIP to reflect that discussion.
Validator nodes will need large disks for storing the chain and the ledger, and strong (but relatively modest by modern server standards) CPUs and RAM. An AWS T2.large or xlarge should work fine.
The node will need to have a static IP and few ports (currently 2154 and eventually port 443) open to the internet. A DNS resolvable URL is strongly recommended. Networking speed is variable, but load is largely symmetrical when producing blocks, so good upstream is recommended. Most cloud machines will be fine, but e.g. a cable modem might struggle. We don't recommend running these machines on consumer network connections.
While this does lock "average" users out of the block producer's pool of returns, that pool shrinks, relative to each individual spot, as the network grows.
Realistically, there is no alternative that allows for large network growth other than getting block production onto bigger and more secure CPUs.
- What other designs have been considered and what is the rationale for not choosing them?
Other designs:
- Cloud Miners: Each Hotspot has a proxy in the cloud that is responsible for running its block production responsibilities and watching the chain for PoC responsibilities. Since each cloud validator is rarely in the consensus group, this leads to weird provisioning scenarios and multi-tenancy issues. If a miner can assume that it will be in the group relatively regularly, it's easier to cost out and simpler to do capacity planning for (and avoids collisions where an overcommitted cloud miner cluster gets too many members at once).
- Most DIY Hotspot setups follow the same model as Cloud Miners
- Switching to another chain to run on has been determined to be currently infeasible due to limitations on storage and private computation
-
Why is this design the best in the space of possible designs?
- I've added some details in the above section, but in addition to those benefits, this also leads to a very clean separation of responsibilities between spot owners and validator runners, whose jobs do not look especially similar.
- Allows us to scale the network better as more light gateways and full nodes get added to the network.
-
What is the impact of not doing this?
More and more resources will need to be poured into the P2P aspect of the design, and we'll eventually need to add a layer of "stronger" validators in any case to keep up with transaction scaling. Since we're always going to be held back by slow/lower memory group members, we will be limited in the complexity of the features that we can add and the stability of the network will continue to suffer.
- How does overstake affect election chances? Linearly? Diminishing returns? etc.
- What are the most desirable evolutions for this feature that are too complicated for the initial version?
- Do we want to limit (at least initially) the number of nodes in order to put a floor under earnings? We could link this to the on-chain oracle price, potentially.
Deployment impact will be minimal, other than an increase in the stability of block times.
We should see an increase in the stability of block times.
We should be able to increase the number of validators in the block production group without disruption.
We should see people eagerly staking new validators as a measure of the appeal of the idea.