- Authors: @zer0tweets (Boris Renski), Joey Padden
- Start Date: 2022-01-04
- Category: Economic, Technical
- Orignal PR: helium#341
- Tracking Issue: TODO
- Status: In Discussion
HIP 51: Helium DAO provides a general structure for onboarding new WNPs to the broader Helium Network, with mechanisms in place to ensure that protocol-specific attributes such as proof-of-coverage rules, data credits pricing, and block validation are within control of the emergent WNT DAO.
In this proposal, we specify the implementation of the structure proposed through a detailed onboarding proposal for the 5G Network. We propose initial configurations of the 5G economics layer as well as governance mechanisms within the DAO through Mobile Network Token (MNT) token voting.
This proposal impacts all current and future participants in the Helium Community.
We proposed in HIP 50 that each WNP subDAO operate as a sovereign economics and governance layer. The 5G subDAO has five core functions
-
Economics The 5G subDAO handles all bonding curve operations, and by extension all MNT emissions to hotspots and purchases or sales from third-parties. The economic responsibilities around this involve parameter selection for the curve and all associated fees, as well as liquidity risk management.
-
Network Participants 5G subDAO coordinates economic activity between a number of network participants with various functional roles. A single entity can implement one or more of these functional and economic roles. The economic responsibilities include definition of network participant roles, minimum stake amounts, and rewards for participation
-
Validator Operations 5G validators perform a number of roles, including consensus group work, settlement account with inbound roaming operators, and network ingress/egress relay. 5G subDAO responsibilities here include definition of validator software, minimum stake amounts, and rewards for participation.
-
Proof-of-Coverage Mechanisms The 5G network utilizes a Proof of Coverage work algorithm to verify on an ongoing basis that hotspots are accurately representing their location and the wireless network coverage they are creating from that location. Responsibilities here include Proof-of-Coverage challenge construction, target selection, reward scaling, and verification.
-
Data Transfer Mechanism and Pricing Data transfer across the network occurs via the process of procuring and burning data credits in the name of the hotspot or set of hotspots that provide coverage. Responsibilities here include Organizationally Unique Identifier (OUI) registration, state channel creation, and bandwidth capacity per data credit definition.
-
Governance The 5G subDAO retains full control over all components of the network, and DAO members can propose and vote for changes to core parameters and mechanisms. Responsibilities here include specification of a formal on-chain voting process that is resistant to attacks.
In the notation provided below, P represents Price and S represents Supply. The quote currency is MNT (Mobile Network Token) and the base currency is HNT (Helium Token).
We propose that the 5G bonding curves take the shape P = S^k where k = 1.1.
For a given amount of HNT deposited to or withdrawn from the 5G bonding curve, the increase or decrease in MNT supply and price is given by the resulting change in the area under the curve. The integral is given by:
The curve looks as follows:
At the end of a given epoch, the L1 HNT emissions contract performs a tally of the data credits transferred across the 5G Network. The emissions contract subsequently distributes the determined amount of HNT to the 5G subDAO multi-signature wallet, the addresses of which comprise the set of validators of the 5G Network.
There are several types of participants in the 5G DAO, which are defined by their functional and economic roles. A single entity can perform multiple functions at the same time.
| Participant | Functional Role | Economic Role |
|---|---|---|
| Subscriber | Uses the network | Pays to access data on the network. |
| Witness | Runs a witnessing app on the phone to verify coverage provided by the hotspot hosts. Witnesses are required to be a subscriber. | Receives MNT mining rewards for witnessing coverage. |
| Witness App Vendor / Service Provider | Promotes network service to subscribers. Issues sim cards to witnesses. Maintains the witnessing app. Responds to witness support queries. | Receives payments for data access from subscribers. Pays Federation & Settlement validators for data on the Helium network. *Stakes MNT to receive % of witness rewards as a function of data sent to the network |
| Hotspot Host | Operates a 5G hotspot and pays for backhaul. | Receives MNT mining rewards for providing coverage. Receives MNT mining rewards for providing data access to subscribers. |
| Hotspot Vendor | Builds and sells hotspots. Supports hotspot hosts. Runs Magma Orchestrator to Facilitate OTA updates of hotspots. Operates onboarding server. | *Stakes HNT to receive % of MNT rewards mined by hotspot hosts, as a function of data sent through them. |
| Federation & Settlement Validator | Authenticates inbound roaming sessions by running a Federation Gateway instance.Records data transfer transactions to state channels by running session purchaser instance. | Gets paid by the service provider. Stakes MNT to receive % of processed transactions. Pre-burns MNT to DC |
| Consensus Validator | Runs a consensus validator node | Stakes MNT to receive % of consensus group tokens. |
We propose that the 5G DAO distributes MNT in the following proportion after minting the given number of tokens per epoch if the Notional Value of Data Credits Transfer (X% of Hotspot emissions) across the WNP is Less than Market Value of MNT Tokens Allocated to Hotspots.
Note that all manufacturers within the network must stake a minimum of 10,000 MNT tokens in order to be whitelisted to receive rewards. If at any point, a manufacturer gives ownership of maintenance and firmware upgrades to a third party, all future manufacturer rewards flow to this new entity. The new hotspot onboarding fee and location assertion fee should be identical.
5G validators perform the following functions:
- Proxy 5G signaling traffic that allows inbound data offload operators to authenticate subscribers in the HSS database to attach to the Helium 5G hotspot nodes (aka host Magma Federation gateway nodes)
- Confirm transactions and add blocks to the 5G L2 chain. They serve state data around Proof-of-Coverage challenges
- Run cellular settlement infrastructure and session purchaser (as described in Data Credits and Pricing section below)
Validation is performed by a set of rotating nodes known as the consensus group, which verifies transactions and ordering prior to forming a block and proposing it to the L2 chain. Consensus groups are elected once per epoch, and the number of members is given by the num_consensus_members chain variable (currently set at 40).
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 Validators 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.
At the end of each epoch, mining rewards are distributed by the consensus group to the wallet addresses that have earned them.
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.
The 5G subDAO is required to constantly interrogate 5G hotspots using the Proof-of-Coverage challenge mechanism to ensure that hotspots are representing their locations accurately. The results of each of these challenges are relayed to the Helium L1 after being validated by their respective consensus groups.
PoC implementation proposed in the Helium LoRaWan sub-dao is based on wireless coverage being verified through LoRa hotspots issuing “challenges” to “challengees” and “witnessing” over the air interface. However, for the 5G wireless protocol, radios cannot both challenge and witness the packets over the air, as the 5G/LTE and other cellular protocols are designed for the radio to interact with a UE (such as cell phone) vs another radio. Moreover, because the use case we are pursuing is not to build a stand-alone network that will blanket the world (like in IoT case) but to create an offload network that can effectively complement macro network of an operator, the usefulness of the cell is determined by a) number of UEs in proximity that are capable of connecting to it; b) comparative RSSI of offload operator macro-cells in proximity. Usefulness should not be a function of location relative to another cell on the Helium network, as is the case with LoRa.
For 5G subDAO we propose to separate the challenge and witness function(s) for 5G PoC between the operator of a hotspot and an iOS/Android app (aka eSIM app), as follows:
- 5G hotspots on the network (regardless of wireless protocol) perform “the challenger” function by issuing randomly targeted challenges every N blocks
- 5G Hotspot operators pick-up 5G challenges and cache them for N blocks until witness cell phones that attach to the hotspot
- Cell phone owners with the witnessing app installed will “witness” that the hotspot is, indeed, active and radiating signal, and submit the confirmation back to the blockchain.
Following the completion of the above, both the 5G hotspot operator and the cell phone owner with the eSIM app will receive their respective “challenge” and “witness” rewards.
From the implementation standpoint, we’ll work to re-use the PoC mechanism implemented in LoRa DAO. Table below shows the mapping between steps in the current PoC mechanism and their cellular counterpart.
| LoRa PoC | Cellular PoC | |
|---|---|---|
| 1. | Challenger, that can be any node on the network, writes a transaction on chain as a request. Currently happens once every 480 blocks. | A 5G gateway issues a cellular challenge every N blocks and writes challenge transaction to the 5G L2 chain. |
| 2. | Challengee tries to decrypt all requests from chain and notices they’re being challenged. | 5G miner with cellular radio attached plays a role of Challengee and tries to decrypt all requests from chain and notices they’re being challenged. |
| 3. | Challengee sends receipt to challenger via libp2p | Challengee waits for a period of N blocks for a phone with eSIM app to come in range and attempt to attach. When a witness phone attaches to the challengee cell, challenger cell sends a receipt to the challenger via gRPC and appends witness IMEI. |
| 4. | Challengee sends beacon over radio. | Challengee accepts the attach request(s) from a witness phone running an eSIM app. Challengee sends the challenge packet to the witness over the air, immediately following the attach. |
| 5. | Witness sees packet over radio | Witness phone with eSIM app receives packet from the challengee over radio. |
| 6. | Witness finds matching “onion” in a recent request transaction. | eSIM app appends it’s IMEI, and witness key to the challenge packet. |
| 7. | Witness sends receipt to challenger via libp2p. | eSIM app sends above data + receipt to challenger over gRPC, once it is no longer attached to the challengee cell. |
| 8. | Challenger combines receipts and writes receipt on chain. | Same as Lora, challenger combines receipts and writes receipt on chain. |
Once the Challenger has the complete set of receipts from the POC Witnesses and Transmitter, or the elapsed time since the challenge was issued has passed the upper time bound, the POC Challenge is considered complete. At this point, the Challenger then submits the proof receipt as a transaction to the blockchain to be verified by the current consensus group. Because the steps taken by the Challenger to construct and complete the proof are deterministic and easily reproduced, members of the consensus group can verify the legitimacy of the proof. Specifically the Challenger reveals the secret ephemeral key it used for both obtaining the original PoC request and for encrypting each layer of the challenge packet. This crucial information, which has been hidden until the receipt is published, allows the re-creation of the deterministic entropy.
5G DAO will set its own variables, yet reuse the logic from HIP 15 and 17 for scaling rewards to 5G hotspots based on placement as per target density of hotspots in a given geographic area as well as number of witnesses to challenges participated in.
Data Credits are utilized in asserting new hotspots and their location on the chain, registering Organizational Unique Identifiers (OUIs) and associated devices, and as payment for packet transfers.
Helium 5G sub-dao will operate a set of 5G L2 chain variables that will dictate the conversion ratio between Data Credits and MNT tokens, denominated in oracle USD price. Changes to the conversion ratios will be conducted following Sub DAO governance specification.
The initial set of DC conversion variables will be as follows:
- Price to onboard a new 5G hotspot (aka register a new OUI)
- Price to assert location of 5G hotspot
- Price per GB of 5G data (denominated in $$ per 66 byte LTE packet)
Roaming agreements require settlements where the visited network exports the data records as measured at the SGW (running on the 5G miner) towards the offload operator. The offload operator may or maynot use a clearing house.
Without clearing house: The records as raised by the visited network translate into invoices at price per GB defined by the 5G DAO governance. The typical window for this is monthly settlements.
With clearing house: The visited network raises records in a standard format like Transferred Account Procedure(TAP) which the clearing house rationalizes with billing records seen in the network of the offload operator based on some pre agreed rules. The settled data records are exposed to the visitor network typically on a monthly window.
Facilitating such settlements will require that an offload operator (or some 3rd party intermediary) run a validator instance that, in addition to acting as a member of consensus group, also operate the following infrastructure:
- Session purchaser instance. Operators of 5G Session Purchaser will maintain a certain pool of data credits pre-burned from MNT tokens that can be used to facilitate traffic offloading. Pre-burn can happen either immediately pri to authorizing an offload section or some time in advance
- Magma Federation Gateway instance that will proxy 5G signaling traffic that allows inbound data offload operators to authenticate subscribers in the HSS database to attach to the Helium 5G hotspot nodes
The following diagrams describe the UE session attach, update and termination call flows between the following components of the system:
- UE - a cell phone or any cellular device connecting to Helium 5G network
- eNB - a 5G or LTE radio attached to the 5G hotspot
- MME/SGW - components of Magma network core running on the 5G hotspot
- Miner - code responsible for parsing/interacting with 5G L2 blockchain running on the 5G hotspot
- Session Purchaser/ESB - a validator instance that also incorporates a session purchaser (as described above) that is run by either the offload operator or a 3rd party intermediary
- State Channel, Blockchain
- Home EPC - network core infrastructure (specifically HSS and OCS/PCRF) of the offload operator
| Fig.1 - Attach Call Flow |
|---|
 |
