Crash Course in I-O Technology: A Crash Course in Blockchain

Richard N. Landers and Andrew B. Collmus, Old Dominion University

Blockchain seems to be all the techno-rage these days.  It is the technology underlying the cryptocurrency Bitcoin and the many altcoins that have come after it, such as Bitcoin Cash, Litecoin, and Ethereum.  Blockchain is poised to “disrupt” several industries, and consultancies like Deloitte claim that HR disruption is ahead.

To understand what might be disrupted and if I-O psychology should care, we need to dig a bit into what exactly blockchain is, what it does, and what potential it offers.  The best way to understand a technology is to recreate it yourself—think about how many years ago you learned ANOVA by creating a summary table by hand—so in this article, we will create a small blockchain using R to illustrate just how simple the basic concept is.  But first, let’s walk through it with words.

A blockchain is, at its core, a digital ledger.  In most cases, these ledgers are public and available on the Internet.  Each blockchain is a list of permanent and secure information that you want to keep and add to over time.  Each of these groupings of information is a “block.”  In the case of cryptocurrencies, blocks contain information about transactions.  For example, a Bitcoin ledger contains, among other things, a list of sale amounts, buyer IDs, and seller IDs.  Each time a new transaction is added to the Bitcoin ledger, the ledger grows by one block, and blocks can never be removed.  Thus: block-chain.

If you’re wondering why permanent public digital ledgers would be useful, it is most obvious in the case of cryptocurrencies, which is why we hear so much about them these days.  There are three major advantages.  First, because buyer IDs and seller IDs are encrypted, money can change hands without the identities of the buyer and seller becoming public.  In other words, I know that “user 123” made a purchase from “user 456,” but I have no immediate way to determine who 123 and 456 actually are.  However, if john@iopsych.com comes to me and says “I am user 456,” I can verify this easily by encrypting “john@iopsych.com”.  If my encryption turns up “456,” I have verified this person’s claim.

Second, because the ledger is public and on the Internet, there is no need for middlemen, which is a major issue in the financial sector.  If you have ever tried to send money over state lines, or worse, international borders, you might have noticed that there were a surprising number of organizations involved.  For example, if I want to send money from the United States to a friend in Germany, I can’t simply “send money.”  Instead, I would probably need to initiate a wire transfer, which typically carries fees and involves companies called “brokerage houses.”  The most common of these is Western Union.  That means if I want to send money to my friend, information must be collected, verified, and processed by me, my bank, the brokerage house, my friend’s bank, and then my friend: a minimum of five distinct steps are involved.  The transactions between each of us and our bank, and between each bank and the brokerage house, are all under a complex system of local, regional, national, and international laws.  By using a cryptocurrency, you can bypass literally all of that.  At least for now.

Third, because the ledger is public, it can be verified and tracked by an unlimited number of people and organizations at any given moment.  If someone tries to change an early block in the chain, the entire remainder of the blockchain is suddenly incorrect.

This combination of security, anonymity, and speed is what has made cryptocurrencies enormously popular, because these three characteristics are all quite valuable for financial transactions.  But can blockchain, the technology that enables cryptocurrencies to even exist, benefit HR and I-O?  To understand this, let’s first look at blockchain in action.

Let’s See It in Action

As described earlier, the best way to understand blockchain is to create one.  It’s not as difficult as it might seem!  Creating a blockchain fundamentally only requires two actions: the creation and encryption of blocks. We’ll do this in R.

First, let’s ensure we have the library we need, which we will use for encryption.

library(digest)

Next, let’s create a sample block so that we can see what goes inside:

starter_block = list(
       index=0,
       timestamp=Sys.time(),
       data="important information for first block",
       prior_hash="genesis",
       next_hash=NULL
)

This block is coded as a list object that contains five pieces of information.  The index simply counts which block we’re on, starting at zero.  The timestamp records when the item was added to the ledger.  Data contains whatever it is we want to track.

The next two items, prior_hash and next_hash are the key to blockchain.  A hash is the result of encryption.  There are numerous algorithms available to convert literally any piece of data into a cryptographic hash, and the better the algorithm you use, the more difficult it will be to reverse engineer the hash to produce whatever created it.  For example, try this in the R Console:

sha1("Encrypt me!")

You should see the following output:

2a2419070644fecacab078ebf1c6c92408e1baef

The fact that you and I and everyone else get exactly the same answer is the key to hashing; there is (theoretically) only thing that will produce that precise hash (i.e., a string containing the text, “Encrypt me!”), it took very little time to create the hash, and it’s very difficult to go in the reverse direction (i.e., from the hash back to “Encrypt me!”).  Thus, good hashes are easy to create, easy to verify, but difficult to reverse engineer.

