Building An Enterprise Blockchain

The word has come down from the top: Your company is going blockchain, and you will be implementing it. You have heard the buzz and are aware there is a difference between blockchain – the distributed, peer-to-peer ledger system – and its digital currency cousin, Bitcoin, which has been in the headlines. But how do you build an enterprise-class blockchain?

Let’s start with the basic premise, as that will inform the architectural and technical choices you make. Organizations are jumping on the blockchain bandwagon as a means of making transactions that span multiple parties simpler, more efficient and available at a lower cost while helping build trust.

Take the Walmart food safety pilot as an example. Walmart, which is regarded as having one of the best food traceability systems in the industry, completed a test using traditional methods to trace the origin of mangoes. The process of tracking a package of mangoes from farm of origin usually took six days, 18 hours and 26 minutes. With blockchain, it took just 2.2 seconds.

Of course, not everybody is Walmart and each vertical has its own set of domain-specific processes and businesses. The considerations that govern the sector your particular organization operates in will also determine how your blockchain is built.

Getting Started With Blockchain

So just how does one go about building a distributed and growing transactional system, that’s capable of spanning multiple parties, of running in real-time and that’s both open and secure?

The first step to consider, says Ashok Reddy general manager of CA Technologies, is not technical but rather regulatory – the subject of compliance. “Within an enterprise, there must be permission, which means the team has to decide: ‘Which data am I going to allow on the ledger and who will read it?’ How do we verify the transactions?  Who does the proof of work? Otherwise, it’s just a shared ledger.”

The next issue to consider is which fabric to use. “You have to decide between Hyperledger Fabric, Ethereum or Corda. Or you could decide to work heterogeneously because not all parts of the network are using the same fabric – maybe banks and their suppliers are using different types,“ Reddy says.

The choice you make will depend on the nature of your organization – whether you’re a B2B provider or in the consumer market. Hyperledger is built for the B2B-type supply chain, while Ethereum is aimed for the consumer market and crypto-currency deployment. There’s also the issue of developers: Ethereum and Corda have a larger ecosystem of developers to choose from.

Underlying this choice is how an organization wants to install blockchain: the technology comes in two flavors: permission-less, meaning anyone can join, transact, inspect or help build consensus, and permissioned where only pre-approved members can do so. Hyperledger and Corda are permissioned systems, while Ethereum is permission-less. There are other differences too: Hyperledger is the only permissioned blockchain system that runs on mainframe and mid-range systems, which are present in many enterprises, while Corda is a smart contract system – one that can self-execute when the conditions set out in the contract are met.

Creating Digital Trust

The Linux Foundation’s Hyperledger Project can work with Ethereum systems, a fact that can prove handy because you are not potentially forced into choosing between one or the other. Hyperledger’s executive director, Brian Behlendorf, told us: “Hyperledger has a project, Hyperledger Burrow, that implements the Ethereum Virtual Machine standard, and can be used in enterprise environments. But we don’t have anything to do with the cryptocurrency side of them.”

If you do go with more than one supplier, it’ll raise further challenges. Reddy says: “Let’s assume that you choose one of them, where is the system of record. How do you enforce security? How can you create trust when you’re working with people with whom you don’t have a previous relationship?”

This, again, is not necessarily a technical issue – although there’s a need to ensure that a company deploys rigorous security tools, since blockchain technology requires a great deal of trust, making public blockchains particularly vulnerable.

For Reddy, it is not just a question of a security tools alone, rather, he believes much higher levels of encryption are needed – particularly in a world where quantum computers and their security-cracking potential are only a few years away from commercialization. “Encryption becomes key – only four percent of the world is encrypted. How much of that data residing in a blockchain is encrypted?  To encrypt at 128-bit or 256-bit means it would take something like four million years to decrypt the remaining 96 percent,” he says.

