How To Make Better Smart Contracts With DASH7 and PoL

9 min readMay 15, 2018

Note: this is the first in a series on implementing Proof of Location using DASH7

Recently our team began taking a look at how DASH7 will help blockchain applications with a hard-to-solve problem: authenticating the physical location of one or more parties in a smart contract.

Smart contracts are computerized transaction protocols that execute the terms of an agreement without the need for a central authentication or organizing authority. Authenticating execution of some smart contracts can be straightforward— e.g. “Party A will pay you $0.10 every time Party B posts a tweet that includes the hashtag #DASH7” — via a simple script. However, a smart contract that includes terms that require one party’s physical presence or location in a given geographic area presents a different challenge, since most methods of authenticating location today utilize easily faked methods for geolocation like GPS or require the use of a central authority like a cellular carrier.

So creating a fraud-proof, location-based authentication capability — or a “proof of location” — will be of significant importance to smart contracts that include location-based terms.

Why This Matters Now

Blockchains are driving the migration of internet applications from the confines of centralized “cloud-based” architectures: payments, supply chain, insurance, social media, gaming, and more to a decentralized, “permissionless” one. A common blockchain-based application implementation relies on Ethereum and implements an autonomous, decentralized (i.e. no cloud server required) network architecture that uses tokens as a means of facilitating transactions.

But with this liberation from the cloud come new challenges, like verifying the physical location of one or more parties to an autonomous smart contract. While “trusted” centralized authorities like cellular carriers can authenticate someone’s location via cell tower trilateration, a decentralized, “trustless”smart contract has no such infrastructure available today to reliably authenticate location.

To illustrate — and my bias here is to look at how PoL will impact IoT applications — let’s use supply chain. How does a smart contract between the manufacturer and buyer of pharmaceutical inventory guarantee that the manufacturer’s inventory was in fact routed via agreed-upon shipping carriers, distribution centers, warehouses, etc. and not diverted for purposes of counterfeiting or gray market sales? How does a company’s autonomous delivery drone prove, in fact, that it landed by your front door to leave a package (that was later stolen) on your porch? These are examples of real-world, location-based risks whose externalities (a la Coase’s theorem) in cases of fraud or abuse are potentially large (e.g. dumping radioactive medical waste in a residential area instead of a pre-agreed location).

Mitigating location-based risk is therefore essential to the future of location-based smart contracts. As a result, we are in the initial phase of the development of a decentralized, terrestrial, global PoL network.

Why Conventional Forms of PoL Won’t Fly With Smart Contracts

While familiar means of determining location may have some role to play with smart contracts, they are ultimately insufficient to the task. And even though we at Haystack work extensively on integrating GNSS and LPWAN’s, for purposes of smart contracts the simple fact is that GPS/GNSS can be faked. All GNSS systems are vulnerable to spoofing, jamming, or even anti-satellite weapons, yet the world depends on GNSS systems not just for conventional navigation applications, but for even more fundamental tasks like timestamping financial transactions. Most of us are oblivious to the pervasiveness of GNSS!

Additionally, GNSS isn’t always available. And getting a reliable GNSS signal amid inner city high rise buildings can be a challenge, not to mention indoors. And if satellites are jammed or made unreliable, then what? Drones need to fly, autonomous vehicles need to drive, you need to find your way home when there are no cellular signals available, etc.

Lastly, and perhaps most importantly for purposes of smart contracts, wireless signals from GNSS satellites are one-way transmissions that are unencrypted. There is no mechanism for implementing, say, public key cryptography using today’s civil GNSS systems. So if you want to authenticate location for a single, mobile endpoint in a decentralized network, public key crypto is going to be important. And one-way location beacons like GNSS won’t solve for this.

NB: a sometimes-alternative to GNSS — Loran — has been touted as a GNSS backup and an upgrade for Loran — “eLoRan” — has been denied government funding for years. Regardless, similar to GNSS, Loran signals are one-way, unencrypted, and like GNSS could be faked, so while Loran would seem to be a good navigation backup to GNSS, it’s utility for proof of location will, like GNSS, be of limited value.

Thinking About PoL From the Bottom-Up

An alternative means of “Proof of Location” (“PoL”) that does not rely on GNSS or centralized location methods is therefore important to the future of location-based smart contracts. This alternative means of PoL will, for the foreseeable future, be a terrestrial-based network rather than space-based.

While implementing PoL requires plenty of thinking at the application layer — the team at FOAM is doing a nice job here — getting to successful PoL for most IoT use cases like supply chain or really requires thinking about PoL from the bottom-up. In other words, start with the physical (radio) layer and then work up the OSI stack from there. Because if your underlying radio and networking layers are a poor fit for PoL, all the application layer tricks in your quiver won’t deliver reliable PoL. Thus for starters, PoL will require:

