RS IoT Blockchain Demonstrators Part 1: Introduction
The design and build of Internet of Things Blockchain demonstrators for Electronica 2018.
This series of posts looks at the design and build of a set of demonstrators for the bi-annual Electronica trade fair and conference, which show how blockchain technology can be used to create a secure, decentralised data platform and more for the Internet of Things.
More than simply cryptocurrency
Given how often it features in the news, when you hear “blockchain” it’s natural to immediately think of Bitcoin — and in turn its highly dynamic nature, along with specialist computer rigs that consume lots of energy in a race to mine more of the cryptocurrency. However, this is but one blockchain application and the secure, distributed ledger technology can be put to use in supporting a great many other applications. Such as, for example, the Internet of Things.
There are a number of different blockchain platforms that support developing custom applications and we’ll be using Ethereum. While there are public Ethereum networks, we’ll be creating a private network, since this will give us full autonomy and allow us to use an alternative to the energy-hungry proof-of-work mechanism that is presently used to secure production public networks.
We’ll be running Ethereum node software on Raspberry Pi SBCs that are integrated into the demonstrators, together with sensors and outputs. A previous post series explored running Ethereum on Raspberry Pi, initialising a private blockchain and then transacting on it. Although it should be noted that it was secured via proof-of-work and this time instead we’ll be using proof-of-authority.
The Ethereum network configuration is something that will be covered in much more detail via a future post in this series.
So now on to the use cases and there are four that we will be concerned with, although it’s easy to think of many more IoT applications that could also benefit from blockchain integration.
Car Crash (vehicle insurance and safety)
Here we will have two model cars, with one static and a second that can be raised up a ramp and released, so as to simulate a crash. The static car will have an accelerometer fitted and when the Y-axis measurement exceeds a predefined level, this will trigger a crash event and upon which a transaction will be logged to the IoT blockchain, recording the impact.
Machine Failure (machine maintenance)
A miniature conveyor belt is powered by a DC motor, with an ADC measuring the voltage across its terminals and when this drops below a predefined level, a failure event is triggered and a transaction logged to the IoT blockchain. Of course, in a real-world deployment, there might also be current, motion and temperature etc. sensors used to distinguish between different failure modes.
Temperature Alert (refrigerated storage/transportation)
With this demonstrator, we will have a small table top refrigerator fitted with a temperature probe. When the temperature exceeds a certain point a transaction will be logged to the IoT blockchain.
LeakKiller Challenge (home insurance and property management)
This demonstrator will provide a simple representation of the LeakKiller Challenge concept via a small sink unit with plumbing, where a simulated leak can be triggered and following which this would be detected and the water supply shut-off.
Building on the LeakKiller Challenge, this demonstrator integrates blockchain technology to provide a secure, distributed and immutable record of a leak event.
We will also require a means of securing the network and as with public networks, this will be performed by a miner, although since our network will be configured to use proof-of-authority this will consume very little energy by comparison. In short, when the blockchain is initialised, nodes can be designated as having the authority to seal new blocks containing transactions, thereby removing the need to perform some highly computationally-intensive task in order to earn this right.
In a production network, you would have more than just one miner, so as to provide greater capacity and resilience, but a single node with this role is fine for the purposes of a demonstrator.
Once again, we will look at blockchain configuration in more detail in a future post.
The design and build of the demonstrators is covered over the course of a total of five posts:
- Part 1: Introduction
- Part 2: Mechanical Build
- Part 3: Electronics
- Part 4: Blockchain Network
- Part 5: Host Software
CommentsAdd a comment
Hi Andrew, mind if I ask, what's the difference between blockchain that is mentioned here, and data storage (such as solid state storage, hard disk drive etc)? Or is blockchain another type of data storage?
- Brandon, recent highschool graduate.
@BrandonWJY Although a storage medium of some kind will tend to be used by a blockchain node, it isn't really the point of blockchain: you can run a fully functional chain entirely in RAM. How blockchain differs from standard ways of keeping data is that each entry into the ledger is linked to the previous entry by holding (as one of its fields) the hash value of the previous block. One of the requirements of an effective hash algorithm is the 'avalanche effect' which means that even the smallest change in the original data will result in an entirely different hash result. What that means for our chain is that any attempt to tamper with data in an existing block is easily detectable, because the hash value for the amended block will not match the 'previous hash' field in the next block. As most commercial blockchain is also run on distributed peer to peer (P2P) networks, so there are multiple copies of the chain, the amount of computing power required to amend an entire chain (after the block that was tampered with) on multiple nodes simultaneously is thousands of orders of magnitude outside of what even the best equipped, state-backed, black-hat hacker can muster. Hope that helps.
@BrandonWJY I'm not an expert but I believe that as the Blockchain acts like a ledger copied across many parts of blockchain. If a chain in one is made then it needs to be copied to all other instances that that the ledger is always up to date. If one chain is changed but not by or in the correct way then the change is not recorded across the block chain and is there for not approved. This means that those with access can check at any time to see the current status and get information from the block chain and know that this is the latest version and always tells the truth.
[Comment was deleted]