Cryptocurrencies, bitcoins and blockchains. Three terms, quite closely related, that anybody who’s even glanced through a technology newsletter in the recent past might have come across. Indeed, the buzz around blockchain is so strong these days that Medium.com suggested not one, not two but three - three! - featured articles in the space of two days on blockchain.
A quick round of research should throw up more than enough resources to learn more about blockchain, but here’s the ten-second digest: blockchains are blocks of data connected to each other through hash-key links and protected from manipulation through various techniques. In its simplest form, a blockchain looks like this:
Each block contains a certain number of transactions - credits, debits, reversals, assignments, etc. When the block is completed, it is “verified.” In the case of cryptocurrencies, this verification process involves the “miners” who might confirm the authenticity of all the transactions through one of various means - proof of work or proof of stake. Yet another method, although this one doesn't necessarily need miners, is consensus. Each of these concepts deserves its own article to be understood fully; suffice to say that these techniques have evolved in a relatively short span of time but are being vouched for by experts who’ve probed the blockchain structure for critical weaknesses.
Once a block is verified, it is replicated across the system of users who will be using it. That, in itself, is one of the biggest protections of a blockchain system: there are so many copies of it that a single-point attack, such as a hacker logging into the master database and altering it (in the case of a relational database management system, or RDBMS) will not serve any purpose since such a modification will change the signature (hash value) of only the block accessed, and thereby identify it as compromised against all the other copies that remain identical to each other.
Thus, once a block is verified and propagated, the records might as well be written in stone. Unlike an RDBMS, which allows CRUD operations (Create-Read-Update-Delete), a blockchain is write-once-read-only. Even a transaction entered in error must be addressed through a separate transaction that reverses it, and not by a convenient deletion of the record.
Blockchain was first visualized in 1991, but hadn’t really been deemed useful until 2008 when Satoshi Nakamoto decided to build the cryptocurrency, Bitcoin, on its structure. In the past few years, blockchain, at least in theory, has moved beyond cryptocurrencies. There are published use-cases for blockchain in EHRs (electronic health records), pharmaceutical manufacturing and logistics, supply chain and aviation industries.
A few months ago, as the hype around blockchain gained steam, the team at Plutomen sat down and analyzed the technology and its possible uses. The idea, a distant glimmer of hope at the time, was to find a use-case that wouldn’t be immediately obvious, but would still be a transformative tool for the right companies. After a lot of brainstorming (and storming in and out of our labs and conference rooms!), BlockERS was born.
BlockERS stands for Blockchain-based Employee Rewards System. As the name suggests, it is based on the blockchain model and oversees/ensures proper administration of employee rewards.
In the present setup, with a typical RDBMS-based human resources management system, the performance appraisal tool needs to be updated with the performances of each and every employee before they can be assigned hikes, bonuses or improvement treadmills for the next cycle. This is often a lengthy process, at times even obscure. And a convenient truth hides in plain sight while we ignore it: the system is only as strong as the database administrator (DBA).
The DBA is God where an RDBMS is concerned. The power to CRUD is in his/her hands.
A negative rating could, hypothetically and possibly - although not commonly - be turned into a positive one. Bonuses can be reappropriated; performances arbitrarily tweaked to suit another set of demands. It doesn’t need to happen for the danger to be clear and present. It is akin to crossing a highway. You might cross it a million times without issue, but the one time something goes wrong will truly be a catastrophe.
BlockERS, on the other hand, employs a blockchain system with smart-contracts built-in to manage the Key Result Areas (KRAs) / Key Performance Indicators (KPIs) of the employees. A smart-contract is a programmable script loaded into the blockchain that activates transactions if certain conditions are fulfilled. A salesperson, for instance, will receive his/her commission on closing a sale as per the terms of the smart-contract for his/her designation. Similarly, an HR practitioner who achieves a certain employee-engagement score may be awarded as per the smart contract set for employees of that specific role.
To build BlockERS, we’ve used the HyperLedger Fabric implementation of blockchain. Hyperledger has been backed by both IBM and the Linux foundation; unlike other implementations like Ethereum or Bitcoin, Hyperledger can work even without a typical cryptocurrency as its transactional unit. HyperLedger’s Fabric variant allows conditional or permissioned consensus as a verification mechanism, which makes the process faster than “mining”, and requires less computational power overall to execute.
The whole blockchain of an organization is then shared across as many nodes as possible. Thus, as each block is completed and verified, it is propagated through the network and copies are shared with different employees. Unless all these employees - chosen at the employer’s discretion - act in concert, any illegal post-hoc modification of a transaction will be barred from being a part of the official record.
BlockERS will be extremely suitable for an organization where there are internal transactions - such as captive canteens, leave encashment policies, asset management, travel desks, employee discounts, etc. In addition to being an immutable data structure impervious to attacks, BlockERS also reduces the need for complicated network resources by positioning a copy of the verified blocks with each of those employees and/or departments that need access to it. Thus, queries will be faster. Errors can be identified quickly.
After all, as Biswajit Choudhry wrote in this piece on thenewsminute.com, if Nirav Modi or Vijay Mallya’s banks had tried to register their lien on the pledged assets, they would have quickly realized that the assets already had other claims on them. Similarly, in BlockERS, any employee trying to manipulate the system can be quickly identified and appropriately acted against.
When the employee wants to redeem a legal reward, the BlockERS system can authorize a conversion of the reward tokens earned into another quantifiable measure of the employee’s choosing. For instance, an Operations/SCM employee might decide to redeem the 7 tokens he has earned for an extra couple of days off. If the employee has no such eligibility, the system can immediately understand the situation.
Even as I share this, we are but a few days away from releasing our prototype of BlockERS. It marks a momentous change in the way we’ve addressed the problems of a company-administered employee rewards system… unblocking it, if you will pardon the pun. Do join us then for a quick look to see if this solution can help your organization!