In any enterprise, the driving principles are the business blueprint, the technology blueprint, and integration in the enterprise. In this post, I’ll walk through the essential considerations for choosing a blockchain framework according to these principles. And at the end, I’ll give you a handy worksheet to help you size your adoption effort based on these considerations.
Blockchain’s promise is to create a business network of value that is based on trust. And in order to reinvent a business based on a trust system, it’s important to understand how different blockchain frameworks address network interaction patterns, inefficiencies, and vulnerabilities.
For technology to align with business imperatives, you need to make the right technology and architecture choices to fulfill your needs, such as TPS (transactions per second), enterprise integration, external system integration, and regulatory and compliance requirements. All of these decisions are the technical due diligence needed to budget properly for an enterprise blockchain project and to mitigate risks.
Enterprise integration, especially with an adjacent system, is an important consideration and cost point. It’s a business consideration as well as a technology consideration, because downstream transaction systems affect critical business systems. In my evaluations, adjacent system integration has a significant cost impact on blockchain projects, and if not focused on early in the planning stages, it can impede enterprise adoption.
Business considerations for choosing a blockchain framework
- Open platform and open governance:
The choice of technology standards paves the way for enterprise adoption, compliance, governance, and the overall cost of the solution.
- Economic viability of the solution:
The focus is on cost alignment to business models, charge backs, compute equity, and account management, which get complicated by the advent of crypto-economics due to game theory constraints and accounting of such. This flows into ROI.
- Longevity of the solution:
As we aspire to build a trusted network, we need to ensure that the cost and operation are sustainable so the network can grow and scale to accommodate additional participants and resulting transactions.
- Regulatory compliance:
This includes events like industry-specific reporting, analysis, and costs of compliance –- in terms of business workflow and tasks, both automated and human-centric. These tasks are tightly linked with transaction processing in a business network.
- Coexistence with adjacent systems:
This refers to the impact of the blockchain network on the enterprise and on the participants of the business network working adjacent to the existing system, which may have overlapping and complementary functions.
- Predictable costs of business growth:
Business growth relies on predictable metrics. Historically, industry has focused on transaction per second, but the measurement of transaction per second differs from system to system based on system design, compute costs, and business processes.
- Access to skills and talent:
Access to skills and talent affects costs and also the maintenance and longevity of the solution with respect to industry and technology innovation.
- Financial viability of technology vendors:
This is an important consideration when it comes to long-term support and solution longevity. Vendor/business partner selection should be based on their long-term vision and the sustainability of their business model.
- Global footprint and support:
Blockchain applications and solutions are about business networks with global footprints, and the associated skills and support to ease the expansion of the business network with the least disruptive adoption path.
- Reliance on technology and industry-specific standards:
Standards play an important role not only in standardizing a common technology stack and deployment but also in setting a communication platform between industry experts and technologists to solve important industry problems and communicate effectively. Standards also lead to low-cost technology that can be rapidly consumed with widely available skills.
Blockchain vendors offer different specializations, including:
- Variant trust systems: Consensus, Mining, proof of Work, etc.
- Lock in to a single trust system
- Purpose-built infrastructure components for a specialized use case
- Design that is field-tested via proof-of-concepts
The risk is a fragmented blockchain model for the enterprise.
Conversely, the open-standards based approach, commercialized by IBM, is different in these ways:
- Open design
- Flexibility with a pluggable and modular trust system
- Open for specialized blockchains, such as Ripple
- Trust intermediary, which is a trust-system provisioning layer
- Enterprise blockchain concept
- Separate business domain with technology that supports it
Technology considerations for choosing a blockchain framework
Start with the premise that this is NOT ANOTHER APPLICATION you’re choosing. This is a production NETWORK with risks and costs to ensure upkeep and maintenance that cannot use existing applications for development, infrastructure, and common services.
1. Identity management
This is an involved and complex topic, especially in regulated industries where identities NOT ONLY need to be managed but also have business consequences around activities such as Know Your Customer (KYC), Anti-Money Laundering (AML), and other reporting and analytics functions.
- Permissioning is the notion of eCerts (member enrollment certificates) and tCerts (transaction certificates for each member), which allow for an entity to be permissioned and be identified as transactions are complete.
- End use identity is the mapping of the LDAP/User registry to the tCerts or transaction ID for the sake of tracing (Know Your Customer, as well as Know Your Customer’s Customer), but this mapping is maintained by the participating entity in the blockchain network.
Other identity management considerations include:
- LDAP or existing user registry will not go away and must be considered as a design point, since Authentication and Authorization systems are mature with significant investment as well as enterprise security policies.
- Blockchain trust systems are the heart of the technology and need to provide an avenue to induce trust with identity insertion (for the use cases that require the transactional traceability).
- Identity on blockchain
- Identity for blockchain
- Identity acquisition, vetting, and lifecycle
- Alignment with trust systems based on use cases
Scalability is both a business consideration and a technology consideration, due to downstream transaction systems affecting critical business systems. Technology choices for scalability, such as database choices for the shared ledger, adjacent system integration, encryption, and consensus, lead to system design that can accommodate the predictable costs of the growth in network membership and/or the growth in transactions.
3. Enterprise security
Enterprise security includes three layers to consider:
- The physical IT infrastructure layer includes use case-specific considerations such as the requirements of EAL5, network, infrastructure isolation.
- The blockchain middleware layer includes considerations around crypto modules, the level of encryption, encryption on data storage, transfer and data at rest, and visibility of data between network participants.
- The blockchain consensus (trust system layer) is the heart of blockchain technology.Consensus in the blockchain is required to guarantee very basic “data store” properties. When more players are in the network, they must bring capital equity to scale. This is about building a “shared data store” that has enterprise data qualities from the internal, walled-off enterprise, at a lower barrier to entry. Consensus, even minimal consensus, is required to guarantee this on the architecture in place.A divide between cryptocurrency-based trust systems and non-cryptocurrency-based trust systems has emerged. The model based on cryptocurrency-based trust systems, such as POW/PoS, is unsustainable for enterprise use cases that aspire to create permissioned blockchains.
4. Development tooling
Development tooling considerations include:
- Integrated Development Environment
- Business modeling
- Model-driven development
5. Crypto-economic models
This term roughly means a decentralized system that uses public key cryptography for authentication and economic incentives to ensure that it keeps going and doesn’t go back in time or incur any other alterations. To fully understand the blockchain concept and the benefits of cryptography in computer science, we need to first understand the concept of “decentralized consensus,” a key tenet of the crypto-based computing revolution.
6. Tenets of decentralization with systemic governance
Decentralized consensus breaks the old paradigm of centralized consensus, in other words, when one central database used to rule transaction validity. A decentralized scheme transfers authority and trust to a decentralized network and enables its nodes to continuously and sequentially record their transactions on a public “block,” creating a unique “chain” — the blockchain. Cryptography (via hash codes) is used to secure the authentication of the transaction source and removes the need for a central intermediary. The combination of cryptography and blockchain technology together ensures there is never a duplicate recording of the same transaction.
Blockchain system design should embody this concept to be adapted and preserved into a permissioned network while centralizing some aspect of regulatory compliance and maintenance activity and while preserving the decentralized digital transaction processing.
7. Robust and secure blockchain infrastructure
Considerations for a robust and secure blockchain infrastructure include:
- Global presence
- Industry acceptable certification
8. Enterprise support
Enterprise support is an important component for the same reasons as the reconsideration of estimation effort. Remember the fundamental premise that this is NOT ANOTHER APPLICATION you’re choosing. This is a production NETWORK with risks and costs to ensure upkeep and maintenance that cannot use existing applications for development, infrastructure, and common services.
9. Use case-driven pluggability choices
Considerations for use case-driven pluggability choices include:
- Shared ledger technology leads to a choice of shared ledger and database technologies driven by the use cases and design imperatives of the business network and problem domain being addressed.
Consensus is heart of blockchain technology as it not only dictates the trust system but also drives the technology investment in blockchain application infrastructure. Also, no one consensus types fits all use cases. Use cases define the interaction between participants and will suggest a most appropriate trust system via consensus models.
Consensus is a method for validating the order of network requests, or transactions (deploy and invoke), on a blockchain network. The correct ordering of transactions is critical, because many types of network transactions have a dependency on one or more prior transactions (account debits often have a dependency on prior credits, for example).
On a blockchain network, there is no single authority that determines the transaction order; instead, each blockchain node (or peer) has an equal say in establishing the order, by implementing the network consensus protocol. Consensus, therefore, ensures that a quorum of nodes agree on the order in which transactions are appended to the shared ledger. By resolving any discrepancies in the proposed transaction order, consensus guarantees that all network nodes are operating on an identical blockchain. In other words, consensus guarantees the integrity and consistency of blockchain network transactions.
Broadly, all consensus algorithms are grouped into one of the three classifications:
- No-Master – PoW
- Multi-Master – PBFT/BFT
- Single-Master – HA manager/RAFT
- Crypto algorithms and encryption technology:The choices in blockchain system design include the choice of crypto library and encryption technology. Use case requirements will dictate this choice and drive the technology investment in blockchain application infrastructure.
- Asymmetric: RSA (1024-8192), DSA (1024-3072), Diffie-Hellman, KCDSA, Elliptic Curve Cryptography (ECDSA, ECDH, ECIES) with named, user-defined, and Brainpool curves
- Symmetric: AES, RC2, RC4, RC5, CAST, DES, Triple DES, ARIA, SEED
- Hash/Message Digest/HMAC: SHA-1, SHA-2 (224-512), SSL3-MD5-MAC, SSL3-SHA-1-MAC, SM3
- Random Number Generation: FIPS 140-2 approved DRBG (SP 800-90 CTR mode)
- Use case-driven pluggable choices:Use cases define the interaction between participants and will suggest a most appropriate trust system via consensus models.
1. Consensus, ACID property, and CAP
The consensus model will never go to 0, and here is why. When NoSQL became the norm, various NoSQL systems solved their problems by understanding this CAP theorem, and the RDBMS enterprise community held steadfast to their ACID properties. Blockchain could very well provide the primitives to break CAP and maintain ACID. Here are some considerations:
- C – Consistency
Consensus guarantees that there is only one truth of what happened and the order in which it happened.
- A – Availability
The fact that all calls to the blockchain are asynchronous allows the “invoking” application to make progress while ensuring consensus and durability (chaining also guarantees this).
- P – Network partition
Consensus again prevents split brain with conflicts when things get back together after a network partition.
- A – Atomicity
The chaincode programming model is an all-or-nothing behavior, which allows you to group activity together. It either all happens, or it doesn’t.
- C – Consistency
I think the new world of NoSQL fudges this one. I believe that this means the same as the “C” in CAP.
- I – Isolation
This means that two transactions are serialized, which is exactly what the block construction and chaining do.
- D – Durability
The chaining and replication all over the network make sure that if one or more nodes go down, you don’t lose the data. This is why everyone wants to bring a node. It’s also why all those nodes should not be not co-located.
2. Attestation – SSCs are signed and encrypted
The software, operating system, hypervisors, and docker container images in secure service containers (SSCs) cannot be modified. Certificates can be included within the SSC so that it can probe itself to be genuine to a remote a party. For example, including an SSL certificate when building SSCs helps us be sure that we are speaking with a genuine instance since the SSL certificate always stays protected (encrypted) within the SSC.
3. Use of HSMs
According to Wikipedia, a hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server.
Administering a high-security device like an HSM is difficult to do with adequate security and controls. In fact, standards today mandate certain methods and levels of security for the HSM administrative (and key management) systems.
Sample of work estimation
Remember the fundamental premise that this is NOT ANOTHER APPLICATION you’re choosing. This is a production NETWORK with risks and costs to ensure upkeep and maintenance that cannot use existing applications for development, infrastructure, and common services.
Front end components: Java, Tomcat
Web front end
Mobile front end
Middleware that integrates with existing enterprise information systems
Database design and admin skills
API management design:
API design and component design
API management design
Enterprise API integration and management
Key management design
Key management implementation and admin
Identity management design and development:
ID management design
ID federation strategy
ID management – integration and implementation
ID audit and operations
Content Management System (CMS) design and development:
CMS design and strategy
CMS implementation and development
CMS installation/management and administration
CMS audit and operations
Blockchain framework migration
Current and future design
Chaincode development and implementation
Chaincode design and development
Chaincode test and deployment
System architecture and design
System (and component) provisioning
DevOps strategy and design
HSBN (V1) design and provisioning
Cloud services (Bluemix and other components) – provisioning and admin
Operation and monitoring:
Operation Center – design and admin
Change management strategy
Monitoring – Infrastructure and application components
Network operations – HSBN and Cloud components
Performance and SLA management:
Performance design and strategy
SLA design and Strategy
Performance management and tuning
Network monitoring and tuning
Overall security design
Network security design and implementation
Blockchain infrastructure security design and implementation
Blockchain middleware security design and implementation
Front end application security design and implementation
Security testing – design and implementation
Security auditing – key metrics and test (application and penetration testing, etc.)
Business analysis and design
Project documentation (business and technology requirements and decisions)
- Start building with IBM Blockchain on Bluemix. Your Bluemix trial is free for 30 days.
- IBM Blockchain 101: Quick-start guide for developers
Read more by Nitin Gaur
- 7 principles for designing a blockchain network to power and sustain your business
- Blockchain for enterprise? Not so fast!
- Blockchain for Enterprise – Focus on KYC, AML, and Regulatory Compliance – Are we Calling it RegTech?
- Path to blockchain enterprise adoption: A prescriptive approach
- Secure Blockchain Considerations for the Enterprise: Infrastructure, Blockchain Middleware, and Consensus