Have you heard the saying, "Bad data in, bad data out?" Here's an example of what it means: Let's say you create a personal budget. You plug in housing, food, and transportation costs. Things you have a pretty good grasp on. But when it comes to entertainment, you're not sure so you say $20 a month. Yeah, that'll do. Right?
If you're just guessing off the top of your head or from what happened last month, this could be considered bad data going into your personal budget. The "bad data out" part comes when you actually spend $100 a month on entertainment and are $80 short every month in your bank account.
Bad data in, bad data out.
The edX course, "Blockchain for Business - An Introduction to Hyperledger Technologies", shows how the blockchain is good for supply chains by following a fish from when it's caught to when the fish arrives at the appropriate restaurant. My problem with this example is, if I'm the restaurant owner I won't know if the fish is the weight and kind as described by the people who caught it until it arrives at my restaurant. The restaurant owner has to trust that the data being logged about the fish is accurate. And, if the fish is different from what arrives at the restaurant how can the restaurant owner change it on the blockchain which is immutable? That's a problem.
This is my fear about the blockchain. Someone makes a mistake - or worse, intentionally - misreports a name or a number about something that goes onto the blockchain and that bad data becomes permanent because the blockchain is immutable, it doesn't change. That's all it takes for the blockchain to become a liability. And not only is there bad data on the blockchain, but there are several copies of that bad data out in the world compounding the problem of what is correct and should be trusted.
Fortunately, there are two ways to improve the quality of data that goes onto the blockchain. The first comes from Internet of Things (IoT) sensors. The second comes from APIs. Here are examples of how IoT sensors and APIs can improve the data we put onto the blockchain so we can get good data out of the blockchain.
Let's say a hospital's neonatal intensive care unit is concerned about the air quality in the rooms where the babies stay. The hospital could have an employee visit the room and test the air throughout the course of the day. Or the hospital could use one of the 85 IoT sensors currently available to test the room's air however often it wants and record those readings on a blockchain dedicated to a particular hospital room. It could even sound an alarm or send a message to a dedicated staffer if the air quality level in a particular room fell below a pre-determined level. Like this air quality sensor, IoT sensors have the potential to be more accurate, dependable, and unbiased.
As for APIs, let's say the Arizona Diamondbacks baseball franchise wants to find players that perform best in locations - such as Arizona - with high temperatures. The team could fly scouts out to games where the weather forecast is hottest for any given week, but that would cost a lot of money, the weather could change, and the player they're interested in may not even play that day. Instead, the team could build an application that cross-references player statistical performance (home runs hit, bases stolen, strike outs by pitchers) with the AccuWeather API to note the temperature, time, and humidity of the place where the players performed such feats. And, unlike a scout in the stands who may describe the day as "really hot", the AccuWeather API will act as a unbiased third party providing objective data that the Diamondbacks can trust is reliable and true. All saved to the blockchain.
Those are two ways to avoid bad data through human error before it goes to the blockchain for permanent record.
Having made these cases, I still want to stress that while it may be difficult if not impossible to hack the blockchain, it would still be possible to hack the APIs or IoT sensors driving information to the blockchain. It's also possible for someone to incorrectly set up how a sensor or API is used resulting in the gathering of the wrong data. Thorough testing in development is, as usual, highly recommended to help avoid this problem.
In future posts I'll continue to give examples of blockchain use cases and how IoT sensors and APIs can help validate the data going onto the blockchain.
Comments
Post a Comment