Non-reliance on centralized wireless communications technologies like those offered by cellular carriers. A decentralized app would not rely on a centralized (and easily compromised) actor like a cellular carrier. PoL will ultimately rely on wireless networking technologies that are being deployed (by default) primarily in unlicensed spectrum.
Support for public-key cryptography. In order to implement PoL in a public network where devices are “strangers” to one another, the use of public keys to authenticate is important. For example, a carton of flu vaccine passing through an airport terminal is detected and authenticated via the endpoint’s public key. Note that the availability of public key cryptography for this next-gen PoL is a significant differentiator from GNSS and opens a number of interesting application venues that were previously closed to developers. More on this in a future post.
Fully bi-directional, low latency communications. Implementing public key crypto, at a minimum, requires bi-directional communications. But implementing even more basic networking functions like queries, ad hoc networking, firmware updates cannot be accomplished with a uni-directional protocol like Bluetooth Low Energy or Lorawan.
Peer-to-peer, ad hoc, and multi-hop networking. In a truly decentralized world, conventional “gateways” or “access points” with direct access to the internet may be unavailable, thus a networking protocol is required that is sufficiently flexible to respond to changing network participants but also allow for the kind of innovation that is inevitable with blockchain technologies. For example, a group of endpoints that are out of range of an internet gateway may nonetheless be able to authenticate the location of another mobile endpoint passing nearby.
Fast, efficient clock synchronization. Clocks move out of sync and any time-based approach to PoL will require reliable, fast clock synchronization for large fleets of devices, including for low power devices. More on this here.
Broadcast and multicast messaging. This is related not only to the task of synchronizing endpoints and gateways in a wireless network, but also in deriving location, whether using time-based (e.g. TDoA, TOF) or signal-strength based (RSSI) techniques. A gateway, for example, may want the authenticated location (PoL) for a large fleet of endpoints simultaneously.
Support for time-based and signal-strength based location methodologies. Ultimately, proving location requires getting your device and/or message stamped with irrevocable location coordinates. GNSS is a time-based methodology and time-based methodologies can be deployed in terrestrial networks as well. But signal-strength based methodologies (like the cellular trilateration your iPhone uses, among other things, to show your location in Google Maps) will be important as well. Note that legacy support for GNSS is likely to be important as GNSS is likely to provide an additional layer of authentication that some applications may require or at least prefer. However, not all wireless technologies can support GNSS, as I’ve written here.
Support for low power devices. Since PoL implies proving location for what is, logically speaking, a mobile device, it is short-sighted to assume all mobile devices will be high powered. In fact, the vast majority will be low power devices. Thus, the architecture for a global PoL network will require support for low power devices — i.e. multi-year battery life — from the outset.
Open network. This should go without saying but to be clear, since anyone can build autonomous, permissionless, location-based blockchain apps, anyone should be able to leverage this global PoL network, a la civil GNSS today.

Wireless networking protocols are only one part of what will ultimately constitute a viable PoL solution, but there’s little doubt that without the right wireless protocol, PoL will be of limited value.

The Blockchain Moment for LPWAN’s

For now, I will skip thoughts on implementing high power, short range radios like WiFi for PoL and leave it to others. For smartphones today, WiFi may have a role to play in PoL.

But the more lively space in the IoT today is with LPWAN technologies like Semtech’s LoRa (and new entrants due to appear later this year) that operate in unlicensed spectrum and whose architecture is more aligned with the way smart contracts work. Note: NB-IoT and LTE Cat M-1, by virtue of being centralized, among other reasons, can be omitted from this discussion.

LPWAN’s are interesting for PoL because the long range (up to several miles) means the number of participating gateways required to authenticate an endpoint can be far fewer than, say, that required to cover an entire city with participating WiFi access points. LPWAN’s are also interesting due to the scalability of the technology to small, mobile devices with a limited power supply, unlike WiFi. You can envision wristbands or keyfobs that utilize PoL with this profile in mind. And lastly, LPWAN’s like LoRa are designed primarily for use in unlicensed bands which aligns nicely with the “permissionless” architecture of blockchain apps.

Note: An LPWAN -based PoL will, like Ethereum, Bitcoin, and other blockchains themselves, implement Byzantine Fault Tolerance to withstand attempts by bad actors to undermine the PoL system. This is accomplished primarily at the application layer but we also see opportunities to implement BFT in the wireless networking layers themselves.

But implementing LPWAN’s for PoL is not just about the choice of radio but more importantly, the networking stack that rides atop the radio. If you follow DASH7, you’ll know it is being deployed on LPWAN radios like LoRa and others and is uniquely suited to the requirements for PoL mentioned above. I will share more in a future post on how we are implementing PoL over DASH7 and I will be looking forward to hearing how other entrants in the PoL space plan to solve for the requirements mentioned earlier in this post.

Final Thoughts

In addition to its capabilities for geolocating low power mobile devices, we believe DASH7 has a foundational role to play in authenticating location for this next wave of network computing. One or more unlicensed band LPWAN technologies are likely to dominate this function and DASH7 was purpose built for location-based LPWAN duties.
Beyond blockchains and smart contracts, the vulnerability of GNSS is something worth pondering further and whether DASH7 has an additional role to play as part of an encrypted, terrestrial backup to GNSS.
As blockchain-based IoT apps generate ever-larger tsunamis of data, companies seeking to profit from the of that data will want to consider authenticating the location provenance of that data, as incentives to sell fraudulent data via a smart contract will be high.
As blockchain-based IoT apps begin substituting for cloud services IoT apps, it inadvertently brings us closer to a vision of driving more IoT processing to the true edge of the network — the endpoint — something I’ve touched on before.

Get the latest about Haystack by signing up for our newsletter here.