Mark Rakhmilevich is Senior Director of Blockchain Product Management at Oracle. He’s working on Oracle Blockchain Cloud Service and guides enterprises, ISVs, and SIs in building blockchain applications and integrating enterprise systems with this platform.
The following article is an exclusive contribution to CoinDesk’s 2017 in Review.
Talk to enterprise blockchain enthusiasts and they will tell you about the potential use cases in their industries and the proofs-of-concept they have run to prove blockchain value in the enterprise.
Ask them about production deployments… and they demur, pointing out implementation challenges and production-readiness gaps.
Will this change in 2018 and will we see a significant shift from experimentation to production deployments of enterprise blockchains?
In numerous customer conversations during 2017, the challenges to moving even successful use cases from successful PoCs to pilots and production boil down to five areas of enterprise-grade requirements: performance at scale, operational resilience, security and confidentiality, supportability and management, and enterprise integration.
Enterprises experimenting with blockchain use cases are recognizing the need to address these challenges, and in 2017, some vendors, (including my company, Oracle), announced blockchain platforms focused on these requirements.
With all of the enhancements coming in enterprise blockchain platforms, 2018 will be the year enterprise blockchain goes live and businesses can move from experimenting to production.
Performance at scale
Many enterprise systems handle business transactions at a rate of hundreds or thousands per second. For example, a large Asian telecom handles more than 100,000 billing and mobile payments transactions per second (tps), and a major credit card processor was running over 13,000 tps at peak a number of years ago. Naturally enterprises are concerned about creating large blockchain networks with hundreds or thousands of members, handling growing transaction volumes, and providing sub-second transaction latency.
While today’s blockchain applications may not require these throughput levels, most real-world blockchains do not even approach 100 tps – bitcoin averages 7 tps and ethereum is about twice that, while the transaction wait times (latency) can run into minutes or hours. Enterprise blockchains not only need much higher throughput, but also transaction latency of less than a second for many businesses use cases.
Reaching beyond these limitations requires an architectural approach that uses separation of concerns (different types of work are done in separate, independently scalable servers or containers), leverages asynchronous flows, exploits parallelization, uses faster consensus protocols, and runs on optimized execution environments.
Some of these architectural principles are already present in Hyperledger Fabric, a Linux Foundation project that Oracle joined in 2017, but more can be done leveraging the experience from those same systems delivering hundreds and thousands of tps at many enterprises to reach the transaction throughput and latency enterprises need.
In addition, scaling a permissioned blockchain, where all members are linked to legal entities, to dozens or hundreds of participants also requires a robust and efficient on-boarding process. Enterprise PoCs rarely include more than a dozen participants on a single blockchain.
Some onboarding processes make assumptions and take short cuts that do not withstand real-world scrutiny, so effective tools will be required to handle adding organizations onto the business network in production, with all the necessary verification and approvals processes, and in a streamlined way that can leverage established identity management services.
Joining members must be able to deploy their validating nodes using multiple, highly available resource pools across distributed cloud or on-site data centers in an open, hybrid environment.
Resilience
Enterprise systems are built to avoid downtime with highly available services and to recover rapidly when (not if) some components fail. Avoiding small issues leading to major outages and quick recovery from failure are key to ensuring high availability in any business-critical system. Software and hardware is subject to failures – and the first design principle of resilient systems is to assume failures will happen and to be prepared to keep the overall system running in these situations.
Traditional enterprise software from Oracle and others use replication of services and redundancy to ensure that the system survives an outage of any single and even multiple components. Similarly, deploying redundant peer nodes per member organization, clustered ordering service, and replicating other blockchain network components is an important foundation for resilient blockchain infrastructure, which is enabled with Hyperledger Fabric’s architecture.
Beyond redundancy, autonomous monitoring and recoverability of failed components, as well as continuous embedded backup of configuration information and ledger data can ensure rapid autonomous resolution of most glitches without manual intervention.
Minimizing intervention is an important aspect, as research shows that around 70 percent of outages are due to human error introduced while correcting other issues or adjusting configuration.
Security and confidentiality
Security assessments of blockchain deployments look at how blockchain can restrict transactions and ledger access to authorized participants, ensure encryption of data in-transit and at-rest, and verify that network messages are tamper-proof and their digital signatures are valid.
Enterprise blockchains start with a permissioned network model, meaning that all members are known legal entities and must be enrolled though membership services, which issue enrollment certificates. These cryptographically signed certificates securely link member identity and authorization attributes with the cryptographic key that enables authentication of their digitally signed messages.
Digital signatures applied to all network messages enable all nodes and clients to verify the sender and validate message integrity. This is coupled with transport security to authenticate the communications end points and encrypt the message traffic.
Further, automatically applying encryption for the stored data completes the best practices for encrypting data in transit and at rest. When this foundation is used transparently and pervasively for all secure communications and stored ledger data, it’s a big step forward in maintaining the integrity and security of the blockchain network, preventing most hacking attacks.
When a blockchain certificate authority enrolls a new member organization and issues its digital certificates, the underlying process depends on properly authenticating the organization’s identity and access privileges. This requires strong identity management and key management capabilities.
Moreover, since even in secure environments credentials can be stolen via spearfishing or social engineering attacks, a certificate revocation mechanism must be available as an integral part of the solution to prevent the use of compromised certificates.
Further, securing ongoing access to blockchain REST APIs or operations interfaces from external client applications or admin users requires strong multi-layered access control – with logical, physical, and data security controls, coupled with adaptive or behavioral authentication – comparing users’ behavior to historical patterns and generating alerts for significant deviations.
In addition to external security, enterprise blockchain must have the ability to conduct confidential transactions, e.g., using channels in Hyperledger Fabric, which insulate peer nodes and maintain private ledgers that are only accessible to other peers on the same channel.
Additional important capabilities, such as fine-grained authorizations for enforcement of access control within a smart contract, private peer-to-peer interactions that limit visibility of transaction information from other peers and selective encryption of the sensitive data for restricted access by authorized peers, are necessary to further enhance data and transaction privacy.
Supportability
Once an organization builds a PoC and proves the value of applying blockchain to a particular use case, how does it put it into production to achieve the promised results?
Who’s going to assemble, harden, and support the blockchain network components, and all their supporting infrastructure? Who will provide troubleshooting, day-to-day administration and monitoring, and deal with patching or upgrades to new versions? With a production blockchain, operations and supportability become critical, including blockchain operations and dynamic configuration, ability to monitor service-level agreements, troubleshoot anomalies, and manage a patching/upgrade lifecycle with backward compatibility.
One answer is blockchain as a managed service (BaaS), which leverages a service provider’s ready-to-deploy infrastructure and operations capabilities to manage, monitor, patch, and maintain the infrastructure, while enterprises focus on the application-delivered value of using the blockchain.
The service provider would integrate and maintain the foundational technologies required to run the blockchain, monitor and troubleshoot the blockchain network, and provide an operations interface for the members to perform dynamic configuration, monitor SLAs, and manage policies as well as tools to manage smart contract lifecycle – deploy initial chaincode, upgrade to a new version, etc.
Integration
Many of the multi-party processes and business-to-business interactions that would benefit from using blockchain touch a number of enterprise systems of record (SORs.)
In the near term, blockchain will extend rather than replace many current enterprise systems of record (e.g., core banking, enterprise resource planning, supply chain management, human capital management.) But building these integrations one by one is very complex and costly. Business need pre-built onramps for enterprise systems and modern event and API-driven integration methods to invoke transactions, share data, and capture blockchain events and ledger updates into systems of record (SORs)
For example, a shipping transaction initiated in a supply chain management system can trigger a blockchain transaction to update the order information and related metadata stored in distributed ledger. In an outbound integration example, an account transfer associated with an invoice settlement in a blockchain system may emit an event to update an internal general ledger account.
Turning an isolated blockchain PoC into a fully fledged part of the enterprise IT depends on ability to simplify and accelerate such integrations. Application integration toolkits that address typical business processes and events is one promising approach.
This can be further extended with API-driven development that relies on managed API platform using REST APIs for invoking blockchain transactions and querying the distributed ledger. These can help to quickly deliver new applications that drive enterprise innovation and integrate existing back-end systems, such as General Ledgers, ERPs, SCM, and other systems that are key to information sharing and transactions with external organizations.
Conclusion
Last year saw a lot of blockchain experimentation in the form of PoCs and pilots in financial services, supply chain and a number of other industries as well as government operations (e.g., the U.S. General Services Administration’s FASt Lane process for IT Schedule 70 contracts).
For these to move toward production in 2018, the technology needs to mature in the key areas outlined above. But open source consortia like Hyperledger and enterprise software vendors like us at Oracle are stepping up to the challenge to deliver on these requirements.
Together we will help enterprises fully adopt blockchain technology as a part of their business-critical IT systems.
Sky scrapers image via Shutterstock