Technology considerations for choosing a blockchain framework

When organizations consider the technology implications of blockchain, they should start with the premise that it is not just another application. It's a production network that involves risks and costs to ensure correct upkeep and maintenance.

Here are some important things to ponder when evaluating blockchain's technological impact.

Identity management

Identity management is a complicated, involved topic, especially in regulated industries where identities must be managed and have significant business consequences, such as around activities like know your customer (KYC), anti-money laundering (AML), and other reporting and analytics functions. This section describes and discerns between the identity of enterprise participants and the identity of the end users that are the customer base of the participants on the network. By identifying the enterprise or entities that join the network, we are using identity as a permissioning mechanism to identity an enterprise and relying on enterprise to manage end user identity as a client service mandate:

• Permissioning is the concept of certification and key management; these enable an entity to be permissioned and identified while transactions are completed. The use case, industry, and business model can define permissioned, that is, the certificate and key management, be it decentralized or distributed or centralized by a consortium network operator.
• End use identity, which is maintained by a participating entity in the blockchain network, is the mapping of the LDAP/user registry to the certificates or keys for the sake of tracing (know your customer, as well as know your customer's customer).

Other identity management considerations include:

• An LDAP or existing user registry won't go away and has to be considered as a design point. This is because there has typically been significant investment and security policies in place for mature authentication and authorization systems.
• Trust systems are at the heart of blockchain technology and must pave the way for trust with identity insertion (for use cases that require transactional traceability).
• Identity is necessary both on the blockchain and for the blockchain. This implies we not only need to identify the direct participants on the network, but also indirect participants who process transactions as the client base of the direct participants.
• Identity acquisition, vetting, and lifecycle need to be accounted for. Identity acquisition is a responsibility of the onboarding entity, which is either a consortium or an operating entity of the network for direct participants and the participants that manage the relationship with indirect participants.
• Identity management should align with trust systems based on use cases. The identity is very much linked to the trust system of blockchain, including consensus voting and also digital signatures for transaction endorsement and processing.

Scalability

Scalability is both a business and a technology consideration, given the way downstream transaction systems can affect critical business systems. Technology choices for scalability—for example, database choices for the shared ledger, adjacent system integration, encryption, and consensus—bring about a system design that can accommodate the predictable costs of growth in network membership or transactions.

Enterprise security

There are four layers of enterprise security to think about:

• The physical IT infrastructure layer, which includes use case-specific issues like Evaluation Assurance Level 5 (EAL5), network, and infrastructure isolation requirements.
• The blockchain middleware layer, which includes requirements for crypto modules, encryption levels, encryption on data storage, transfer and data at rest, and the visibility of data between participants in the network.
• The blockchain consensus (trust system layer), which is central to blockchain and necessary to guarantee basic data store properties. If there are more players in the network, they have to bring capital equity to scale. This is about building a shared data store with enterprise data qualities at a lower barrier to entry. Consensus, even minimal consensus, is necessary to ensure this on the architecture in place. There's now a divide between cryptocurrency-based trust systems and non-cryptocurrency-based trust systems. The former model, such as PoW/PoS, isn't sustainable for enterprise use cases aspiring to create permissioned blockchains.
• The application security that uses blockchain.

Let's explore development tooling next.

Development tooling

Considerations for development tooling include an integrated development environment, business modeling, and model-driven development.

Crypto-economic models

A crypto-economic model refers to a decentralized system that uses public-key cryptography for authentication and economic incentives to guarantee that it continues without going back in time or incurring other alterations. To fully grasp the idea of blockchain and the benefits of cryptography in computer science, we must first understand the idea of decentralized consensus since it is a key tenet of the crypto-based computing revolution.

Decentralization with systemic governance

The old paradigm was centralized consensus, where one central database would rule transaction validity. A decentralized scheme breaks with this, transferring authority and trust to a decentralized network and enabling its nodes to continuously and sequentially record transactions on a public block, creating a unique chain—thus the term blockchain. Cryptography (by way of hash codes) secures the authentication of the transaction source, removing the need for a central intermediary. By combining cryptography and blockchain, the system ensures no duplicate recording of the same transaction.

Blockchain system design should preserve the idea of decentralized digital transaction processing, adapting it into a permissioned network, while centralizing some aspect of regulatory compliance and maintenance activity as needed for an enterprise context.

Enterprise support

Having enterprise support for blockchain is important for the same reasons as the reconsideration of estimation effort. Remember that blockchain should not be thought of as just another application. It's a production network that involves risks and costs for upkeep and maintenance, and it won't be able to simply use existing applications for development, infrastructure, and services.

Use case-driven pluggability choices

To make sure your blockchain solution can allow for use case-driven pluggability choices, consider the following issues.

Shared ledger technology

The use cases, design imperatives, and problem you're trying to address through blockchain will all help determine the choice of shared ledger and database technologies.

Consensus

Consensus guides the trust system and drives technology investment in blockchain application infrastructure—and therefore is at the heart of blockchain. Also, there isn't one consensus type that fits all use cases. Use cases define the interaction between participants and suggest the most appropriate trust system through consensus models.

Consensus is a way to validate the order of network requests or transactions (deploy and invoke) on a blockchain network. Ordering network transactions correctly is critical because many have a dependency on one or more prior transactions (account debits often have a dependency on prior credits, for example).

In a blockchain network, no single authority 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, consequently, ensures that a quorum of nodes agree on the order in which transactions are appended to the shared ledger. Consensus, by resolving discrepancies in the proposed transaction order, helps guarantee that all network nodes are operating on an identical blockchain. In other words, it guarantees both the integrity and consistency of transactions in a blockchain network.

Consensus algorithms are grouped into three classifications:

• No-master: PoW
• Multi-master: BFT or Practical Byzantine fault-tolerance (PBFT)
• Single-master: HA manager/Raft

Crypto algorithms and encryption technology

Choosing a blockchain system design may be guided by crypto library and encryption technology as well. An organization's use case requirements will dictate this choice and drive technology investments in blockchain application infrastructure. Alternatives to consider include:

• 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)

As previously stated, use cases will define the interaction between participants and will suggest the most appropriate trust system using consensus models.