Blockchain, Distributed Ledger and Trusted Third Parties –
And Why Should an IoT Sensor Producer Care about it?
What exactly is a blockchain, anyway?
Blockchain is a: “open, distributed ledger that efficiently records transactions between two parties in an auditable and permanent manner.” [1]. Blockchain technology was developed ten years ago on January 3, 2009. After the first original block, a block (data record) was bound to the next by so-called miners [2] using cryptographic hashing. No preceding block can be modified, swapped, or deleted in all copies of the chain without updating the following blocks. Every node in the system has a copy of the chain. This mechanism ensures that the system becomes more reliable with each node, because the data written in a block can no longer be changed (or forged). Today, the blockchain (chain of records) and its most famous application “Bitcoin” is a worldwide phenomenon. – The data written in these blocks are the “financial” transactions between two parties. It is ultimately an electronic ledger. This is why the blockchain is sometimes referred to as a distributed ledger.
Blockchain example: Bitcoin
Because every node is independent from every other and all have a copy of the chain (or ledger) no one person is in charge of a central certified copy, everyone has the real chain. There is no need for a trusted third party (TTP). Bitcoin is called a cryptocurrency because it guarantees that no one simply “prints” or generates bitcoins and thereby devalues the currency. In a normal currency this is done by the central bank of the country – a single potential point of failure. The decentralized currency Bitcoin is in effect independent of any “government pressure”. Bitcoin has no TTP but cannot be attacked with a technical Denial of Service (DoS) attack and requires practically no fees to keep running.
Visa has the same functionality for credit transactions. But because it doesn’t use the distributed technology invests huge sums of money every year to protect their centralized client server architecture from DoS attacks. All the millions of clients worldwide (credit card terminals) are connected to their main server. Visa guarantees the performance of their system and the security – they are then the TTP – and demand generous recompensation for their troubles in the form of fees.
Where will all the data go?
Clearly with billions of sensors in future in an IoT world where will all the data go? Even if one could build a centralized client-server architecture, which was efficient and secure to DoS attacks, would we want one company controlling all sensor data worldwide? Sensor data could be stored directly in the ledger and individual customers could contact individual sensors and get their data independently, safely and cheaply, without expensive TTPs as middle men.
The concept and challenges of Smart Contracts
Smart Contracts are written in computer code and run on every node of the chain. With defined inputs comes a defined output (ideally like a legal document). These Smart Contract “decisions” are reliable because they are run everywhere and the result is documented on the blockchain in a transparent, verifiable and permanent way.
Smart Contracts run inside a virtual machine that has to be independent of the hardware it is running on, because it has to run on all possible nodes, and therefore has no access to any hardware or sensor information. Another major technical hurdle: Smart contracts run on every node and if the information is available only from one sensor, it is not advisable that many millions of nodes ask the same sensor for the same information at the same time.
Because the Ethereum blockchain, a competitor to bitcoin, was the first to implement Smart Contracts, they started working on a solution: oracles.
A possible solution: Oracles
Oracles are special nodes in the network that supply the information to the smart contracts. The hardware sensors supply their information and make it available to the oracle, which distributes it to the chain. The oracle acts effectively like a data proxy.
The problem of trust
However, the problem of trust has reappeared. The oracle is in the position to change the data from the sensors before it even reaches the blockchain. Once in the blockchain the data transacted may be trusted without a TTP – but the oracle providers have to be trusted. The oracle providers are letting themselves be certified by central certification systems. This however means the TTP is back (just in a different form) and also centralized (like Verisign for trusted web pages). A simple denial of service attack on the certificate providers or the oracles themselves could stop the entire IoT system.
One option is to supply the data to several different oracles and use redundancy. However, to set up enough oracles is too expensive for most organizations. An open source universally hostable oracle server could be the solution to serving the data but not to the trustworthiness.
A certificate only “trusts” the oracle node. The sensor which delivers the information could be compromised and the oracle would not know it or - worse - “wouldn’t care”. The oracle producers just provide the service to get the information onto the blockchain and cannot realistically check all sensor providers.
Of course the sensor providers could also certify themselves and say that their hardware/firmware is not hackable and is trustworthy. But there again is the TTP problem, customer lock-in and higher costs involved in your system.
With the introduction of such a TTP, the use of a decentralized trusted blockchain is then questionable. A “standard” database centralized network provides the same functionality with, effectively, the same disadvantages.
The ideal solution: Trustworthy camera sensors
The ideal solution would be that the sensors produce data which may be checked by the end user (with a smart contract) to see if it has been tampered with on its journey from the sensor.
Taking the example of a camera sensor, the first step would be to hash the image and store the hash. The picture would reach the end customer who could get the hash and compare it to the one he has generated himself. If they did not match, the image has been tampered with. Additional information may also be hashed with the image data, for instance the firmware. This would then make the image unique to one specific camera and firmware. Other local sensors in the system may also send their data to the camera module for hashing before sending the data over the blockchain. The image may then be used by the end user to check to see if the sensor data was tampered with.
This is just one example of a trustworthy camera sensor [3]. There may be many other possibilities for other sensors.
Summary
Modern peer-to-peer blockchain-based networks work without any centralized trusted third party. This allows for better scalability and avoids the need for paid trusted third parties. Unfortunately, providing sensors to the smart contracts on the chain have to go through data proxies. In order to avoid the monopolization of the data through these oracle proxies, independent algorithmic allowing the data from a camera sensor to validate itself has been introduced. It is hoped that more sensor producers will follow to provide a truly decentralized trusted-third-party free network.
REFERENCES
[1] M. Iansiti, K.R. Lakhani "The Truth about Blockchain", Harvard Business Review, January 2017.
[2] D. Drescher, “Blockchain Basics”, mitp, Chapter 14, 2017.
[3] Patent Pending, B16000DE / FK, em 18-009.