In addition, the right processes and people need to be in place. Reddy likens this to the move towards the European Unions’ General Data Protection Regulation (GDPR) and the drive to protect information. “In a blockchain context, how do you make sure that you don’t expose information about a citizen of Italy or the United Kingdom when you transfer information?”

Scaling For Blockchain

That’s the concept, but what about technology? When it comes to actually running your blockchain implementation, what technical changes will you need to make?

The good news is you shouldn’t need to overhaul your underlying compute – servers that power the distributed ledgers. “They are not terribly CPU-intensive but they are latency sensitive,” Behlendorf told us of blockchain transactions. As a result, blockchain has also brought mainframes squarely into this world of distributed computing.

That said, be aware of legacy. “When I talk to customers from large financial institutions,” says Reddy, “one of the things they talk about is existing environment complexity. How do they manage systems they may have acquired, for example? Before you implement blockchain, these systems need to be simplified, it won’t scale otherwise. So you have to eliminate that complexity and make it more scalable. It’s the biggest challenge for the implementation of blockchain.”

“As customers go from pilot to production, there are three main challenges,” he adds. “First of all, is how to detect and prevent a smart contract deployment from going rogue.” In other words: making sure the project scales and ensuring that what worked in pilot works in production – that a transaction won’t go wrong once the system encounters real-life factors such as more users and real-time updates. “The second challenge is how to optimise the performance of blockchain transactions. And third, we have to examine the membership, governance, auditability and compliance of blockchain applications and networks.”

Those are the high-level considerations, but what of the first steps? The first stage in rolling out blockchain is to look at your databases – take all the data and create a blockchain database. “Take IBM as an example, they’re running a lot of data in DB2 on a mainframe. Blockchain transactions can work with existing business data on DB2. So, that means 70 percent to 80 percent of corporate data that’s running on mainframes can now be deployed pretty easily within blockchain,” Reddy says.

Network Capacity – Now And Beyond

Having tackled the database component, you must next look at your networking infrastructure: thanks to the requirements of latency demands, this needs to be robust. “Blockchain is a technology that’s based on polling, once you have made a transaction and agreed it, it goes on to the next node. So for n nodes, you have n squared amount of network traffic, which means that if you want to pump a thousand transactions a second through this, then you’re talking about speed of light issues,” says Behlendorf.

“Even if the servers are being separately managed by different companies, they’d need to be in close proximity to each other. Even if they’re in the cloud, on AWS, they’d need to be in the same zone so they’re operating at wire speed with each other.”

As blockchain becomes more widely deployed, be prepared to upgrade your network infrastructure. Your networks will have to become faster and more robust. “We’re not ready for transactions of tens of thousands yet, but for applications of tens and hundreds, the technology is there today,” Behlendorf says.

That is not the only aspect of delivery. DevOps has become a cultural force that’s shaping the way software and services are built and delivered. Naturally, you’ll want your blockchain system to feed into your continuous delivery and integration pipelines. How does DevOps fit in? At present that’s not clear, says Behlendorf. “It’s a bit early to say what will happen here,” admits the Hyperledger chief. “At one level there’s no reason to treat this kind of software differently than any other kind of enterprise component. But major upgrades will need to be coordinated across the network, so that will require coordination with other companies in your network.”

Whether mainframes or midrange systems, Hyperledger or Ethereum, blockchain is on its way. From the perspective of the technology component pieces you’ll use to build blockchain you shouldn’t encounter anything new or too surprising. Indeed, some familiar technology brands are extending into blockchain. For example, CA – a specialist in IT management – is making its own products for enterprise blockchain implementations. It’s looking at extending its automation systems to manage, operate, integrate, monitor, transact and secure blockchain applications and networks.

Designers and builders will, however, need to embrace concepts possibly outside their usual field and more typically associated with the world of hyperscale computing – but these concepts are surmountable.

The ethos of blockchain is to think big, think security and plan for resilience. This ethos already runs business computing. With that in mind, rolling out blockchain shouldn’t present too radical a shift for IT pros.