The XYO Network (XY = location coordinates, O = Oracle) is promising to connect location data from untrusted producers to smart contract consumers - building an entirely new incentivized network to solve the perceived problem of untrusted blockchain oracles feeding bad data into smart contracts.
XYFindables - the company behind the network, is already producing a line of Bluetooth Low Energy (BLE) beacon-enabled, smartphone-linked, asset tracking tags. Presumably the company has identified a need for this network based on real-world experience, and XYO is not just an ICO crypto-grab.
What I see in XYO are two key concepts:
- Harvesting location data from bona-fide battery-powered IoT devices - an area I am active in, and
- Building an incentivizing layer on top of the data transport mechanism - in effect creating a Data Supply Chain - something I've blogged about before.
However, on closer inspection, the XYO concept is lacking in detail. The elaborate scheme of "Bound Witness", "Proof of Origin", compensation models, and another proof-of-work "XYOMainChain" could, in my opinion, be replaced by BLE beacon location devices utilizing Google's Eddystone secure beacon eID and eTLM, for example.
Furthermore, Bound Witness describes a scheme whereby nodes must register the presence of other nodes in the vicinity. If you know a little bit about how these BLE location devices work, and the value that that market places on battery life (got to XYFindables.com and you'll see a comparison of companies using battery life as a metric) - you will know that if the device has to record another device's BLE beacon, it must turn on its radio - and turning it on will drastically shorten the device's battery life and hence market value.
Transmit-only BLE beacon devices, which the company produces now, have a battery life that depends proportionally with how many beacons are emitted per unit of time. A device that needs to "bind" itself to another device is going to drain its battery a lot faster.
A More In-Depth Analysis
Think of the following as an open letter to the XYO Network.
Two key features of the system are Bound Witness and Proof of Origin/Proof of Origin Chain. The Proof of Origin is rooted in Bound Witness and assumes that the devices are not secure, in other words, a spoof-able unencrypted unique ID is broadcast in each BLE beacon emitted by the device.
Here we go:
- Bound Witness places a requirement on devices to turn on their radio receivers to capture information about their environment. This drains energy and significantly reduces battery life compared to beacon devices that only transmit.
- Proof of Origin is claimed to be needed to avoid the problem that devices are not physically secure; this is not a justified position – properly secured MCUs prevent any readout or access to content stored wthin flash or RAM; in this respect a private key with established CMAC algorithms is sufficient to "prove origin" of a "measurement heuristic" about this device's location – all without turning on the beacon's BLE radio receiver and draining the battery.
- Assuming the devices are not secure – weaknesses in "Bound Witness" have not been sufficiently discussed – it seems that adding some nodes to the network to add a small bias or error to a local region's position results would be accepted, and even compensated with crypto currency – it also seems possible that the XY group will simply refuse to allow just anyone to add nodes to the network, instead requiring node builders to "register" and get an "access token", which must be programmed into the device... and you see where I'm going with this... circling back to the private key situation.
- Incentivizing the elements in this "data supply chain" is interesting, but there is no explanation or discussion about what incentivizing these actors may actually look like. If I get XYO for relaying fancy BLE beacons (aka Proof of Origin messages) detected by my phone in an airport, are we going to see Pokeman Go all over again?
- Is this system really just an attempt to circumvent secure Google and Apple beacon APIs? Is not a secured Eddystone EID beacon sufficient to prove location? (According to Google's own material: …)
- Me and thousands of other people are working on city-wide IoT networks that render XY's tech obsolete. Why would you buy devices that need to attach and be in range of your phone when our devices can communicate with city-wide networks? The applications and use case that our devices opens up have no comparable in the BLE XY beacon space.
- Incentivizing network participants in a "Data Supply Chain" IS interesting, however. This is the first time I've seen the concept discussed in a blockchain whitepaper. What we really want to do is implement such a scheme in a LoRaWAN network – incentivizing private LoRaWAN gateway operators (as "bridges" in XYO-speak). Nodes can securely and authentically transmit location information end-to-end across the LoRaWAN network to a LoRaWAN application server, run by a trusted organization as a smart contract Oracle. I see no reason that Company X, interested in location data for smart contracts, can strike a deal and trust Company Y – running a location-data-providing Oracle as a LoRaWAN network application service. Do we need XYO here? No. What we need is something else.
So what's next with IoT location technology?
Hashgraph
A Hashgraph type of system could replace all of this by embedding the Oracle right into the network – with cutting edge IoT systems in the works. Devices that are IP capable could participate directly in the distributed ledger, moving data directly into the smart contract environment – which could then perform the function of the XYO Diviners, all right on the Hashgraph proof-of-stake chain, without any special bridge component. Maybe the 'Archivist' concept still applies to buffer data, or store it as part of the smart contract ledger audit history.
LoRaWAN
LoRaWAN networks can fulfill a smart contract location function already. The end device securely stores a private key known only to the LoRaWAN network application acting as the oracle. Data is securely and authentically transferred through the LoRaWAN network, consisting of untrusted gateways, public internet, other relay servers, to be stored on the trusted LoRaWAN application server performing the Oracle function.
This LoRaWAN application can be run by a reputable company and thus serve as the trusted location data source for the blockchain smart contract. We can build an incentivization layer on top of that to compensate the components of the data supply chain: the device owner/operators (data producers), LoRaWAN gateway owner operators, cloud infrastructure and application service providers, and eventually the smart contract participants (data consumers).
Conclusion
If you've learned one thing here, it's that IoT, location and blockchain do have a future together and it is unfolding as we speak. It is up to us to make it happen.