| Fig.2 - Update Call Flow |
|---|
 |
| Fig.3 - UE Termination Call Flow |
|---|
 |
| Fig.4 - Network Termination Call Flow |
|---|
 |
Every aspect of the 5G Network is under the control of the subDAO. All subDAO proposals must come attached with code to be approved.
We propose the following governance mechanism borrowed from HIP-41 in order to impose enough of a cost on voting that only committed participants would vote to influence the direction of the network, while ensuring that the barrier to entry is low enough for all small holders to participate should they choose.
The core primitive of this proposal is “voting power”, the unit of support for either side in a given vote.
Network participants can deposit MNT tokens to a “governance staking contract”, which are locked and delegated to one or many validators of their choosing. Users have control over the number of tokens they choose to stake, and the period they choose to stake them for.
The minimum lockup period is 250,000 blocks and the maximum lockup period is 2,500,000 blocks (these values can be changed retroactively via this governance mechanism).
A user’s voting power is determined by 1) the amount of MNT they vote with, and 2) the amount of time they commit to locking up their tokens. The structure applies a linear multiplier of time to the amount of MNT locked up in the voting contract. For the maximum amount of 2,500,000 blocks, users receive 50x the voting power. For the minimum amount of a 250,000 block lockup, users receive 1x the voting power.
As a simple example, let’s imagine Alice, Bob, and Charlie all have 100 MNT:
- Alice chooses to lock up her tokens for the minimum required 250,000 blocks, and thus her voting power is 100
- Bob commits to locking up his tokens for 1,375,000 blocks, and thus his voting power is 25 * 100 = 2,500
- Charlie commits to locking up his tokens for 2,500,000 blocks, and thus his voting power is 50 * 100 = 5,000
As the lockup burns down, so does the voting power. For example, if Charlie locked up his 100 tokens for 2,500,000 blocks and 1,125,000 blocks have passed then Charlie would have 2,500 vote power.
Governance proposals can be called to a formal vote with a minimum of 1,000,000 voting power (“vote minimum”), and users will be able to participate in each vote for a period of 7 days (“voting period”). These thresholds are placed to mitigate risk of DDoS attacks, but both parameters will be tunable by this same voting process at any time.
Note that the voting power used to call a vote is eligible to vote, so the user that calls for a proposal to be voted upon can allocate their stake to either side. At the end of the voting period, the governance staking contract looks at how many tokens a voter has and how long they are locked for. Voters can always extend their lockup period just prior to voting. Locked tokens can vote as many times as they want, and all earnings from staking are earned by voters as normal staking rewards.
One of the challenges with the locking mechanism proposed here is that most participants will wait until the last minute to vote. This is because there is a cost—namely, giving up liquidity—to vote. As such, if a vote is going someone’s way, they may not want to participate and lock up tokens. In order to incentivize honest voting and maximal participation, we propose that 5G DAO governance adopt a commit-and-reveal scheme. With this feature, votes would be submitted in a concealed fashion. Upon the completion of the voting period, we propose a 3 day reveal period in which voters can review the results of the vote, including who voted.
Commit-and-reveal can be implemented by having voters hash together their address, vote, and salt. Once the reveal period begins, voters can reveal their votes by publishing the unhashed data. If voters don’t reveal their vote before the reveal period, their vote is not counted.
The result of this should be maximal participation for important decisions because voters won’t know whether their vote will matter or not.