The Helium blockchain uses a new consensus protocol, called simply the Helium Consensus Protocol.
In designing the protocol, we wanted to emphasize the following characteristics:
- Permissionless - Any Hotspot operating in accordance with the consensus rules and network specifications should be able to participate freely in the Helium Network.
- Truly decentralized by design - No incentive should be available for taking advantage of factors like inexpensive energy cost or deploying more hardware in the same location.
- Byzantine Fault Tolerant - The protocol should be tolerant of Byzantine failures such that consensus can still be reached as long as a threshold of participants are acting honestly. For this, we selected a variant known as Honey Badger BFT detailed below.
- Based on useful work - Achieving network consensus should be useful and reusable to the network. In Nakamoto Consensus-based systems like the bitcoin blockchain, work performed to achieve consensus is only valid for a specific block. By comparison, Helium’s consensus system should perform work that is both useful and reusable to the network beyond simply securing the blockchain.
- High rate of confirmed transactions - The protocol should be able to achieve a high number of transactions per second, and once the transaction is seen by the blockchain it should be assumed confirmed. Users sending device data through the Helium Network cannot tolerate long block settlement times typical of other blockchains.
- Censorship-resistant transactions - Miners should not be able to censor or otherwise select / deselect transactions to be included in a block.
The Helium Consensus Protocol is based on a variant of the HoneyBadgerBFT (HBBFT) protocol. (HBBFT is based on a body of research originally kicked off by Andrew Miller and the team at the University of Illinois, Urbana-Champaign.)
HBBFT is an asynchronous atomic broadcast protocol designed to enable a group of known nodes to achieve consensus over unreliable links. In Helium’s implementation, a consensus group of elected Hotspots receives encrypted transactions as inputs and proceeds to reach common agreement on the ordering of these transactions before forming a block and adding it to the blockchain.
HBBFT relies on a scheme known as threshold encryption. Using this scheme, transactions are encrypted using a shared public key, and are only decryptable when the elected consensus group works together to decrypt them. The usage of threshold encryption enables the Helium Consensus Protocol to achieve censorship-resistant transactions.
A new Consensus Group (CG) is elected once per epoch. Currently there are 16 members elected to each consensus group, as defined in the num_consensus_members chain variable. As of HIP 16, all Hotspots active on the Helium Network are eligible to be elected to a consensus group and are selected at random.
In addition to random selection, a geographic filter is applied to ensure there is adequate location diversity. The Helium blockchain uses a system called H3 for all aspects of geospatial representation within the network. H3 lets you index a space into hexagons of varying resolutions, ranging from H0 to H15,with each level representing a different hexagon size. (The full breakdown is here.) Currently, we use the H4 resolution as the filter for eligible Hotspots for a CG. Put another way, in an ideal election, no two Hotspots within the same H4 resolution - roughly 658.5 square miles - should end up in the same CG.
Each election uses a phased approach to migrating out only a subset of the existing Consensus Group Members out over a series of epochs. Specifically, each new Consensus Groups retains 12 of previous 16 members. This is done to make additional use of the CG members that have already been elected and have proven their ability to mine blocks and distribute HNT. Put another way:
- Each election, typically four new Consensus Group members are elected. The other 12 are from the previous CG election.
- Once elected, a Hotspot can typically be part of up to four consecutive Consensus Groups.
- Poorly performing CG members are likely to be deselected before their four epoch limit is reached.
- Once a Hotspot is deselected from a Consensus Group, it's not eligible to be elected to another group until the other 15 members that were in its group are completely cycled out. This would be four elections into the future.
Following the election of a new Consensus Group, a distributed key generation phase occurs to bootstrap the threshold encryption key (TPKE). This TPKE is a cryptographic primitive that allows any Hotspot in the network to encrypt transactions to a master public key (PK) such that the Consensus group must work together to decrypt it.
Hotspots are constantly submitting new transactions to the current consensus group. As they arrive, each consensus group member takes a random subset and forwards them around to other members of the group after encrypting them with their share of the master public key.
At the end of each epoch, mining rewards are distributed by the consensus group to the wallet addresses that have earned them. Currently 65% of all mining rewards go to the hotspot infrastructure (with the remaining 35% being distributed to Helium, Inc and other network investors). A graphical overview of token reward system can be viewed here.
During the course of any epoch, Hotspots are rewarded for the following list of activities:
- Submitting valid proof of coverage challenges (as a “challenger”)
- Successful participation in proof of coverage as a target (as a “challengee”)
- Witnessing a proof of coverage challenge
- Transferring device data over the network
- Serving as consensus group member
The Consensus Group members also split 6% of all HNT mined, as well as any transaction fees collected during the epoch.
Each one of the above activities is recorded in a block using the reward transaction. At the completion of each epoch, all the individual reward transactions are grouped in a rewards transaction at which point all HNT mined in that epoch are distributed.