In the previous post we added to the Open Badges’ DNA its first genes extracted from the blockchain. We obtained the following results:
Everything can be represented as a Badge — everything is relationship;
A BadgeChain is made of chained badges (not yet a blockchain);
A BadgeChain is a like a distributed database: badges are stored all over the Internet.
New objects can grow organically from the aggregation of badges in the BadgeChain — e.g. ePortfolios.
There are two points we have not addressed yet
How is the BadgeChain practically stored?
How can we trust the content of the BadgeChain?
The trustworthy BadgeChain
Can we check whether the components of the BadgeChain, Open Badges, are authentic (the issuer is the issuer, the earner is the earner, etc.) simply by looking at them, just as we would do to check whether a banknote is counterfeit? The answer is yes, and the means to do it is named cryptography. Here are the conditions to create badges that resist effective counterfeiting:
Every participant in the network uses one or more public /private key pair;
The public keys are used as the identities of the participants in the network.
The private keysare used to encrypt information that can then be deciphered using the matching public keys.
Reciprocally, the private keys are used to decipher any information encrypted by the matching public keys
The picture below illustrates the process when Alice creates a badge containing the information that will be used to verify whether it is authentic or not.
How to create trustworthy badges using cryptography?
What happens when Alice creates a badge:
For practical reasons (saving space and time) the content of the badge created by Alice is transformed into a digest, a small and unique representation of the complete badge using a public algorithm called hashing. It is as impossible to reconstruct the original badge from its digest, as it would be to rewrite an article from its summary.
A signature is computed from the badge’s digest using Alice’s private key which is then added to the badge.
How the integrity of the badge and whether Alice is the issuer are checked:
A digestof the badge is computed with the same hashing function used by Alice.
The signature of the badge is deciphered using Alice’s public key which is provided by the Issuer metadata of the badge. The result should be the digest initially created, before being encrypted by Alice’s private key.
If the two digests are different, then we can conclude that the badge is counterfeit.
Without entering into the details of cryptography, one of the properties of this kind of encryption is that it is not possible from the knowledge of public information (the public key, signature and digest) to guess what the original private key is. It is practically impossible for anybody but Alice to create a badge where she is declared as being the issuer — at least until quantum computing becomes a reality!. The down points of cryptography are that the private key must remain an absolute secret and must not be lost as it cannot be recreated (but you can save several copies in different safe places!).
The private key can be used to create one or more receiving badges, i.e. badges that will appear as the actual earners of the earned badges. This way one public/private key pair can be used to create multiple identifiers which are used to collect different types of badges.
Alice creates 2 badges as IDs to collect different types of badges
Furthermore, Alice can create multiple public/private key to keep her different identities totally separate — in the example above, the two badge identifiers make reference to the same public key, so the identities can be associated without any effort.
How is the BadgeChain stored?
To connect a badge to another badge, badges need to have an address (or an identifier that can be translated into an address) where they can be found. When Alice creates Alice 1 and Alice 2, the two genesis badges that will be used to aggregate future badges, they could be stored anywhere on the web. Alice could decide that all the badges she receives will be stored on her blog, so the location of her first genesis badge could be something like http://www.aliceblog.me/badges/alice1.png. When Bob wants to issue a badge to Alice, he can then use this address as the earner of that new badge.
While this seems to work, in fact it does not. Let us imagine for a moment that Bob issues a first badge to Alice, then for whatever reason wants to endorse the badge he has just issued, how could he know the address before Alice has stored the badge? And when she has stored the new badge, how could Bob know its address?
The solution to this problem is twofolds:
every badge is identified by a unique identifier or UID
there is a means to translate a UID into a real address
For the sake of the demonstration, let us assume that each badge’s signature is unique, we could keep a table with two entries: the signature of the badge, and its real address. When we want to access the content of a badge, we look in the table for the signature to find the real location of the badge. If the holder of the badge wants to move the badges to another location, the entry in the table is changed — and if the earner wants to hide the badge, the address is erased.
A similar mechanism is used on the web to locate its content. For example, the identifier of my blog is learningfutures.eu, which is associated to the IP address 108.178.52.174. The translation of the string of characters (learningfutures.eu) into the real address on the Web is performed by a Domain Name Server or DNS. If tomorrow I decided to move my blog to another server with another IP address, I would just have to notify the DNS of the new address, and people would be able to continue to read my blog as usual.
Badges real addresses are saved in a shared table that is updated when a badge is moved
Let us call our (free) interpretation and application of the DNS mechanism to Open Badges a BNS or Badge Name Server. A BNS has several interesting features:
The issuer enters the UID on creation of the badge — the UID column can only be written by issuers.
The earner provides the real address of the badge after it has been accepted and stored — the real address can only be written by the earners of a badge.
The earner can change the address of a badge (to move badges to other locations) or erase it.
multiple copies of the BNS can be distributed among the members of the network and are synchronised by applying certain rules.
The table of the BNS could be improved by providing for each UID (the signature in our demonstration) a column with the issuer and the earner of the badge, making it easy to retrieve all the badges associated to an earner or an issuer. To revoke a badge, the badge issuer would notify the BNS to erase the entry matching the UID of the badge — after checking the authenticity of the issuer! To take into account the possibility that a badge might have been revoked, the verification mechanism of the badge integrity would start by checking that the signature of the badge is still in the BNS. If not, it would mean that the badge has been revoked.
If erasing an entry in the BNS might not seem enough to effectively revoke a badge (would not it be better if we could erase the badge altogether?) in reality it is perfectly sufficient as the original earners are facing the following dilemma:
If they keep a copy of the badge, any person displaying the badge will see that it has been revoked
If they erase all the copies of the badge, nobody will ever know that they once had this badge and that it is now revoked
Similarly, we cannot forbid people to create badges that would not pass the integrity test (e.g. using the public key of an issuer that is not themselves) and store those faked badges anywhere on the Web. While legal action might be sometimes necessary, once everybody understands that the only valid reference for the integrity of Open Badges is the BNS, fake badges should not have a negative impact on the trustworthiness of the BadgeChain ecosystem —as they will not be part of it. Web crawlers should be able to discover where undesired and faked badges are stored.
What have we achieved at this point?
We can create trustworthy BadgeChains that can be moved around the web. A table distributed among the members of the Open Badge ecosystem (the BNS) maintains the integrity of the BadgeChain including the revocation of badges.
There are still problems to address, in particular: as the badge earners are responsible for storing their badges, problems would arise if their storage crashed and did not have a backup to restore them — a problem unknown to blockchains with their distributed ledgers!
We still do not have a fully functional blockchain, but we are getting closer.
In the previous post, we looked at the relationship between trust, Open Badges and blockchains. To paraphrase George Bernard Shaw, one could say: Open Badges and blockchains are two technologies separated by a common idea [trust].
To explore how Open Badges and blockchains could merge into a new technical object, my reasoning will pass through several stages. We will start with a BadgeChain that does not make any reference to the blockchain technology, then, step by step, we will describe the mutation of this initial object through the incorporation of new genes into its DNA — hoping that we will not have created a chimera!
BadgeChain take one: everything is a badge
To create something that looks like a BadgeChain, we need to link badges together; there are multiple ways this can be achieved:
Indirectly: badges are “connected” through each individual issuer and earner. The issuer is a kind of “connector” between all the badges issued (and their earners), the earner is a kind of “connector” between all the badges received (and their issuers). Badges can also be connected through the alignment metadata, a list of objects describing educational standards — a property of the version 1.5 of the standard that has not been widely exploited.
Directly: badges are literally linked to other badges. For example, an endorsement badge could use the address of the badge being endorsed as the identification for the earner of that badge.
An endorsement as a connected badge
As a chain invokes the image of a direct connection between its constituents, we will focus our attention on creating an environment where everything is a badge. There is a legitimate reason to use badges for everything: once we understand that a badge is a relationship (between an issuer and an earner), saying everything is a badge is not different from saying everything is relationships. Making everything a badge should make it as easy to play with them as it would be with Lego™ blocks.
NB: while I often use the Lego™ metaphor to describe the simplicity of Open Badges and how it makes it possible for educators to practice bricolage, if I am honest, in the depiction of the state of the badges as a Lego blocks, I should write:
it is not possible to plug them together: square tubes do not match round studs (there are also oblong studs on half of the top and half the bottom is flat with no hollow parts)
if you insist on building something with them, do not sneeze, or you’ll have to restart from scratch!
when you discover that there is not much you can do with them, you read the manual and understand why there was a bag, a kind of backpack: it’s to carry them with you wherever you go to show your collection, to a[n] (probably uninterested or condescending) audience…
The next Open Badge standard should bring us closer to the conditions for Lego™ block-like badges, with matching tubes and studs. This should open the Open Badge ecosystem for some serious and rich play to take place (*).
In a world where everything is a badge, we could use badges for many different purposes: creating personal identifiers, linking to evidence, setting criteria for issuing or receiving a badge, etc. Some of these options are described in the table below.
Everything is a BadgeEverything is a Badge
In the picture above, the arrows elicit the links between the components of a badge. The green and purple badges are identifiers with the green badge being self-issued (self-referential). The Issuer of the yellow badge at the centre is the purple badge so the content of the Issuer metadata of the yellow badge contains the address of the purple badge. The Evidence metadata links to a blue badge that was issued by the issuer identified by the purple badge — it could be an observation of the learner’s performance, and the Evidence of the blue badge could be a video of the observation and the Criteria the narrative of the observation by the issuer.
There are probably better ways to connect badges together, but what we want at this point is not to decide on what is the best possible way to connect badges together but to explore the properties of chaining badges together: what are the properties of chained badges that badges placed in a bag do not have?
The properties of chained badges
Chained badges change the topography of the Open Badge landscape where issuers are currently at the summit of their Open Badge dominions. Chained badges are a means to put an end to the strong asymmetry between issuers and earners implemented in the original version of the Open Badge Infrastructure — surreptitiously underpinned by the formal education credentialing model.
By connecting badges together, we are creating interwoven threads of data, so starting from one person’s identifier in the network we are able to follow multiple paths that connect this person to all the other participants in the network, their relationships, knowledge and the artefacts produced. Chained badges create one global distributed database from where one can pull different threads, creating multiple narratives, from different points of view: individual, community, organisational, city and region.
Moreover, when looking at the picture above, we are looking at something that might speak to the ePortfolio practitioner. By connecting together pieces of information we are creating meaning and assembling the elements of a new artefact: a portfolio. Most of us are familiar with the action verbs associated with ePortfolios: collect, select, connect, reflect — BTW, those verbs do not describe a “sequence” as the collection could be the result of a reflection and conversely! Open Badges are a means to simultaneously collect and connect, while creating meaning providing the fuel for further reflection (and action!).
Until now, the understanding of the link between ePortfolios and badges is dominated by ePortfolios as a place to display Open Badges and the use of ePortfolios to earn a badge — this is particularly clear when practitioners oppose ePortfolios and Open Badges or see them as “complementary.”. In this perspective, the link between ePortfolios and Open Badges is mainly functional, not organic; they are treated as two different objects.
bee-badges for hive-portfolios
My proposal is that Open Badges and ePortfolios are not “complementary” loosely connected objects , but Open Badges are the substratum from which ePortfolios can grow organically, like a beehive out of the activity of the bees — bee-badges for hive-portfolios!
By providing a space where everything is a badge, we have also resolved the issue of interoperability: we render obsolete standards like IMS ePortfolio (hardly used) and LEAP2A (slightly more used) that are based on a fragmented vision of information systems, in particular the storage of data, something that is now challenged with the increased adoption of distributed ledgers (blockchains).
(*) Nate Otto commented on this point: “the Learning Pathways data vocabulary allows a data format that enables this. See https://usecanvas.com/ottonomy/learning-pathway-models-api/47JdBeSCqzKJ1v3H8Oswlo — which shows some “report style” syntaxes using this proposed vocabulary. The context is not build yet, but it is a data model that allows us to build nested hierarchies of the legos, and then to each lego, you may specify a relationship to suggested badges, earned Badge Assertions, etc.”
This post is the third in a series of five blog posts designed to explore, inform, and encourage public discussions about the possibilities, opportunities, and challenges arising at the intersection of Open Badges and blockchain technology.
Part 1: “The Open Badges Part”
Part 2: “The Blockchain Part”
Over the last five years, we have dedicated ourselves to working in the open as founding members of the open badges revolution. We continue to share our insights publicly in this blog post, exploring the possibilities of combining badges and blockchain, two innovative, new technologies. As always, we aim to keep the language simple and straightforward. (If you’re brand new to open badges, you can find the original open badges white paper here.)
A vital open badges ecosystem
In our first post, we dived into the definition and history of open badges, providing information regarding the technology that underpins them. In our second post, we focused on defining blockchain, hinted at its adoption rate, and referenced its increasing power in the software implementation world. Here we’ll explore some of the ways that blockchain can serve the needs of the open badges ecosystem. That means investigating issues and impasses that currently beleaguer open badges and their related ecosystem development. Areas we’ll cover include hosting, identity, verification, and privacy; however, we acknowledge that there are additional issues that impact further open badges ecosystem development, including evidence and endorsement.
Here it’s important to state that all of our comments addressing concerns and roadblocks are noted with this caveat: the open badges ecosystem is vital and growing in dynamic ways and has been for years. We assert that its continued surging growth is a direct response to the intrinsic hypothesis embedded in the open badges initiative — that many forms of learning were/are going unrecognized and under-appreciated. In this important aspect, the open badges effort, regardless of its current issues, is succeeding wildly in its aim of representing learning in new and beneficial ways.
In the following sections, we’ll link existing open badges development with blockchain possibilities, some of which are conceptual concerns and some of which are affordances offered by a new technology.
Stakeholders
Currently the open badges ecosystem is composed of at least three essential audiences: earners (people who earn recognition through badges), issuers (organizations and individuals who provide recognition through badges) and consumers (individuals and organizations that make use of / evaluate badges for their own purposes). These different constituencies have different drivers, desires, and requirements. The open badges ecosystem has been structured to acknowledge, accommodate, and nurture each of these audiences. Think of them as a three legged stool: remove one of the legs and the proposed ecosystem structure topples over. Each of these audiences plays important and reinforcing roles at different times. In this post (3.1) and the follow-on sister post (3.2), we’ll explore how a BadgeChain implementation could affect their influence, address their difficulties, and encourage continued development.
Issuer consideration: lifetime hosting
In the existing software construct, open badges contain three files: the assertion, the badge class, and the issuer object. The last acts as the metadata reference to the issuer. Once issued, badges become an artifact that must be hosted permanently. Right now, most badges typically reside on the originating badge issuers’ servers and, somewhat like transcripts, they must remain hosted during the life of the badge, which may be as long as a lifespan or as long as the earner or consumer requires them.
Badges with signed assertions require issuers to host private keys for the life of the badge. Baked into these arrangements are implicit issues of trust intertwined with explicit financial, physical, and social capital costs. While this aspect of participation is not entirely insurmountable, it does complicate long term viability. For some issuers or wannabe issuers, this requirement directly infringes on their ability to fully engage in the open badges ecosystem.
BadgeChain viewpoint
With the blockchain construct, responsibility for information accuracy shifts away from the (hosting) issuer as the primary reference point to the information itself. So how does this work? The hosting requirement is distributed to all nodes on the blockchain. All badge metadata information is embedded within the blockchain and permanently hosted by all nodes participating in the blockchain. Consequently, there is no requirement for issuers to host badges because that information is hosted on the blockchain itself.
As long as the chain (or ledger) exists, information about any badge on the ledger will be available, regardless of whether or not the badge issuer goes out of business, stops issuing badges, or disappears altogether. Obviously, issuers are essential to the open badges ecosystem; however, with blockchain, their hosting responsibilities and to a certain degree, their requirement for information maintenance, end upon badge issuance.
Earner + Consumer consideration: zombie badges
If by some chance a badge is cut loose from its hosting location, whether accidentally or intentionally, it becomes a potential liability to both the earner and the open badges ecosystem. Why? Because without the vital hosting reference links that confirm it, the badge can no longer be validated or verified. Consequently, the badge becomes orphaned and, for the most part, useless to potential consumers. In colloquial terms, this is a zombie badge: dead in most respects despite any original implied or actual value.
BadgeChain viewpoint
With blockchain, the zombie badge concern can be not only mitigated but dispensed with altogether. Blockchain is built upon a ledger concept, and because the ledger acts as an ongoing reference point, badges cannot become zombified. Why? Because issuer verification is written into the ledger when the badge is written into the ledger: verification becomes an artifact of the issued badge.
The open badges specification references external urls that may or may not be hosted on the issuers’ servers. These urls include the criteria, the part of the metadata that describes earning, and the evidence, the part of the metadata that indicates work requirements. Currently, both criteria and evidence each have their own url. While the 2.0 specification work is exploring alternatives to existing structural elements of the badge metadata, like embedding criteria content directly in the badge and allowing evidence to refer to an array of urls with identifiers, even these alterations leave holes in verifiability and validation.
BadgeChain viewpoint
Because badge evidence can be a file or website accessible via a url which we understand to be unreliable. Evidence plays a critical role as it accomplishes two things: it clearly indicates a badge’s learning/earning requirements, and it provides proof to consumers of completion. Evidence that a consumer will evaluate on their own terms. With the blockchain, it is possible to store evidence files, whether or not they are videos, content, audio. etc. Storj.io & bitproof.io are two such examples of services that will encrypt and store files.
A further possibility involves combining the ledger capability of blockchain with the distributed web, two peer-to-peer systems. Projects like IPFS (Interplanetary File System) host files and web pages on a distributed system. It’s conceivable that viewers (most likely consumers or proposed consumers) of the files could also host them. Regarding open badges, this idea could be extended to include audiences acting as hosts for evidence files. Now it’s a bit futuristic, but using this scenario, it’s possible that this include baked badges as well: a slightly deeper exploration can be found here.
Issuer + Earner + Consumer consideration: data
The data from open badges is currently inaccessible unless issuers volunteer it or badge collection platforms like the Mozilla Backpack provide it. Even today, it’s difficult to ascertain which badges have been claimed or which badges have been viewed / consumed. And yet, inquiries about open badges issuing, distribution, and use are among the most common requests heard today. How many organizations are issuing badges? Who are they? What badges are they issuing? How many are they issuing? Are issued badges being claimed by earners? How many earned badges are being viewed and consumed? Who is consuming them? Are patterns emerging?
No issuer wants their badges to sit idly on their servers, unclaimed or even unacknowledged, but the current open badges infrastructure allows for that unintended possibility. While some issuing platforms provide ways for earners to share their badges publicly, not every issuer does. Additionally, some platforms have created an interface that links to the Mozilla open badges backpack, a reference implementation of a badge repository, sharing, and display site, but it’s not a requirement of the Open Badges Specification. And even though many badge earners opt to push their badges to a badge collection platforms like the Mozilla backpack, all of that content is still only a subset of all badges issued.
BadgeChain viewpoint
Once again, the value of a ledger that records all transactions reveals itself. Not only is the ledger hosted in a distributed manner, but transactions, once they are added to blocks, become public. This is a dramatic improvement in badge data transparency. Generally speaking, it is possible for issuers, badge classes and assertions to be publicly accessible on blockchain. The public nature of blockchain makes data much more accessible and referenceable than previously has been possible — even in a complicated example of multiple chains containing multiple badges and other credentials.
Data-derived answers to the considerations noted above will reveal the true nature of open badges: as powerful, information-rich tools. By providing a window into what makes a badge, or series of badges, useful and valuable, many types of connections can be generated, e.g., issuers to other issuers, earners to opportunities, and consumers to issuers and earners. This information can help to create a virtuous circle that benefits the entire open badges ecosystem.
Of course, as with all personal digital data, privacy issues must be considered closely. Interestingly, blockchain implementations of open badges may differ from how the majority of blockchain transactions currently work. These considerations and challenges are precisely the areas that BadgeChain is exploring.
— —
A word about BadgeChain + funding
BadgeChain is an open source think tank focused on the intersection of open badges and the blockchain for the public good. While we currently are investigating blockchain affordances with regards to learning recognition (i.e., not developing specific tools), we have ideas! Lots of ideas. And we are searching for funding opportunities to continue this exploration and possibly build/expand upon tools both existing and new. If you are intrigued by this work and have ideas of your own pertaining to development activities, please contact us. We are available for discussions regarding general consulting as well as specific projects.
While not initially coined to describe a technical object, but rather a team of Open Badge enthusiasts willing to exploit the benefits of blockchains, BadgeChain is also a word that might be used in the future to describe a new technical object resulting from the merger of blockchains and Open Badges.
When we started the BadgeChain group, the initial idea was to explore how blockchains could contribute towards improving the Open Badge technology and experience. There are a number of limitations to what one can do with Open Badges today that blockchains seem to be able to outsmart. Our initial reflection looked at the application of blockchain ideas to Open Badges. What has not yet been explored is the application of Open Badge ideas to blockchains: what could we do to blockchains if they used what we know about Open Badges?
About Trust
Both Open Badges and blockchains are related to trust but they do it in almost opposite ways. As I have written many times, Open Badges are trust statements that could be combined to create chains and networks of trust. The information on how the members of the network trust each other can be used as the basis to establish trustworthy transactions — if 32 Open Badge experts trust Slava’s expertise on badges as well as 53 clients, I’m inclined to trust Slava to work with me on my next project.
Blockchains on the other hand are a means to establish trustworthy transactions even if those engaged in transactions do not trust each other. The trustworthiness of the transactions is not a property depending on the participants, their behaviour or the data they provide but on an algorithm controlling the trustworthiness of the next blocks added to the chain. The blockchain technology was designed to eliminate the human factor from making the decision on whether a transaction is trustworthy or not.
BadgeChain vs. blockchain
NB: many articles on the Web describe blockchains as trustless. What is meant is that trustworthy transactions are possible without the involvement of any trustedauthority (a bank, a notary or a registrar) and despite the fact that the parties involved do not trust each other. Trust is fully embedded in the blockchain infrastructure and does not need human intervention.
With the BadgeChain, trust is a property emerging from the participants’ behaviour, with blockchain trust is a property that ignores participants behaviour. One builds dynamic multidimensional networks i, the other an ever growing unidimensional chain. One is able to add and delete data (withdraw trust), the other can only add data (write only). One has emerged from the world of informal education, the other from the formal world of international business and finance.
BadgeChain vs Blockchain
From the previous description, any attempt at combining blockchains with Open Badges into a new technical object might sound like the marriage of the carp and rabbit! Yet, it is what we are going to try to achieve.
BadgeChain = Open Badges * blockchains
Different approaches are possible for merging Open Badges with blockchains:
Assimilation: the blockchain provides a more secure way to store credentials, so institutions do not have to bother with Open Badges.
Integration: the blockchain is a distributed database, where badges are stored as they would be in any other database (MySQL, Oracle, Fedora, etc.).
Accommodation: Open Badges are used to rethink blockchain architecture, protocols and algorithms
The assimilation model is already in action and will soon be adopted by all those who do not see in Open Badges anything more than credentials. Let’s face it, blockchains, even in their infant stage, are far superior to the current Open Badge technology for storing academic credentials. Moreover it is an opportunity for institutions to reassess their power as credentialing authorities. After all, why bother with Open Badges if any institution can create their own private chain and put on it the data they wish. Organisations already in the credentialing business can move directly to the blockchain without having to go through the Open Badges stage.
The integration model is a means for the Open Badge practitioners to continue business as usual while exploiting the unique properties of blockchains to correct some of the shortcomings of the current Open Badge Infrastructure. The integration model has also its drawbacks, like the lack of maturity of blockchain technology, a characteristic shared by the Open Badge infrastructure… There might be advantages in building a future together rather than getting older apart…
One of the main value propositions of the blockchain for integration is the ability create fully trustworthy and easy to verify records. Another main value is its ubiquitous database: the blockchain frees the storage of Open Badges from any individual storage, so badge holders are not forced to choose between one platform or another to store their badges. Service providers (e.g. issuing platforms) will be free to concentrate on added value services rather than trying to improve an idiosyncratic technology.
how could Open Badges help in creating a new type of blockchain exploiting the trust relationships captured by Open Badges?
The accommodation model starts with a question: how could Open Badges help in creating a new type of blockchain exploiting the trust relationships captured by Open Badges? It is what we are going to explore over the next posts, moving gradually away from the current Open Badge infrastructure to a possible BadgeChain infrastructure.
Many thanks to Nate Otto for his comments and suggestions on the first draft of this series of posts.
But what exactly is blockchain, and what are its implications for higher education?
Originally created as the underlying database for bitcoin (the peer-to-peer digital asset and payment system), blockchain’s technology is now being seen as valuable and purposeful beyond the financial sector. The advantages blockchain provides to store information on a secure, permanent, historical ledger that can be both public and private will change how edtech applications approach student data.
In higher ed this means that student data could be shared across many institutions — rather than a single one — and also include data from online learning tools, co-curricular activities, employment history and other learning experiences. This would allow the data to be exchanged, understood and validated amongst many parties. Imagine the pictures of students’ learning experiences that this could provide and how these pictures could help develop and improve upon course design, facilitate transferring credits, or prove qualifications for a job to a potential employer.
A Brief Blockchain History
To understand how blockchain works, let’s take a step back and consider some history. Take MySQL, for instance, which is considered to be one of the world’s most widely used relational databases. When it was created over 20 years ago, it made it possible for more developers to have affordable, easy to use, open-source databases. MySQL is hosted and controlled by the applications that use it. This puts the onus of access to the data and security precautions solely on the application provider.
Blockchain takes a different approach by distributing data equally amongst its participants. A public blockchain like the one bitcoin uses is distributed amongst thousands of participants (also called miners). To give you an idea of how many participants there can be, take a look at Bitnode which as of this writing is showing 7,071 miners participating in Bitcoin. Not all blockchains will have this many participants, but nonetheless this distribution provides a higher level of permanence than one application hosting its own database.
Blockchain is literally a chain of blocks. Often this chain is referred to as a ledger. Each block can contain hundreds of transactions (the data) waiting to be added to the blockchain. The blocks are in numerical order and only one block can be added at a time, with each block referencing the previous one. Each block is a link on the chain and is mathematically reliant on the one to which it is connected. There isn’t a central authority overseeing transactions. Instead, validity is determined by how the chain is generated providing assurance that blocks can’t be tampered with or duplicated. Even though the blocks are described as transactions, the data is not always financial. It can be content of any kind, including files.
The miners play a critical role in the creation of blocks and distributed nature of blockchain. To create the blocks each miner must host a copy of the entire ledger. Miners are incentivized to do this by being paid a reward and potentially collecting a fee for each transaction they process. They listen for incoming data, process it and attempt to fit as many transactions as they can into a block. Typically transactions with larger fees get processed first. Once a block is validated and published to the chain, the chain is redistributed so that all miners get the same update. Then it begins again.
Implications for Higher-Ed
It’s important to note that not all blockchains will use bitcoins, mining or apply the same rules to mining as bitcoin does. Blockchains could be managed by a consortium where members make the decisions about how blocks are processed. Also, blockchains can be private where one organization controls everything. A university may be interested in hosting a private blockchain or perhaps a group of universities. An ecosystem like Open Badges, which generates digital representations of learning and skills, may consider a consortium blockchain.
Blockchain is clearly more than just hype. Last fall, MIT Media Lab announced that it is developing software to issue digital certificates on the Bitcoin Blockchain. Holberton School has started delivering its academic credentials in a partnership with Bitproof, a blockchain-based notary system that proves ownership of content. In the Open Badges community, the BadgeChain team has started exploring how badges can be advanced by blockchain. Sony Global Education developed blockchain technology that enables secure sharing of academic records.
It’s also worth checking out Learning Is Earning, originally presented by Jane McGonigal at SXSW 2016. Learning Is Earning introduces a concept of “Edublocks,” which represent units of hours of learning which are written to a blockchain and can be used to “pay” for additional learning opportunities. Many shake their head at the concept of learning being measured in hours but nonetheless, the site and video do a nice job of illustrating how a blockchain in an educational context could operate.
We are still very much in the early days of blockchain in both development and adoption, and there are some challenges: Bitcoin costs are variable and still too difficult to buy, transactions are taking longer, and it’s reliant on users to store the public and private keys used to track transactions safely and permanently. Even with these challenges and likely many more, you can bet that it’s here to stay with adaptations, experiments and innovations on the way at a faster pace. It’s likely that your students soon will be or already are buying things with bitcoin and that the applications they use outside of your institutions, including the ones that your students create, will embrace the blockchain first.
We’re excited by the amazing response we’ve been getting. Thanks! You have been finding and following the BadgeChain work here on Medium and on Twitter @BadgeChain.
As you know, we have a temporary website up at http://badgechain.com. Our new BadgeChain site is in progress, so we wanted to share a brief update on two pieces of the future site: the calendar and the roadmap.
Calendar
You want to stay up to date with the BadgeChain work: we get it. So, we have created a public BadgeChain google calendar for you! Subscribe to it for reminders to attend our biweekly BadgeChain Community Calls. (We have one this Wednesday, May 11.) The calendar is where you’ll find activity details and events as the work continues to grow and evolve, so subscribe to it now. Bonus: never worry about call timezone conversion again. Following us on Twitter @BadgeChain gets you call announcements as well.
Roadmap
As we have repeatedly noted, working in the open is baked into our process. We believe that public roadmaps are not only meaningful but useful for building the future we want. We built them at Mozilla when we were working to launch open badges and developing the web literacy map. We wrote them at the Badge Alliance when we continued to build the open badges ecosystem network. So, continuing with that proud tradition, we are pleased to announce BadgeChain’s first public roadmap.
By the way, we’ll be discussing the roadmap during this Wednesday’s (May 11) BadgeChain Community Call.
Next steps
Subscribe to the calendar, review the roadmap, and consider how all of this might fit with your work. The real next steps are figuring out how we might build the future we want together.
BadgeChain keeps you up to date on the ways in which blockchain and related distributed technologies intersect with education, politics, business, and society.
Follow Us