Helium State Channels
The People’s Network received a major update on 8/12. From then on, devices required Data Credits to transfer data and Hotspots earned HNT (a new cryptocurrency) for transferring packets, in addition to providing coverage. For a breakdown on how Hotspots earn HNT, go here.
Think of Data Credits as similar to mobile minutes for a prepaid cell plan, only they pay for sensor data instead of voice data. Learn more about Data Credits here. Data Credits can be acquired using a credit card or converted from HNT (via Console).
Our vision is a network that spans the globe with millions of sensors and devices instantly transferring data anywhere.
Given blockchains have scalability issues tied to throughput though, how can the Helium Blockchain verify transactions for millions of devices while continuing to scale?
Layer 2: Off Chain, No Core Protocol Changes
A blockchain uses every node on the network to verify on chain transactions. This core capability secures ledger integrity, and attempts to establish trust in a trustless, decentralized system, but makes blockchains difficult to scale or quickly process transactions.
Millions of devices connecting in an asynchronous manner would make it practically impossible for the main Helium Blockchain to keep up with the volume of transactions.
Since state channels allow the majority of transactions to happen off chain, scalability, and transaction speed can be achieved while maintaining the security of the blockchain.
Layer 2 technologies, like state channels, allow processing of transactions to happen “off chain”, meaning they don’t need to be processed by the main blockchain (layer 1). Layer 2 technologies are built on top of the blockchain removing the need to make changes to the core protocol.
State Channels = Mini Blockchains
Since state channels allow the majority of transactions to happen off chain, scalability, and transaction speed can be achieved while maintaining the security of the blockchain.
The transactions that occur in state channels still need to follow similar integrity rules as transactions that occur on the main blockchain.
State channel participants need to sign and countersign transactions and keep complete copies of the state channel to verify the accuracy of the transactions. From that perspective you can think of state channels as mini blockchains.
However, after signing off, there’s no need to wait for confirmations from the main blockchain.
At any time, the latest agreed upon summary of the transactions among participants could be added back to the main blockchain and be considered valid.
To use an analogy, let’s say a worker and a manager (state channel participants) have a timesheet they use to document a worker’s hours. The worker records hours worked, signs, and shares with the manager who then signs off on the accuracy of the number of hours (transactions) before submitting to the accounting department (blockchain).
The accounting department only cares if the timesheet is the most updated, and signed off by all participants, not all the activities performed during those hours.
For more information about state channels in general, go here.
Helium State Channels
Based on the anticipated network traffic volume from millions of IoT devices constantly transferring data, the team decided to leverage state channels to allow packet transfer transactions to happen “off chain” and not processed by the main chain.
The participants in Helium State Channels are the Hotspot and the Console backend we call Router. Basically, Router acts as the air traffic controller for all data transferred on the network. Either forwarding data sent by devices and sensors on to their desired endpoints or pushing data down to these devices initiated from their owners usually in the form of commands or updates.
For IoT folks familiar with LoRa, think of Router as a combination of the functionality performed by the LoRa network, join, and application servers, as well as the network interface with the Helium Blockchain. More information about Router can be found here.
Opening and Closing State Channels
State channels need to be open to transfer packets, and pay out Data Credits.
To open a state channel, Router sends a transaction to the blockchain requesting a state channel to open to pay for packets offered by Hotspots and ensure packet exchange is accounted for and accurate.
A balance of Data Credits used to pay for packets is moved from the main blockchain to an open state channel. The balance includes an overcommit amount which is used to share among participants to cover any double spend that occurs. One way to think about the overcommit is similar to a credit card hold on a hotel room.
Once opened, a state channel keeps track of how many packets were transferred and by who, how much Data Credits were spent, and which Hotspots should earn HNT for transferring.
This running summary list of signed transactions is continuously updated, kept off chain, and a copy is shared among the state channel participants to ensure trust is maintained.
Every hash is verified which allows the blockchain to account for all packets sent by sensors.
The duration a state channel remains open is determined by a set number of blocks created on the main chain. A state channel will also close if its Data Credit balance is empty and it can no longer pay for packets.
Even if the main blockchain is experiencing issues as long as an open state channel exists with a sufficient balance of Data Credits, packets will continue to transfer and Data Credits will continue to be paid out.
When a state channel closes it provides a final summary of transactions that occurred while it was open and places it back onto the main blockchain in addition to the remaining Data Credit balance including the overcommit (unless a double spend is detected). From the main blockchain’s perspective all it cares about is packet accounting up to the time a state channel closes.
For redundancy purposes, and to ensure there’s continuous packet transfer flow, multiple state channels are kept “open” (active, and backup) and overlap with one another. This means when one state channel expires or runs out of Data Credits, the Router can switch to opening and using a new backup state channel.
At the end of the blockchain epoch all the transactions are scanned and Hotspot rewards for transferring packets are paid out.
Packet Journey from Sensor to Hotspot to Router via State Channels
When a Hotspot receives a packet from a sensor or device, it knows where to send the packet based on its routing table.
With the destination known, once a Hotspot connects to Router the transaction between the Hotspot and Router begins.
A Hotspot verifies that Router has opened a state channel, the duration it’s been open, and that Router has enough Data Credits to pay for the packet.
After verifying the state channel is valid, the Hotspot sends a packet “preview” and an offer to sell Router the packet and cost in Data Credits. Router then accepts or rejects the offer (reasons for rejecting include if it’s a duplicated packet).
If Router accepts the offer, it sends a binding agreement to purchase the packet, the Hotspot validates then the purchase, and if valid sends the full packet bringing an end to the transaction.
Similar to how every node contains a copy of the blockchain, to make sure participants stay trustworthy every state channel participant has a full copy of the state channel.
If a Hotspot sees a version that conflicts with its own version it checks which version is the latest based on a global state channel vector clock which is used to arrange everything in causal order (for more info about a causal order algorithm check here). Every participating Hotspot in the state channel has counters for packets sent and Data Credits.
If the other version is older, a Hotspot doesn’t take action, if newer, then it just replaces its existing version, but if there is conflict and does not have a causal history then you need to combine histories, merge together, and get a superset. This is rare, but could happen due to bad actors trying to double spend Data Credits or tied to a crash or outage.
Start Building, Start Using
The team is continuously tackling challenging problems that arise when building something that has never been built before.
So what does it all mean if you’re a Hotspot owner or want to use the network to connect devices?
It means you can feel confident joining the community and building coverage or using the network knowing the team is hard at work abstracting away the complexity of the network to ensure a simple, streamlined experience for users.
To start using the network, sign up for Console here. To start building the network, go here.
