Image CC BY-NC-ND Clayton Shonkwiler

A post entitled Avoiding the pointless blockchain project was brought to my attention recently. It provides a useful jumping-off point for the BadgeChain project in terms of thinking through Open Badges using a blockchain.

The author of the post, Gideon Greenspan, states that all of the following should be true for projects built upon a blockchain:

  1. The database — the project is one that requires some form of shared database
  2. Multiple writers — more than one person or organisation needs the ability to write to that database
  3. Absence of trust — the people or organisations writing to the database don’t necessarily trust one another
  4. Disintermediation — every person or organisation that has ‘write’ access has the need to verify transactions (rather than go through a trusted intermediary)
  5. Transaction interaction — there are benefits to the project in being able to see transactions that are in some way ‘linked’
  6. Set the rules — there are constraints on the type of transactions for which the project blockchain can be used
  7. Pick your validators — you know what model you’re going to employ to resolve conflicts — e.g. “(a) one or more nodes controlled by a single organization, (b) a core group of organizations that maintain the chain, or (c) every node on the network.”
  8. Back your assets — there is agreement on the types of assets being moved around, and what exchange value they have in the ‘real world’

As Greenspan states in his conclusion:

[I]f your project does not fulfill every single one of these conditions, you should not be using a blockchain. In the absence of any of the first five, you should consider one of: (a) regular file storage, (b) a centralized database, (c) master–slave database replication, or (d) multiple databases to which users can subscribe.

And if you do fulfill the first five, there’s still work to do. You need to be able to express the rules of your application in terms of the transactions which a database allows. You need to be confident about who you can trust as validators and how you’ll define distributed consensus. And finally, if you’re looking at creating a shared ledger, you need to know who will be backing the assets which that ledger represents.

Let’s come back to Open Badges and how they might work using a blockchain using Greenspan’s helpful list.

  1. The current way Open Badges work does not require a shared database. In fact, this is pretty much by design so that they can be stored anywhere. However, as I wrote in a recent article for DML Central, there are at least two use cases for using a blockchain with badges. The most obvious of these is for extremely high-stakes credentials such as university degrees and credentials that, for example, get you access into a country.
  2. Instead of every university or issuing body having its own blockchain, there are advantages of them pulling together in creating a single, open blockchain for Open Badges that could be written to by anyone who meets certain criteria. These could be negotiated and laid out by the Badge Alliance.
  3. There is no reason for issuing organisations to trust one another simply based on the fact that they are all issuing Open Badges. So this condition looks like it is met.
  4. The whole point of Open Badges is that they are distributed and remove gatekeepers. So it makes no points to re-introduct gatekeeprs. Distintermediation seems baked into the Open Badges Infrastructure (OBI).
  5. Badges represent credentials that often relate to knowledge, skills, and behaviour. Showing progression through such credentials is useful, and therefore the ‘transaction interaction’ referenced is a desirable feature of the system.
  6. Although blockchains can be used to represent a whole swathe of data types, an Open Badges blockchain would likely limit transactions to those containing information relevant to the Open Badges specification.
  7. The options for validation would need to be discussed with the founding members of the blockchain project. However, of Greenspan’s options, it’s likely that the validators would be option (c) — i.e. all the nodes on the network.
  8. Talking about exchange value when it comes to Open Badges is an interesting problem to solve. There’s been a lot of talk about ‘levelling’ badges, so people are aware of equivalencies. However, for every pragmatic person wanting this, there’s an idealist (like me) not wanting to lock things down. This is a problem that can be solved, and probably most easily done if a project such as the proposed blockchain project gets the founding members to agree on a taxonomy.

There’s certainly more work to be done here, but I think that we’re on the right track with BadgeChain. The eight points set out by Greenspan seem to be met by the project as it relates to Open Badges.

If you’re a funder interested in the potential of Open Badges using blockchain technology, please get in touch with us!


Originally published at discours.es on March 3, 2016.