The hashing algorithm we just used is called SHA-1, which stands for Secure Hash Algorithm 1.  These days, SHA-1 is not considered secure, because computing power has increased so dramatically over the past few years that SHA-1 can be reverse engineered in a reasonable amount of time with a sufficiently powerful computer.  Thus, modern cryptography typically uses some variant of SHA-2, which comes in 224, 256, 384, and 512-bit varieties.  The most common of these is SHA-256:

digest("Encrypt me!","sha256")

When you run that, you’ll see that the output hash is much longer.  In fact, due to its length, that hash has 2²⁵⁶ possible values.  Thus, it is incredibly unlikely that any two strings, any two pictures, any two audio clips, any two videos, or any two anything, after being hashed, would produce the same SHA-256 hash.  This translates into higher security, because it is extraordinarily difficult to reverse engineer the original data from which a SHA-256 hash is created (with modern computers).

Given this, the security advantages of blockchain come from the fact that each new block is hashed along with all previous blocks, and each new hash is stored inside each new block as it is created.  Thus, if you change the information contained within an early block, all the hashes that come after it will suddenly be incorrect.  This prevents people from attempting to rewrite the past within the ledger, because it will be immediately obvious to everyone else watching the ledger that something has changed that should not have been changed.

To illustrate, we will create two functions.  First, we need a function that hashes a block.  In the function below, we apply the SHA-256 hashing algorithm to the information contained within a block, then return the hash it creates.

create_block_hash = function(block) {
  to_be_hashed = list(
    block$index,
    block$timestamp,
    block$data,
    block$prior_hash
  )
  next_hash = digest(to_be_hashed, "sha256")
  return(next_hash)
}

As you can see, the function takes a block as input, then it hashes four of the pieces of information within that block, returning that hash as the output of the function.

Next, we write the function to create a new block based upon that hash:

create_new_block = function(prior_block, data_for_new_block) {
  new_block = list(index = prior_block$index + 1,
                   timestamp = Sys.time(),
                   data=data_for_new_block,
                   prior_hash=prior_block$next_hash
                   )
  new_block$next_hash = create_block_hash(new_block)
  return(new_block)
}

In this function, the previous block in the blockchain plus the new data are used as input to create a new block.  Then, this data is hashed using the first function I wrote above and included as part of the new block.  That means the block now contains unencrypted data plus an encrypted hash of those data.

That’s it!  We have the two functions necessary to create a blockchain.  To illustrate what’s happening in these two functions, try hashing the starter block we created earlier:

starter_block$next_hash = create_block_hash(starter_block)
starter_block

When you run this code, you’ll see that the starter_block list now contains a “next hash,” which is a SHA-256 encryption of itself.  We can start our blockchain with this newly encrypted block like so:

blockchain = list(starter_block)

and we can add new blocks to the blockchain directly:

blockchain[[2]] = create_new_block(blockchain[[1]], "new info for block 2")
blockchain[[3]] = create_new_block(blockchain[[2]], "new info for block 3")
blockchain[[4]] = create_new_block(blockchain[[3]], "new info for block 4")

In a “real” blockchain, to be used in the real world, we would want to create code to add blocks like this automatically, based upon requests from the people watching the blockchain ledger.  But for our toy example here, that just adds unnecessary complexity and is something we can leave to professional software engineers.

You can see the outcome of the hashing algorithm by looking at the content of our four-piece blockchain.  Within each block, the next_hash character vector gives a SHA-256 hash that is also the SHA-256 hash contained in the prior_hash vector of the next block. 

Put in programming terms, two relationships are therefore always true for any two sequential blocks within the chain:

1.       blockchain[[i]]$next_hash == blockchain[[i+1]]$prior_hash

2.       blockchain[[i+1]]$prior_hash == create_block_hash(blockchain[[i]])

By building a chain of blocks where these two equalities are always true, all blocks within that chain are linked together in a permanent sequence.  If any block is removed or changed, the hashes will no longer be accurate, and this is immediately obvious to anyone watching the ledger; that’s what maintains the security of the blockchain.

To Learn More

The R code I wrote to create a blockchain here is a simplified version of Datacamp’s exploration of blockchain in R, so if you want to dig just a little deeper, or if you want to see the same ideas in Python, I would recommend starting with one of those.  Once you have a better handle on the core idea, you might look at something like Hyperledger, which is a complete framework for creating your own blockchain and adds a lot of features that don’t exist in our toy blockchain, like proof of work, decentralization, and a management layer.

