Blockchain applications live in their own digital realm, totally orthogonal to the “meat space” also known as the Real World™. Be it decentralized application or smart contracts, their reach is limited to the space they can control. Any use case projection in our reality eventually confronts the following hard fact:
how can an app efficiently and securely interact with the physical world?
We need gateways to input/output with the physical realm, which are also called “oracles”.
The oracles are trusted entities signing claims about the state of the world.
Depending of what exactly we call the “physical world”, and depending of the existence or not of a consensus about the state of what we need to assess, there are different implementation of oracles.
Attestation of origin (TLSNotary)
When the knowledge of the information you are seeking is available online, simple software based oracles can provide efficient solutions. They can answer simple questions such as: “What is the value of BTC in EUR?”, “Did this plane suffer a delay of more than 30 minutes?” or “Was it raining yesterday in this city?”. Data are available online, on the Internet, and can be extracted from trusted sources such as company airlines, financial data aggregators or weather institutes.
The oracle can cryptographically attest the origin of the data (TLSNotary) and push the information to a smart contract. The oracle is making a public claims about the contents of secure web pages, and provide an actionable gateway for a decentralized application. For instance, Oraclize is a platform providing such “oracle as a service”.
There are some technical pros and cons for such an implementation, but the major issue is that you need to trust the source of information. For weather data coming from a reputable website, it can be acceptable, but what about more complex questions such a facts or events. Should we trust Wikipedia? Edition wars could seriously manipulate the oracle and its claims would be worthless.
Hard facts can always be crossed checked from different trusted sources (financial tickers, weather data, sports results…), but it won’t work for more complex questions.
Consensus based oracles
Decentralized prediction markets such as Augur heavily rely on oracles to settle outcomes of events. However, to avoid market manipulation, these oracles cannot be based on the trust of one single entity (be it Google or Wikipedia). The solution is to use rather complex consensus mechanisms based on reputation, ultimately building decentralized oracles.
All of the previous oracles implementations work best for facts that can be determined by consensus.
But what about real time, non public, user centric facts?
There are some facts which cannot be determined through consensus or public data attestation. For examples:
- Where is this container right now?
- Is this door locked?
- What is the carbon emission of this engine for the last 60 minutes?
- What is the current speed of this vehicle?
- What is my heart beat?
Local and private data source
Some applications require to get information or readings from the physical world, where the data exists only within the targeted object (or person).
easure must be done locally, and often in real time. As the data is private, accuracy of the information cannot be asserted neither by a public feed nor by consensus.
Some applications and use cases concerned by these setups are:
- Industrial: supply chain, traceability, energy…
- Sharing economy: peer to peer car/flat renting, smart objects…
- Insurance: car safety premiums, personal health…
Let’s take for instance a smart contract insurance where drivers would pay a premium in the hope of being rewarded for their good behavior on the road. Drivers guilty of speeding would lose their premium, which would go in a pool shared by all “law abiding citizens”. Road safety associations could locally contribute to pools to bring even bigger incentive for good driving.
The difficulty in this approach is to find a secure and non-tamperable way to monitor the speed of vehicles: if one were able to either simulate a perfect driving or to attach the tracker to another car, the insurance system would be totally gameable and ultimately collapse.
Cryptographically attestable anti-tampering sensors
To be able to securely report a reading (from any kind of sensors), the combination of the following is necessary:
- a cryptographic attestation of the sensor reading, authenticating the origin of the measure: each device has a private key signing outgoing payloads (with a nonce to avoid replays)
- an anti-tampering installation of the reader device, rendering it inoperable (by wiping the private key) in case of manipulation attempt (connect to another object, inject false stimuli, etc.)
These secure reading devices are called Hardware Pythias, and are the gateways from the physical work to the Blockchain realm.
Deployment of these oracles require provisioning of the system (master attestation keys and device identification keys), and establishing a strategy to supervise they correct initial installation (to make sure they are measuring what we want them to measure). Trust on the long term is guaranteed by anti-tampering features and private keys’ protection through a Secure Element.
By design, this approach is neither trustless nor fully decentralized. In the case of the car’s smart contract insurance example, the tracker must have the proper attestation keys (therefore bought from specific vendors) and an audit strategy must be put in place to randomly verify their proper installation (therefore requiring some external trusted parties/auditors).
However, as most of the Hardware Pythias’ use cases require some sort of centralization or authority, this design is a perfect match.
Decentralized apps for industrials, insurances and the sharing economy won’t exist without reliable Hardware Pythia technologies. We predict a massive deployment of these devices in the long term.
Ledger is a technological enabler for industrial and enterprise Blockchain use cases. Contact us if you want to know more about our Hardware Pythia and Blockchain Computer solutions.
About the author
Eric Larchevêque is Co-Founder and CEO of Ledger.
Serial entrepreneur since 1996, Eric founded several companies in Europe. He got interested in Bitcoin in 2013 and launched La Maison du Bitcoin — a French Bitcoin center in Paris, before co-founding Ledger.