Helium is a peer-to-peer wireless network that supports IoT devices.
The backbone of The People’s Network is the Helium Hotspot, a new wireless device for the Internet of Things (IoT) that provides connectivity 200 times farther than Wi-Fi thanks to Helium’s open-source “LongFi” technology and transmits data at a fraction of the cost than cellular. Hotspots also act as miners on the Helium Blockchain, incentivizing anyone to deploy a Hotspot and earn a new cryptocurrency, Helium (HNT), for building the network and transferring IoT device data. A single Hotspot can support thousands of IoT devices, yet only requires as much power as an LED light bulb (5W). Only 50-100 Hotspots are needed to provide coverage for an entire city.
Consumers across the U.S. can purchase Hotspots and help build the world’s first peer-to-peer wireless network that belongs to the people and takes the IoT outside in a way that the traditional telecommunications industry can’t.
From the Helium Medium:
The Internet we have today dates back a long, long time. Back in the days when the ARPANet was designed, which eventually became the Internet, there were only a handful of sites participating, mostly Universities. In those days, when the early services that underpin the internet like BGP, DNS, and SMTP were designed, the designers assumed that the operators of those services would operate in good faith. The community was small and everyone knew everyone else, or at least knew where to find them.
As the years passed, more and more people gained access to the Internet and the strong identity and responsibility around using and operating services began to erode. Today many critical internet services rely on simple access control to secure them from attack and much effort is expended in the resulting arms-race between people trying to profit from attacking the Internet and those trying to defend it.
The challenges of a centralized trust model for IoT
Fast forward to today, and with the IoT, we’re trying to extend the Internet, with all its naive trust in the network, to tiny devices with little RAM and a very thin pipe back to the internet. The big problem of Internet security doesn’t fit well on a microcontroller.
One way of solving this is to introduce a trusted party that the devices look to for instructions and relay all their traffic through. By necessity these systems are a centralization point, everyone has to agree to use them, or they have to be federated. IoT’s track record on federation at this point is abysmal. Almost every IoT system to date requires customers to delegate trust to a service offered by the vendor. Additionally, in many of these systems, the gateway device (that bridges the wireless protocol and the internet protocol) also occupies a trusted position, or at least is not an open-access routing device (meaning it only works for devices using the same trusted party).
This is fine, but it’s not how the internet works. The internet, for all its flaws, is still a decentralized system. You can operate on the Internet with very little dependence on a trusted party. Your laptop works fine at home on a Comcast Internet connection and it works fine when you hotspot with your AT&T phone. Your laptop doesn’t care, or need to care, how it’s connected to the internet. IoT devices today are not like this. They might speak the same wireless protocol (unlikely), but two products from two different vendors are very unlikely to interoperate. Additionally, if your neighbor has the same IoT device as you do, your device won’t use his gateway if the cat pulls the plug out of yours, nor vice versa. This is not an Internet of Things, it’s something else.
Rethinking the Internet of Things
Helium was founded with the idea that an internet of Things, that was publically accessible and ubiquitous, should exist as a public commodity. Unfortunately, even we fell into the trap of centralizing around a trusted party, namely ourselves. While we were never entirely comfortable with the idea, it was difficult envisioning how an alternative could work.
About a year ago, we had a deep re-think about what we were offering and how it differed from what we wanted to offer: a crowd-sourced network of open-access gateways that users could depend on and gateway operators could be rewarded for maintaining. We also wanted to let users operate their own infrastructure (or use ours, if they trusted us). How do you build a trustless IoT network, though?
At the time blockchains had come back into vogue and we had many joking discussions about merging blockchains and IoT. Finally, though, we had a really interesting insight; what if we could replace Bitcoin-style Proof-of-Work (PoW) with something useful and relevant to the IoT.
Fundamentally, Bitcoin-style proof of work is about defeating Sybil attacks. A Sybil attack is when a single actor creates many sock puppet accounts and exploits majority rule voting to overrule the true majority of actors. Proof of Work uses the fact that a CPU/GPU/ASIC can only be solving one puzzle at a time; solving several puzzles at once would reduce the speed of the computation. This means that a miner can realistically only be mining on behalf of one identity at a time. This allows proof of work style blockchains to defeat the Sybil attack strategy because mining on top of the block the miner thinks is the tip of the chain is an activity not interchangeable with mining on top of another block, or mining under another identity.
This effectively means that Bitcoin and other proof-of-work style blockchains rely on the fundamental limits of computation (although our own technological limitations get in the way first) to construct an unforgeable identity.
Defining the first blockchain proof-of-work for wireless
The challenge we posed ourselves is what does a equivalent to proof-of-work look like in the world of radio? In radio there are several fundamental limits: RF energy propagates at a maximum speed (the speed of light), it dissipates over distance (inverse square law), and it emits from a point source (antenna location). Happily these limits are well understood and improvements in technology are unlikely to change them, unlike computationally bounded proofs of work where a new ASIC can make hardware obsolete overnight.
Initially we wanted to build a network around an ERC20 token, but several requirements made that very difficult. First, ERC20 tokens are, pretty much by design, pre-mined. We’d have to build a smart contract to pay out mining rewards from a pre-mined pool. Writing secure smart contracts is still far from a solved problem and the stakes are high. Second, storage on the Ethereum blockchain is extremely expensive, so we’d have to store a lot of things off-chain, which defeats the purpose of building a decentralized system. Finally, Ethereum is slow, on the order of 5 to 7 transactions per second across the entire Ethereum network.
The Helium Gateway includes a Software Defined Radio (SDR) allowing it to listen on many channels simultaneously and determine a highly accurate timestamp of when transmissions were received.
After a lot of thinking, false starts and whiteboarding, we’ve come up with a way to turn our gateway’s access to radio equipment and location into a proof of coverage suitable for use as an identity. Essentially Helium gateways assert their location (according to their GPS coordinate) and other Helium gateways routinely challenge these gateways to prove their location. Knowing where, when, and how strongly a signal was received allows us to verify the transmitter location. Over time, with enough successful responses to these challenges, the gateways can create a strong identity with an associated trust score that we can use to defeat Sybil attacks. Because a gateway is anchored in space, and only a single gateway can occupy a point in space (we don’t allow two gateways to claim the same location), these identities are also unique.
What about Consensus?
Now that we’ve addressed the Sybil attack problem we need to return to consensus. In proof-of-work style consensus (also called Nakamoto consensus) because the proof of work is probabilistic (at any point in time the next bitcoin block is 10 minutes out, even if it’s been 10 minutes since the last block) it’s fine to have a ‘first seen block wins’ approach. Once you have a deterministic proof of identity you no longer want to just wait for the first proof seen, because proofs now have relative value outside of their order of arrival. In Helium’s blockchain we rank the proofs in order of how much they tell us about the network and the trustworthiness of the reporter.
An additional aspect to consider is because our proofs now have value, they all tell us something about the network, we don’t want to discard proofs that didn’t win. This means that simple Nakamoto consensus is not suitable. We explored using Ethereum style uncle blocks and, while that did work, it added a significant amount of complexity and overhead.
Another aspect we considered was to make certain kinds of transactions “free” — as in free of transaction fees. This is important if you want to account per-packet because not only do we want to keep a trace that the packet was sent on the blockchain (for proof of location/transmission of the transmitter), but we also want to enable a “pay as you go” settlement scheme, rather than a pre-pay or pay-in-arrears settlement scheme. This requires the ability to have a transaction per packet (or at least a transaction every N packets).
Miners in a blockchain system are not your friend, they cooperate as long as it is in their interest to do so. Typically they will do the bare minimum, bend or break the rules, censor transactions, etc as long as they can still get paid. This is why most blockchains have transaction fees, they’re the bribe to incent the miner to include the transaction in the block. However, this is in direct conflict with the desire to provide microtransactions for packet transport. So, struggling with both the issues of discarding useful proofs and providing transaction-fee-free microtransactions, we discarded our Ethereum-style blockchain approach and went back to the drawing board.
Choosing a hybrid consensus model for speed and scalability
One interesting approach we found was ByzCoin, which used Nakamoto-style consensus to bootstrap a Practical Byzantine Fault Tolerant (PBFT) consensus system. This type of system has the advantage of not only being resilient to Sybil attacks, but also confirming transactions at a very high rate which is critical for scalability. One big problem with Nakamoto consensus is you tie the proof of identity to the confirmation of transactions. Even worse, because Nakamoto consensus is not very tolerant of netsplits or chain forks, if a fork occurs eventually it will be resolved simply by deleting the losing fork. This means that if you’re on the wrong side of a network partition, or if you’re connected to a malicious peer on the blockchain, your transaction might look like it has been added to the chain (even with several blocks on top), but there’s no guarantee that a longer chain doesn’t exist elsewhere that will appear later and supercede it.
The HoneyBadger consensus model is both asynchronous and censorship-resistant.
These so called hybrid consensus models, like ByzCoin are very interesting, and are on the cutting edge of blockchain research. After researching ByzCoin we also found another paper with the amazing name of “HoneyBadgerBFT”. HoneyBadger is really interesting as it has two rare properties: it is asynchronous and it is censorship-resistant. Asynchronous means that it can tolerate arbitrary delays on messages being delivered. This is helpful for us as we expect gateways to be spread around the world with varying qualities of backhaul. Asynchronous systems are also less susceptible to Denial of Service (DoS) attacks where you cause a system to crash by flooding it with traffic.
With censorship resistance as long as one member of the consensus group is honest, and a user submits their transaction to that honest node, the transaction will eventually be accepted. HoneyBadger manages this with clever use of threshold encryption and as a result it’s very difficult for miners to ignore transactions they don’t want to include in the next block.
Download the Binance.US app here
*Legal disclaimer:
This material has been prepared for general informational purposes only and should NOT be: (1) considered an individualized recommendation or advice; and (2) relied upon for any investment activities. All information is provided on an as-is basis and is subject to change without notice, we make no representation or warranty of any kind, express or implied, regarding the accuracy, validity, reliability, availability or completeness of any such information. Binance.US does NOT provide investment, legal, or tax advice in any manner or form. The ownership of any investment decision(s) exclusively vests with you after analyzing all possible risk factors and by exercising your own independent discretion. Binance.US shall not be liable for any consequences thereof.