Having said that, frankly, I-O psychologists are never going to need to create a functional production-quality blockchain except to satisfy personal curiosity, so for the average I-O, the toy blockchain presented here is plenty to play around with.  Once you have a handle on the idea of a public-facing ledger that contains permanent data records and encrypts previous versions of itself as it is built over time, you have the core of the idea.  The remaining issue to explore is where this idea might be useful.

Conclusion

Understanding where blockchain could be applied to I-O and HR more broadly is right now the million-dollar question (literally).  There are a host of startups attempting to take advantage of this new technology to improve HR.

We reached out to many I-O, HR and business leaders to get a better feel for what type of questions and requests are being made regarding the use of blockchain in talent management. The majority of our respondents were unwilling to share or had not yet been approached with such questions. However, the head of an advanced analytics department in a large technology firm who wished to remain anonymous offered the following:

Blockchain has great potential in HR to speed up the delivery of employee information through the systems. Examples would be having all of your medical plans attached to your medical history within blockchain such that you can give your doctor the encrypt key any time and they would have a full history of you.

Blockchain could easily help in the onboarding/validation of new employees. Imagine if all of your employee docs and required paperwork were on blockchain. The amount of time saved from an HR onboarder to go find all relevant information would be dramatically faster than having to call around to each place to verify documents and history of employment.

Blockchain could eventually impact people in job search and recruiting. If a user has resume on blockchain, it's verified already and makes the search and hire process faster.

The most obvious and likely the first to happen will be an employee payment going through blockchain. This could save significant time and cost around all the 3rd party payers for companies. This would be beneficial for full time, part time, and contract workers.

It could also be an electronic replacement for those countries that need to have a paper copy of certain things for record. If those all switched to blockchain that is secure and distributed, there would be no need to create all the paper trail, storage facilities, and people to manage that paperwork.

And lastly, it will enable better security and relevance in areas like EMEA and beyond which have much stricter laws around global data privacy regulations.

Deloitte identified several use cases for blockchain in HR.  Some of these are more relevant to I-O than others.  One use case was payroll. Specifically, because many organizations are multinational entities, the process of paying their employees must move through several intermediaries as mentioned earlier in this article. However, because international money markets are volatile, some intermediaries take advantage of exchange-rate fluctuations to profit by optimizing the timing of payouts. Thus, in addition to cutting out the middleman, blockchain can be used here to lock in a specific and verifiable exchange rate, leading to greater transparency and efficiency in the exchange.  This is probably the biggest and most obvious advantage to blockchain in HR, although it is not particularly relevant to I-O.

Another HR use case identified by Deloitte was credential certification. Because job applicants will sometimes fudge or outright lie in application materials, blockchain could be used to create and store verifiable histories of credentials, such as GPA and degree earned from a university, background check status, or any other information used to make personnel decisions.  In I-O terms, this ideally increases the validity of (verifiable but often unverified) application materials and employment records.  Biodata, in particular, would benefit from blockchain.

A third use-case extended the idea of credential verification to include all types of HRIS information, including home addresses and medical records.  Thus, anyone needing this information and given the key could access that information immediately without the need for technological middlemen.  This is attractive due to the difficulty in reverse engineering modern encryption; theoretically, the people who should have access to the data can get access very easily, and the people that shouldn’t, can’t.  However, it should be noted that today’s “secure encryption” is tomorrow’s data breach, so organizations and HR departments would do well to exercise caution when dealing with confidential data regardless of the level of encryption.  Traditional data security practices are unlikely to disappear, but they are likely to change shape.  For I-O, the greatest advantage to blockchain of this type would be a more consistent way to access HR information when needed; anyone who has tried to integrate data from multiple HR data systems and thought, “Why does this have to be so difficult?” has already wished for blockchain without realizing it.

In summary, blockchain is a popular new technology that allows for decentralized, encrypted, and verifiable exchange of information. Each new block takes the existing information including an encrypted hash of that information, adds new information and a timestamp, then encrypts it all again before sending to the next block. As the latest buzzword in technology, blockchain will certainly be brought up to I-O practitioners as organizations and HR departments follow trends and strive for competitive advantage. We’ve identified some potential use-cases for HR. As with all new technologies, it is important to consider whether blockchain is necessary and actually adds value to an existing process. There will undoubtedly be new products, vendors, and services peddling blockchain in HR. We hope that with an increased understanding of what blockchain is and how it might be used, our readership is better able to navigate these claims and differentiate between innovative useful products and those capitalizing on buzz.

That’s it for the eighth edition of Crash Course!  If you have any questions, suggestions, or recommendations regarding blockchain or Crash Course, Richard would love to hear from you (rnlanders@tntlab.org; @rnlanders). If you have questions about blockchain in particular, my guest coauthor this week, Andrew Collmus, would be particularly happy to help (acollmus@odu.edu; @AndrewCollmus).