Blockchain Data
Stuart Harrison discusses the ODI Labs team’s foray into putting open data into a blockchain – and what would happen if they opened it up to miners
If you work in the technology sector (which, if you’re reading this, you probably do), then you’ve most likely been swept up in a lot of hype and talk about blockchain. This immutable, distributed ledger technology will apparently change the world, allowing a revolutionised approach to share trading, smart contracts and provenance tracking, to name but a few things.
But what does this mean for open data? With 2016 just getting started, ODI Labs decided to use our first week back in the office to try to tease out the answers to this question.
Setting up a digital currency
Firstly, we needed to find a blockchain; not, as I should point out, the blockchain (which is the ledger that stores Bitcoin transactions) – we wanted something quick and dirty to experiment with, and we weren’t entirely convinced that storing data in the Bitcoin blockchain was the right solution.
We settled on Multichain, a Bitcoin-compatible blockchain, which builds on the main Bitcoin blockchain spec, but crucially adds support for things like metadata and custom assets, so we could mint our own digital currency.
The next step was to build a Ruby client, which we found didn’t exist. As Multichain (and Bitcoin) exposes a JSON-RPC API, this was nice and easy. We also had some vague ideas that we might want to add some metadata that showed the state of a given URL at any time, so added in functionality for that too. You can see our code on GitHub and pull requests are, of course, welcome.
The blockchain meets the open data
So, we had a blockchain and a way of accessing that blockchain in a language we felt comfortable using, what next? After some thought, we cast our minds back to earlier last year, when Philip Potter from GDS wrote a fantastic blog post about guaranteeing the integrity of a register, describing technology that looked, for all intents and purposes, like a blockchain.
The example Philip used in this blog post was food safety inspections and, as I’ve got a long history in publishing and working with food safety data, we decided that we could use the existing open data to suck up the Food Standards Agency (FSA) ratings data and put it into our blockchain. That way, if people were unsure if a rating was genuine, they could look at our blockchain and see that it was the case. While a website can be hacked, and ratings altered, information on a blockchain cannot be deleted or altered, and can also be traced back to its originator.
We knocked up a quick script that uses the FSA API to get inspection data and import their premises ID into the blockchain, along with the inspection date and rating. The idea was to then run the script on a regular basis to get any new inspections.
The import seemed to work and we set out what we planned to do – put open data in a blockchain. But this raised more questions than answers.
