Blockchain solution architecture deliverable

© 2017 IBM Corporation
Blockchain Solution
Architecture
Sprint 1
1

Academy of Technology Initiative
› Executive Champion
– Nitin Gaur, Director Blockchain Labs, Industry Platforms
› Study Leaders
– Annap Derebail, Executive Architect, FSS Integrated Accounts
– David Smits, Senior Architect, Global Business Services CAMS/CSI&A
› Key Contributors
– Sridhar Narayanan, Executive Architect, FSS, IBM Global Markets
– Maurizio Luinetti, Executive Architect, Software Client Architect
› DE Advisor
– Bertrand Portier, Distinguished Engineer, FSS Blockchain
› ALT Sponsor
– Wouter Denayer, Technical Lead, Global Markets
2

Initiative Overview
Purpose The purpose of this initiative is to guide solution architects to design business
network solutions using Hyperledger Fabric architecture
Output Solution design artifacts are represented using two models
• Architecture Overview Diagrams
• Architectural Decisions
Viewpoint Artifacts are developed from the viewpoint of a solution architect that is starting
the design of a new blockchain business network solution
Intended Use • By Solution architects (IBM/Partners/Clients) as a practical solution design
guide
• As an extension to IBM Cloud Architecture content
Audience Solution Architects; Blockchain Reference Architecture Board; Standards Bodies
(e.g.. ISO)

Assumptions
› The contents of this document are applicable for a Hyperledger Fabric
v1.0 architecture. Some considerations are provided for designing the
solution using tooling from the Hyperledger Composer project.
› The IBM Blockchain Platform is considered to be the preferred
deployment model, although we provide considerations that have to be
taken into account when thinking about hybrid deployments.
4

Scope Limitations
› The following are considered out of scope for this initiative
– Other blockchain platforms such as Ethereum, R3 Corda, etc
– Specific cloud platforms such as Amazon Web Services or Azure. Architectural
decisions refer to generic cloud infrastructure platforms.
– Interoperability of blockchain solutions that are deployed on multiple infrastructure
platforms (suggested as Next Steps)
– Inter-chain solutions e.g.. where blockchain transactions span multiple chains.
(suggested as Next Steps)
5

The value of using a platform
› Solution architects often get asked why use a platform such as IBM Blockchain Platform to implement a
blockchain business network.
› While Hyperledger Fabric is dockerized and available for download to build & deploy your own network, the
following table presents key benefits of the IBM Blockchain Platform from an architectural perspective.
6
Arch. Considerations Value that IBM Blockchain Platform delivers
Security All network peers run on a hardened security stack with no privileged access, which blocks malware introduction. In
a heterogeneous environment, the security of the network can be compromised by the most insecure node and is
difficult to control
Performance Provides better control of business network performance. In a heterogeneous deployment, performance is limited
by the slowest network node and is difficult to control
Resilience Platform provides always-on, high availability with in-place software and blockchain network updates. In a
heterogeneous deployment, management of software and smart contract updates can present huge challenges
Network Governance Platform provides activation tools for new networks, members, smart contracts and transaction channels, making it
far simpler to govern business networks. Further, it is easier to build efficient governance tools (e.g.. multi-party
workflow tool with notifications, secure signature collection, policy voting) for a platform than for a heterogeneous
environment
Network Monitoring With the platform, monitoring of the blockchain network activity is easier with readily available tooling, which is
important from audit and regulatory compliance perspectives.

Hyperledger Fabric Pluggable Components
› Hyperledger Fabric implements a modular architecture to provide functional choice to business network
designers. The following tables lists each key aspect of this pluggable architecture, which provides decision
points for an architect when designing a solution.
7
Arch.Considerations Module function and choices
Identity All network participants have known identities. Public Key Infrastructure is used to generate cryptographic
certificates which are tied to organizations, network components, and end users or client applications. Fabric has a
Membership Service Provider (MSP), an abstract interface that provides credentials to clients and peers to
participate in a Hyperledger Fabric network. Clients use these credentials to authenticate their transactions. Peers
use these credentials to authenticate transaction processing results (endorsements). The MSP interface allows for
alternate implementations to be plugged in without modifying the transaction processing components of the system
Consensus Consensus is the verification of the correctness of a set of transactions comprising a block, and is achieved when the
order and results of a block’s transactions have met the explicit policy criteria checks. An ordering service then
packages transactions into blocks to be delivered to peers for committing to the chain. Fabric provides flexibility by:
• Allowing architects to define endorsement policies that dictate which participants must endorse transactions.
System chaincodes ensure that these policies are enforced and upheld.
• For the ordering service, different algorithms can be employed based on a pluggable interface. For Fabric 1.0
deployments today, options available are Kafka/Zookeeper. Other algorithms such as Simplified Byzantine Fault
Tolerance (SBFT), BFT Smart, Honey Badger of BFT are currently being developed as Fabric 1.0 plugins. This
allows customization of the ordering based considerations that include the application use case and fault
tolerance to network node crashes.
Crypto Algorithms The built in crypto library may be replaced with other suitable algorithms/implementations to address regional
regulations or different technical requirements

Logical Architecture – High Level Overview
8
Org 1
Client App
REST
API
Node JS App
(REST API)
Org 1
Org 2
Org 3
Orderer
Nodes Org N
Endorser & Committer
Peer Nodes
Events
Org 1
Enterprise
Systems
Websphere App
Server, TIBCO, MQ
etc
Org 1 Users
and Enterprise
Systems
Org 2
Client App
REST
API
Node JS App
(REST API)
Events
Org 2
Enterprise
Systems
Websphere App
Server, TIBCO, MQ,
etc
Org 2 Users
and Enterprise
Systems
Org 3
Client App
REST
API
Node JS App
(REST API)
Events
Org 3
Enterprise
Systems
Websphere App
Server, TIBCO, MQ,
etc
Org 3 Users
and Enterprise
Systems
Org N
Client App
REST
API
Node JS App
(REST API)
Events
Org N
Enterprise
Systems
Websphere App
Server, TIBCO, MQ,
etc
FABRIC – LEDGER TIERINTEGRATION TIERACCESS CHANNELS &
ENTERPRISE SYSTEMS
…
INTEGRATION TIER
Off-chain Store (Legal
Docs, etc)
ACCESS CHANNELS &
ENTERPRISE SYSTEMS

Logical Architecture – Detailed View
9
ORDERER 1
ORDERER
NODES
REST
Engine
Fabric
SDK
Composer
SDK
DATA
STORE
OBJECT
STORE
FILE
STORE
ENTERPRISE SYSTEMS
OFF-CHAIN
DATA
STORE
IDENTITY &
ACCESS
MGMT
CERT & KEY
MGMT
LOG
MANAGEMENT
SECURITY
MONITORING
STORAGE
MGMT
ENTERPRISE UTILITY SERVICES
USER
APPLICATIONS
API Gateway
(External)
LEDGER WORLD STATE
DB
ORG 1 CA
(Fabric CA)
ORDERER N
…
ORDERER 2
PEER
REST
Engine
Fabric
SDK
Composer
SDK
REST
Engine
Fabric
SDK
Composer
SDK
API Gateway
(Internal)
Integration
Hub
ORG 1
API Gateway
(Internal)
Integration
Hub
API Gateway
(Internal)
Integration
Hub
ORG 1
ORG 2
ORG N
…
…
ORG 1
…
ENTERPRISE
APPLICATIONS
AND SERVICES
ENTERPRISE
DATA MGMT
Blockchain Relevant Data
ACTIONABLE
INSIGHT
USER
APPLICATIONS
API Gateway
(External)
ORG 2
ACTIONABLE
INSIGHT
USER
APPLICATIONS
API Gateway
(External)
ORG N
ACTIONABLE
INSIGHT
LEDGER WORLD STATE
DB
ORG 2 CA
(Fabric CA)
PEER
ORG 2
LEDGER WORLD STATE
DB
ORG N CA
(Fabric CA)
PEER
ORG N
…
Participant Organization (1 .. N)
MONITORING
SERIVCES
FABRIC–LEDGER
TIER
Endorse, Configure
etc.
Broadcast
Deliver
- CHANNEL
INTEGRATION
TIER
ACCESS
CHANNELS
SHARED
SERVICES

Logical Architecture - Components
Dimension Description
Fabric Tier The Fabric Tier consists of Blockchain network components, including the network peers and Certificate
Authority (CA) that are owned by members of a network and are operated either by members or by a 3rd
party in a SaaS model. Members might participate in multiple channels. It also consists of the ordering
service which is a shared/common network service responsible for ensuring total order of transactions in
the network and for delivering blocks to peers. Chain code execution takes place within secure containers
in this tier.
Integration Tier This tier provides integration capabilities, enabling integration of both the channels and blockchain
solutions with enterprise systems & services, data management components and shared services. The
integration tier could be made of several components such as a message broker hub, event hub, API
gateway, application connectors that provide enterprise connectivity, etc.
Shared Services This tier consists of data management components that store and manage blockchain solution relevant
data, such as documents, images, etc.
Utility Services This tier consists of services that address cross cutting concerns such as Identity and Access
Management, Certificate and Key Management, Log Management, Monitoring (Systems, Application,
Security etc.), Storage Management (SAN, Backup solutions etc.). Capabilities offered here will need to
integrated with Blockchain solutions (regardless of deployment model chosen).
Analytics and
Operational
Insights
Analytics delivers insights from data collected on the blockchain and can be done using different
implementations. We will cover alternatives and considerations later on in this document.
10

Deployment Architecture – Blockchain as a Service
11
ORDERER 1
ORDERER
NODES
REST
Engine
Fabric
SDK
Composer
SDK
DATA
STORE
OBJECT
STORE
FILE
STORE
ENTERPRISE SYSTEMS
OFF-CHAIN
DATA
STORE
IDENTITY &
ACCESS
MGMT
CERT & KEY
MGMT
LOG
MANAGEMENT
SECURITY
MONITORING
STORAGE
MGMT
USER
APPLICATIONS
API Gateway
(External)
LEDGER WORLD STATE
DB
ORG 1 CA
(Fabric CA)
ORDERER N
…
ORDERER 2
PEER
REST
Engine
Fabric
SDK
Composer
SDK
REST
Engine
Fabric
SDK
Composer
SDK
API Gateway
(Internal)
Integration
Hub
ORG 1
API Gateway
(Internal)
Integration
Hub
API Gateway
(Internal)
Integration
Hub
ORG 1 ORG 2 ORG N
…
…
ORG 1
…
ENTERPRISE
APPLICATIONS
AND SERVICES
ENTERPRISE
DATA MGMT
ACTIONABLE
INSIGHT
USER
APPLICATIONS
API Gateway
(External)
ORG 2
ACTIONABLE
INSIGHT
USER
APPLICATIONS
API Gateway
(External)
ORG N
ACTIONABLE
INSIGHT
LEDGER WORLD STATE
DB
ORG 2 CA
(Fabric CA)
PEER
ORG 2
LEDGER WORLD STATE
DB
ORG N CA
(Fabric CA)
PEER
ORG N
SecureServiceContainer
IBMBluemixContainer
Service
…
Bluemix Shared Services
LOG
MANAGEMENT
MONITORING
SERIVCES DEVOPS
IBM Blockchain Platform – Blockchain As a Service Delivered through IBM Bluemix Cloud Infrastructure (SoftLayer)
Participant Organization (1 .. N)
SECURITY
MONITORING
MONITORING
SERIVCES
FABRIC–LEDGER
TIER
INTEGRATION
TIER
ACCESS
CHANNELS
SHARED
SERVICES
IBM Blockchain
Platform

Deployment Architecture – Hybrid Deployment
12
ENTERPRISE SYSTEMS
IDENTITY &
ACCESS
MGMT
CERT & KEY
MGMT
LOG
MANAGEMENT
SECURITY
MONITORING
STORAGE
MGMT
ENTERPRISE
APPLICATIONS
AND SERVICES
ENTERPRISE
DATA MGMT
Participant Organization (1 ..
N)
MONITORING
SERIVCES
ORDERER 1
ORDERER
NODES
REST
Engine
Fabric
SDK
Composer
SDK
DATA
STORE
OBJECT
STORE
FILE
STORE
OFF-CHAIN
DATA
STORE
USER
APPLICATIONS
API Gateway
(External)
LEDGER WORLD STATE
DB
ORG 1 CA
(Fabric CA)
ORDERER N
…
ORDERER 2
PEER
REST
Engine
Fabric
SDK
Composer
SDK
REST
Engine
Fabric
SDK
Composer
SDK
API Gateway
(Internal)
Integration
Hub
ORG 1
API Gateway
(Internal)
Integration
Hub
API Gateway
(Internal)
Integration
Hub
ORG 1 ORG 2 ORG N
…
…
ORG 1
…
ACTIONABLE
INSIGHT
USER
APPLICATIONS
API Gateway
(External)
ORG 2
ACTIONABLE
INSIGHT
USER
APPLICATIONS
API Gateway
(External)
ACTIONABLE
INSIGHT
LEDGER WORLD STATE
DB
ORG 2 CA
(Fabric CA)
PEER
ORG 2
LEDGER WORLD STATE
DB
ORG N CA
(Fabric CA)
PEER
ORG N
SecureServiceContainerIBMBluemixContainerService
…
Bluemix Shared Services
LOG
MANAGEMENT
MONITORING
SERIVCES DEVOPS
IBM Blockchain Platform – Blockchain As a Service Delivered through
IBM Bluemix Cloud Infrastructure (SoftLayer)
SECURITY
MONITORING
FABRIC–LEDGERTIERINTEGRATIONTIERACCESSCHANNELS
Participant Organization N
SHAREDSERVICES
Hybrid deployment
Deployment Options
• Other Cloud Service
Provider (AWS, Azure,
etc)
• On-premise

Key Architectural Decisions
Subject Area Number Details
Business Network Design AD-NET-001 Direct and Indirect Network Participation
Security AD-SEC-001 Channel Design
Security AD-SEC-002 Secure Key Management and Key Operations
Identity AD-IDM-001 Certificate Authority (CA) design for membership management of multi-party solutions
Identity AD-IDM-002 Blockchain solution identity and access management
Data Storage AD-DATA-001 World State data store choice
Data Storage AD-DATA-002 On-chain vs Off-chain data
Data Storage AD-DATA-003 Secure off-chain Document store*
Data Storage AD-DATA-004 Personal identifiable information (PII) and EU GDPR
Data Storage AD-DATA-005 Data modeling*
Consensus AD-CONS-001 Design of Endorsement Policies
Performance AD-PERF-001 Performance*
13
(continued)

Key Architectural Decisions
Subject Area Number Details
Performance, Throughput AD-PERF-002 Block design – block sizes, batch sizes, etc*
Tooling AD-TOOL-001 Fabric Composer and Hyperledger Fabric
Integration AD-INTG-001 Enterprise Application Integration
Query AD-ANLY-001 Querying and Analytics*
Query AD-ANLY-002 Provenance Analytics*
Smart Contract AD-CODE-001 Smart contracts design for flexibility and governance
Smart Contract AD-CODE-002 Orchestration and Smart Contracts
Governance AD-GOVN-001 Secure On-boarding of members*
Governance AD-GOVN-002 Policy management for smart contracts and channels*
Deployment AD-DEPL-001 Deployment Models
Availability AD-AVL-001 High Availability*
Availability AD-AVM-002 Disaster Recovery*
14
* - To be covered in Sprint 2

Direct vs Indirect Participation
Subject Area Business Network Design
Architectural
Decision
Determination of the nature of participation: direct/indirect within a business network.
Issue or Prob
Stmnt
• Within a consortium based blockchain network, a member organization may choose to participate directly
or indirectly.
• Direct participation is where a member organization “owns” a peer node. Indirect participation is where a
member organization (usually a smaller org) uses services provided by a peer node via the access
channels. In this case, the peer node itself is “owned” by another organization.
• Example: Consider the scenario where we have an auto insurance subrogation network between insurers,
brokers and service providers. Smaller service providers such as auto repair shops may be not want to or
be able to participate directly due to cost of onboarding, ongoing operational and management complexity,
lack of IT maturity etc.
• The cost to participating in a consortium network is driven by a number of considerations including the
consortium business model, cost of infrastructure, platforms and services provided, whether the consortium
is operating as a non-profit or for-profit entity.
• A smaller size organization may find it prohibitive to be a direct participant in some consortium solutions.
• In most large consortium networks, the question of direct vs indirect participation arises and requires
addressing.
Assumptions
Motivation
15
AD-NET-001
(continued)

Alternatives 1. Direct Participation: The member organization is a direct participant in the network
• Advantages: The organization will be direct member of the consortium giving its stake and influence in the
overall governance and business model of the consortium. In addition, the organization will have a stake
in nature of solutions deployed and critical architecture decisions including how data privacy and
confidentiality concerns are addressed (e.g. channel design). The organization needs to host its own peers
and CA (either in Hybrid or SaaS deployment model).
• Trade offs: Key trade off is that member will bear both the initial onboarding and ongoing operational costs
of participating in the network. The organization is subject to the legal, operational and governance
frameworks of the consortium, e.g. SLA commitments, legal liabilities etc.
16
AD-NET-001
(continued)

Alternatives 2. Indirect Participation: Organization participates indirectly in the consortium network through a direct/master
organization. The master organization will be responsible for interfacing with the Blockchain network on behalf
of the indirect participants. In other words, the indirect participant will reuse the peers and CA hosted by
master organization.
• Advantages: Lowers the costs of participation in the network and reduces operational and management
complexity for the indirect participant. For instance, the master organization could be responsible for
onboarding, key & cert management etc. However, master organization and consortium will need to consider
any legal implications and potential liabilities that may arise (to master participant) due to actions of indirect
participant on the network
• Trade offs: The master organization could use the same set of peers and channels for all indirect members.
This could cause concern from data privacy perspective since data for the indirect participant will be on the
same channel with other indirect participants. On the other hand, if the master organization creates a
channel for each indirect participant, this could lead to significant operational complexity and costs for the
master organization. In addition, the need for isolating the UI, transactions and data between the indirect
members might dictate need to segregate indirect participants at user interface level, front end application level
or even create separate Uis
Justification N/A
Implications N/A
Derived Reqts N/A
Related Decisions *** To be filled in once we have numbering of architecture decisions
17
AD-NET-001
(continued)

Channel Design
Subject Area Security
Architectural Decision Ensuring privacy of transactions and data exchanged between transacting parties
Issue or Prob Stmt • In Hyperledger Fabric, channels provide privacy of transactions and data that are exchanged between a set of
parties that participate in the channel.
• Transactions within a channel are not visible/accessible to parties that are not a participant in the channel.
Ledgers exists within the scope of channel
• Example of channel usage:
• B3i is a global consortium of reinsurers, brokers and insurers, formed to initially collaborate on distributed
reinsurance contracts. Contracts are written bi-laterally or multi-laterally between participants and require privacy.
Participants also share common contract reference data across the whole consortium. Further, there is a desire
amongst the consortium members to execute all contract related processes, private and public – fully on the
chain. To address these needs, a three channel solution has been designed.
• Each organization will have a private ledger (channel) for storing their own contract elements & data.
• All organizations also participate in two shared ledgers (channels):
• A shared Master Data ledger contains common and agreed master data including public company
information and common contract clauses.
• A shared Communication ledger that is cryptographically secured and stores the communication
used to consent on the state of the private organization ledgers. Only counter-parties can see the
content and destination of the communication.
Assumptions
Motivation
18
AD-SEC-001
(continued)

Channel Design
Alternatives 1. Single Global Channel: All participants in the network are part of the same channel.
• Advantages: Suitable for scenarios, where within a consortium based network, there is need to share
common data such as reference data across all participants.. A global channel could be defined in which all
participants (including the consortium that might operate its own peer nodes) can participate. By default,
participants in channel have full visibility to data that is stored in the channel’s ledger. If confidentiality of
data is required, then such data could be encrypted. Easier to support Analytics and BI since data resides
on single channel
• Key Tradeoffs: Not suitable for scenarios where data privacy and data residency rules dictate that relevant
data cannot be shared across all participants. Use of encryption for data confidentiality introduces
additional overhead and management complexity due to management of keys and certs. In Hyperledger
Fabric 1.1, there will be support for Collections which will allow for data to be exchanged between a set of
participants within a channel without sacrificing data privacy.
19
AD-SEC-001
(continued)

Channel Design
Alternatives 2. Bilateral and Multi lateral channels: If privacy of transaction and underlying data is required between
specific subset of participants in network, create a distinct channel that only such subset of
participants in the network will join.
• Advantages: Provides flexibility to comply with data privacy and data residency rules required within a
solution. Further, if confidentiality of data is required, then such data could be encrypted.
• Key Trade offs: Creation of too many bilateral channels results in high level of operational and
management complexity. Use of encryption for data confidentiality introduces additional overhead
and management complexity due to management of keys and certs. Analytics and BI could be
challenging when a participant participates in multiple channels. Performance is one consideration that
must be paid attention to when choosing the channel design. There is a limit on the maximum number
of channels with Fabric running on dedicated hardware (100-150 channels, latest numbers available
from Performance Team). There is also a practical limit on the numbers of nodes that can participate
on a channel (10-20 nodes, latest numbers available from Performance team). Within a channel, the
transaction throughput rates can range from 150-200 transactions per second before there is
noticeable latency (time for all nodes in channel to commit transaction).
20
AD-SEC-001
(continued)

Channel Design
Alternatives 3. Private Channels: If a participant requires data pertaining to a workflow that is orchestrated over the Blockchain
network to remain private from all other members of the network, the participant may create a private channel.
Traditional database solutions could be considered as an alternative to such private channels to minimize the
complexity of managing additional run time components (e.g. orderer).
**Note: Current implementation of Hyperledger Fabric only provides logical isolation of databases per channel.
There may be need to have a higher degree of isolation at physical level. This will require provision of distinct set
of peers per channel (resulting in additional infrastructure cost, and operational complexity).
Justification N/A
Implications N/A
Derived Reqts N/A
21
AD-SEC-001

Secure Key Management and Key Operations
Architectural Decision Ensuring security of key management operations (generation, storage, and use of keys within
cryptographic operations) within Blockchain solutions
Issue or Prob Stmt • Cryptography keys and key operations (signing, verifying, encrypting/decrypting) are performed
extensively within any Blockchain solution. It is critical that there is mechanism to securely create,
store and use keys within cryptographic operations as this is the core element of trust in a
blockchain solution.
• Within a Hyperledger Fabric based solution, keys are generated for run time nodes and those
used for signing transaction proposals and responses (system/human users’ keys).
• The generation, storage and management of cryptographic keys must be performed without
impact to the qualities of service characteristics (performance, availability).
• In certain industries/use cases, compliance with industry standard certification and validation
(e.g. FIPS 140-2) may also be required.
Assumptions
Motivation
22
AD-SEC-002
(continued)

Alternatives 1. Use a Hardware Security Module (HSM) for creating, managing keys and performing key operations. For IBP, IBM
provided HSM can be used. Within Hybrid deployment, participants may use a 3rd Party Vendor HSM
• Advantages:
• Security: HSM is highly recommended for secure key generation, storage and for performing crypto
operations. If compliance with industry standards and certifications (e.g. FIPS 140-2 CMVP) are a
requirement, HSMs are the only choice
• Performance: HSMs provide an order of magnitude better performance for crypto operations than software
based solutions
• IBP HSM: If IBP is used as deployment model, IBP currently does not support HSM. However HSM support is
in the roadmap and will be offered within IBP. This will free up the customer from operational complexity for
deploying and managing HSM infrastructure in HA and DR configuration and IBM will also provide for HSM as
part of IBP support.
• Trade offs:
• Scalability: Scalability characteristics varies with the use of HSM and must be assessed within context of NFRs
of specific solution specifically given that all crypto operations will be performed on the HSM. In general,
scaling out HSMs will result in significant cost and operational complexity
• 3rd Party Vendor HSM: For Hybrid deployments, participants may use 3rd party HSM. However this will
impose additional cost and operational complexity since the HSM needs to be deployed and managed in HA
and DR configuration. Operational procedures must be put in place for key backups/restore, key rotations
etc. In addition, support for 3rd party HSM does not exist in 1.0 GA and is expected in future releases. At
this point, these will have to be custom implementations. While customers deploying on prem to Z (i.e. Linux
on Z) could use Crypto Card, this is not yet supported.
23
AD-SEC-002
(continued)

Alternatives 2. Develop a custom software based approach for creating, managing keys and performing key operations. This
approach will only work for Hybrid deployments where cost and operational complexity are overriding concerns
over security. This approach will likely only be applicable for non production deployments(e.g. internal
deployments, POCs, Pilots etc.).
• Advantages:
• Operational Simplicity: Less cost and complexity (since no new infrastructure components are required
besides the core fabric components). However, additional operational procedures required for safe
keeping of keys and ensuring keys are not compromised.
• Support: These will be custom implementation and no official support is required.
• Trade offs:
• Security: Since keys are stored in file system, and key operations are performed in software, the solution
is less secure. Certain mitigating actions could be taken, for instance ensuring strict access controls can
be put in place to ensure there is no unauthorized access to the keys.
• Performance: Crypto operations are generally slower when performed in software.
Justification N/A
Implications N/A
Derived Reqts N/A
24
AD-SEC-002

CA Design for Membership Management
Subject Area Identity
Architectural
Decision
Issuance and Management of Certificates for participants within Blockchain Solution
Issue or Prob
Stmt
• Within Hyperledger Fabric based network, participants need valid identities in form of Enrollment Certificates (Ecerts) to access
and participate in the Blockchain solution. These Ecerts are Public Key Infrastructure (PKI) based certificates.
• Participants need flexibility to issue and manage such Ecerts for their peers and users (people or system) in a federated manner
while at the same time ensuring that the network transactions are trusted by other parties.
• To enable federated issuance, management and administration of such identities, participants within the Blockchain network will
host their own Certificate Authority (CA).
• This CA is usually configured as an intermediate CA that will use internal Organization Root CA or an external CA as Trust
anchor; External CA is likely case for multi party networks where the external CA will be trusted CA within the network.
• The Intermediate CA can be Hyperledger Fabric CA or 3rd Party CA that organization may already deploy/use. The Intermediate
CA will issue Enrollment certificate (Ecert) to run time nodes (e.g. peers) and users.
• The intermediate CA can be deployed in two-tier or three-tier hierarchy based on participant context (considering the trade
offs).
• In a two-tier CA hierarchy, an External CA/Root CA issues certs to an Intermediate CA that will in turn issue ECerts for
Blockchain solution entities (peers, users etc.).
• In a three tier hierarchy, an External CA will issue certificate for the organization’s Level 1 CA which in turn issues cert for
the Level 2 Intermediate CA that will be responsible issuing ECerts for Blockchain solution entities.
• The choice of two tier vs three tier depends upon organization’s existing CA architecture. Three tier provides better security,
scalability and flexibility than Two Tier Hierarchy, however it introduces additional operational cost and management complexity.
25
AD-IDM-001
(continued)

26
AD-IDM-001
(continued)

Alternatives 1. Participants are recommended to use dedicated Intermediate CA for Blockchain solutions.
• Advantages:
• Manageability: Although the corporate security teams will govern the policies, procedures around issuance and
management of certificates and keys, the day to day operation of Intermediate CA could be delegated to Blockchain
operations team towards driving efficiencies in DevOps and ongoing management of Blockchain solution.
• Security: The intermediate CA may be kept offline if only limited number of certs are issued (e.g. peers, Node.js server
etc.) to ensure further security and prevent compromise of CA key materials. However, the CA can be online if on
demand issuance of Ecerts to users is required. It is highly recommended that CA key be secured in an HSM.
Procedures must be defined for monitoring certificate expiration and reissuance of certificates (for both intermediate CA
cert and certs issued by intermediate CA).
• HA: Depending upon the volume of certs issued and whether online/on demand provisioning of certs are needed,
Intermediate CA may need to be deployed in HA configuration. If Fabric CA is used as the CA, then this means multiple
instance of Fabric CA will need to be deployed with MySQL/PostgreSQL as backing store.
• Authentication: Intermediate CA will need to be integrated with LDAP to ensure users are authenticated prior to issuance
of Ecerts.
• Trade offs:
• Operational Complexity: Introduces additional operational complexity in managing dedicated Intermediate CA, secure
management of keys (and key operations), procedures to monitor and manage certificate life cycle events. . Addition of
intermediate CA will impose additional manageability and operational complexity for clients. Cost of deploying
additional infrastructure for intermediate CA also needs to be considered
• Only ECDSA keys are currently supported and needs to be considered when using 3rd Party CA. Note: Fabric CA
supports ECDSA keys
27
AD-IDM-001
(continued)

Alternatives 2. Use organization’s existing Level 1 or Level 2 CA for Blockchain solutions. This CA issues Ecerts to run time nodes (e.g.
peers) and users.
• Advantages
• Operational Simplicity: Reuses existing infrastructure although the infrastructure may need to be scaled to meet the
higher volume of certs that need to be issued and managed within context of Blockchain solutions. Existing
infrastructure for secure management of keys (and key operations) and existing procedures for certificate lifecycle
management can be reused.
• Tradeoffs:
• Manageability: Imposes significant operational burden on the corporate security teams or existing operations that
manage the organization’s existing CA with the operation of the Blockchain solution imposing bottlenecks and
inefficiencies in DevOps and ongoing management of the Blockchain solutions.
• HA: Although existing HA solutions an be reused, it is important to ensure availability of CA meets the availability
requirements of Blockchain solution. Any constraints within deploying existing CA in HA configuration need to be
considered.
• Security: Typically organization CA is kept offline for security reasons. However, this CA will be need to be kept
online if on demand issuance of Ecerts to users is required. This could present a security challenge since
compromise of CA keys will have a pervasive impact on the organization. This can be mitigated through additional
measures such as securing keys in HSM.
• Authentication: The CA will need to be configured to ensure the users are authenticate (e.g. through integration with
LDAP ) prior to issuance of Ecerts.
Justification N/A
Implications N/A
Derived Reqts N/A
Related Decisions *** To be filled in once we have numbering of architecture decisions28
AD-IDM-001

Identity and Access Management
Architectural
Decision
Authenticating and Authorizing access to Blockchain solutions.
Issue or Prob
Stmt
• Within a Blockchain solution, each participant needs to ensure that valid identities and roles have access to the Blockchain
solution.
• Valid identities can be of two kinds:
• Organizational identities (people, systems) that must be authenticated and authorized to access the Blockchain.
Organizational identities usually already exist within an organizations. Relevant organization specific roles also exist in the
organization’s context. Organizational roles are used to authorize actions against the organization’s enterprise systems.
• Blockchain identities (by means of Ecerts) are used to perform actions on the blockchain, such as executing smart
contracts. Blockchain solution specific roles also exist and are meaningful in context of the relevant Blockchain solution.
• These two identities and roles do not necessarily map one to one.
• How can authentication and authorization of identities be performed in these two contexts: Organization level and Blockchain
solution level?
29
AD-IDM-002
(continued)

30
AD-IDM-002
(continued)
Identity
Management on
Blockchain
Identity Management Structure on Blockchain
Hyperledger Fabric
Blockchain Platform
Blockchain Network
Blockchain Solution
Enterprise System Enterprise System
Enterprises have
user IDs
Blockchain Solution
has Roles
Blockchain Network
has CA Enrollments
Organization Identity
(People & Systems) Blockchain Identity
Solution
Identity
(Role)
Provided
by IDP
Provided by
Fabric CA
Provided by
Solution Design
Company
A
Company
B

Alternatives • Blockchain solutions often have an application tier that integrates with the chaincode deployed onto the
network (i.e. endorsers on a channel) through an integration tier. The application tier may be common to
all participants (e.g. a Web front end developed for the Blockchain solution), or could be custom for each
participant. In either case, such an application can authenticate and authorize organizational identities
(users, systems) through following means:
1. Authenticate and authorize the users through the participant’s Identity and Access Management (IAM)
system (e.g. IBM Security Directory Server, Microsoft AD etc.). Risk based MFA and existing SSO
mechanism may also be used.
2. Authenticate and Authorize users through the IBM Cloud Identity Service (CIS). CIS can integrate with
participant’s cloud based or on- premises directory service. IBM CIS also support MFA and SSO.
31
AD-IDM-002
(continued)

Alternatives 2. Applications access/invoke chaincode through an integration tier that exposes REST endpoints. The integration tier is
responsible for mapping the organizational identity to Blockchain identity (using Node.js SDK) that is required to
access/invoke the chaincode provided by the Blockchain solution. The following approaches can be considered for mapping
organizational identity to blockchain identity:
1. Take a 1-1 approach for mapping organizational identities to Blockchain identities (Ecerts) will provide non repudiation
for user actions, however could result in significant management complexity if high volume of certificates (and keys)
need to be issued and managed. If Fabric CA is used, Fabric CA currently does not support SSO or identity federation.
2. Multiple organizational identities could be mapped to a coarser grained Blockchain identity (e.g. Ecert issued to a
system/process/line of business etc.). This approach is simple, however does not support non repudiation in cases
transactions needs to be attributable to specific users (although user information could still be capture as part of
transaction payload).
3. The integration tier needs to map Blockchain identities to appropriate Blockchain solution roles for authorization. User role
information can be passed to chaincode to make fine grained authorization decisions. Currently the only way to do this is via
transient field or as part of operation signature both of which are not preferred approaches. Transaction certificates (Tcerts
- One-time use certificates per transaction) support in future will enable attribute based ACL.
4. Onboarding and management of organizational identities, Blockchain identities, relevant keys & certificates, and performing
authentication and authorization of transactions based on such identities and roles (organizational and Blockchain solution
specific roles) can be quite challenging within a large business network. IBM’s Membership Management & Onboarding offers a
solution. Please refer to Appendix for more details.
Justification N/A
Implications N/A
Derived Reqts N/A
AD-IDM-002

World State Data Store
Subject Area Data Storage
Architectural
Decision
Choice of data store for ledger world state
Issue or Prob
Stmt
• Currently, there are two choices available for choice of a database for the world state
database.
• The choice of database for Blockchain network will influence the data model, access
patterns, deployment topology, operational complexity and manageability.
33
AD-DATA-001
(continued)

Alternatives 1. Use CouchDB as the database for world state.
• Advantages:
• Data Representation: Enables data to be stored as JSON documents, supporting ability to have a richer data model
• Query Support: Providing rich query support that includes, key range queries, composite key queries and complex rich
queries against data values in the JSON document (using JSON query language) can be performed. Note: Currently,
rich queries are only supported in read only mode since there is no guarantee the result set is stable between
chaincode execution and commit time for such queries
• Analytics: Provides better support for analytics since data could be replicated to an analytics engine such as Spark for
deeper reporting and analytics.
• Performance: Provides better support for creating indexes, views that lead to better performance of queries. Note:
Fabric 1.0 currently does not support indexes and views.
• Key Trade offs:
• Operational Complexity: Runs as a separate database process alongside the peer, therefore additional considerations
needed in terms of setup, management, and operations
• Support: Currently not supported within the IBP, however support is part of the roadmap and expected soon.
34
AD-DATA-001
(continued)

Alternatives 2. Use LevelDB as the database for world state.
• Advantages:
• Operational Simplicity: LevelDB is the default key/value state database embedded in the peer
process.
• Support: Supported out of the box on the IBP.
• Key Trade offs:
• Data Representation: only offers storage of key/value pairs.
• Query Support: Only offers querying based on keys.
• Analytics: not appropriate for analytics .
Justification N/A
Implications N/A
Derived Reqts N/A
Related
Decisions
*** To be filled in once we have numbering of architecture decisions
35
AD-DATA-001

On-chain vs Off-chain data
Architectural
Decision
Representation and storage of documents, images, files etc. pertaining to transactions that
occur within a Blockchain solution.
Issue or Prob
Stmt
• In some blockchain based solutions, there is a need to exchange documents, images,
files, etc, associated with transaction data.
• In use cases such as Know Your Customer and Contract Management, the ultimate
source of evidence relies on the ability to prove evidence via the existence of pre-
verified or contractually agreed-to documents.
• In KYC, the evidence about who an individual is or an organization is constituted by is
provided by identity proof documents that have been certified by a participating
organization.
• In contract management, the agreed-to and signed contract between parties that is
legal and binding requires verifying the actual document that holds signatures.
• In such use cases, because documents are part of the accountable and irrefutable proof of
due-diligence, a key question that arises when designing such a solution is to think about
whether the document objects should be stored on-chain or off-chain.
36
AD-DATA-002
(continued)

Alternatives 1. On Chain: With this approach such data is stored directly on the ledger The member organization is a direct
participant in the network
• Advantages:
• Development Complexity: Less complexity since chaincode will manage life cycle of object along with life
cycle of related data attributes that are stored on chain.
• Data Consistency: Data pertaining to the Object can be kept in sync more easily with other relevant data
attributes since both reside on the chain
• Access Control: Access controls can be applied for both the object and other data on the chain since they
are enforced in a consistent manner.
• Availability: Addressed through HA for Fabric components (peers, orderer, Fabric CA etc.)
• History and Provenance: Inherently provided within the Blockchain solution.
• Manageability: No added impact to manageability.
• Trust: Fewer components that needs to be trusted, making security engineering a little easier
• Trade offs:
• Performance and Scalability: As the number (and size) of object increases, performance and scalability of
network is impacted since object will be part of the payload exchanged during consensus (endorse-order-
validate) process. Thus, there is a need to scale the network (peers, orderer) across the participants of the
network.
37
AD-DATA-002
(continued)

Alternatives 2. Off Chain: With this approach, the data is stored off chain in shared store such as Object store.
• Advantages:
• Availability: Typically can be deployed in in HA configuration to meet the same service levels as the Fabric
components
• Performance and Scalability: Offers a more scalable solution, since the document data does not become part of the
consensus process
• Trade offs:
• Development Complexity: Increased complexity since the application needs to manage the life cycle of object and
related data stored on the chain by directing such operations to both Blockchain and Object Store.
• Data Consistency: Access controls must be in place to ensure no operations occurs directly against the object store
and cause them to get out of sync with the ledger
• Access Controls: Access controls need to be separately implemented for the Object store to prevent data from
being tampered with (and thus going out of sync with data on the chain)
• History & Provenance: Object store must support and be configured to provide history and provenance of object
life cycle states.
• Manageability: There is impact to manageability of the solution due to increased complexity arising out of designing,
deploying and maintaining the object store.
• Trust: Adds another point of trust. Considerations must be given to how documents are stored (e.g. encrypted).
From a governance standpoint, important to ensure that the entity running the document store does not misuse or
leak the documents. If such trust is absent, the objects must be encrypted before submitting to the store for write.
38
AD-DATA-002
(continued)

Justification N/A
Implications N/A
Derived Reqts N/A
39
AD-DATA-002

PII and EU GDPR
Architectural
Decision
Storing personal data within a Blockchain-based solution while guaranteeing the data security and privacy (specifically for EU GDPR
compliance)
Issue or Prob
Stmt
• GDPR aims to give EU citizens and residents control of their personal data:
• Easier access to their data
• Data portability between service providers
• Right to erasure (“right to be forgotten”)
• Right to know when their personal data has been hacked
• Personal data means “any information relating to an identified or identifiable natural person who can be identified, directly or
indirectly, by reference to an identifier (e.g. name, identification number, location data, online identifier, one or more factors
specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person)”
• The “right to erasure” has deep impacts on the definition of blockchain solutions because blockchains are an “append only”
system, so it is not possible to erase data stored in it and data immutability is a key and desired characteristic of such solutions
Assumptions The business network includes companies that does business in the EU in some way, shape or form. Considering that data security
and privacy are going to be more relevant worldwide, this architectural decision should be evaluated anyway.
Motivation • The new EU data privacy and security regulation - General Data Protection Regulation (GDPR) - goes live on May 25, 2018. From
that day it has the potential of global impact and large financial penalties for failure to comply. For each significant breach or
failure to comply, the fines can be up to 20 million euros or 4% of global annual turnover.
• GDPR can be viewed as applying to any personal data that can identify data subjects, regardless of where that data is stored or
processed in the world. Data subjects can be viewed as any residents in Europe, wherever their data is in the world.
40
AD-DATA-004
(continued)

PII and EU GDPR
Subject
Area
Data Storage
Alternatives 1. Storing personal data in a side database and delete them when needed (hard erasure)
• Using the Blockchain as a system of trust, the information stored in the Blockchain is not
all information required by the use case, but a subset, plus a reference to bulk data
residing in a traditional data store
• Using a crypto hash reference to an external data store allows to understand if anything
in that external store has change
• In this way, removing the information from the traditional store, means the reference in
the blockchain becomes defunct. The Blockchain has not been edited, but the system to
which it refers to has
• This is a desirable native function of the Hyperledger Fabric and is already on its feature
list, see FAB 1151 (Side DB-Private Channel Data) and FAB 2450 (Client SDK-Transient
Data Handling)
41
AD-DATA-004
(continued)

PII and EU GDPR
Subject
Area
Data Storage
Alternatives 2. Using cryptographic features to make personal data in the blockchain unreadable (soft
erasure)
• Blockchain content has to be encrypted in a way that makes the content unreadable
without using the proper keys. Destroying the keys makes the content permanently
unreadable
• As GDPR is not yet effective, no juridical literature exists regarding soft erasure
compliance with GDPR requirements, so choosing it to comply with the right to erasure
requirement is a high-risk decision
42
AD-DATA-004
(continued)

PII and EU GDPR
Subject
Area
Data Storage
Alternatives 3. Deleting the personal data stored in the blockchain (editing the immutable blockchain)
• Using a variation of the “chameleon” hash function, through the use of secure private
keys it is possible to edit the blockchain allowing designated authorities to edit, rewrite or
remove previous blocks of information without breaking the chain
• Immutability of blockchain is one of its greatest strengths so implementing the capability
to edit blockchain could introduce other side effects and should be not desirable in a
real implementation
43
AD-DATA-004
(continued)

PII and EU GDPR
Justification • To comply with the GDPR right to erasure, personal data should be kept private from chain,
with only its evidence (hash) exposed to the chain. In this way, personal data could be
deleted when needed without any further impact
• Blockchain immutability could be used to demonstrate the compliance with the process to
guarantee the right to erasure
• As GDPR is not yet effective, no juridical literature exists regarding hard vs. soft erasure
compliance with GDPR requirements, so choosing to leverage cryptographic functionalities
(soft erasure) to comply with the right to erasure requirement is a high-risk decision.
• Immutability of blockchain is one of its greatest strengths so implementing the capability to
edit blockchain could introduce other side effects and should be not desirable in a real
implementation
Implications N/A
Derived
Reqts
N/A
Related
Decisions
44
AD-DATA-004

Design of Endorsement Policies
Subject Area Consensus
Architectural
Decision
Issue or Prob
Stmt
• An endorsement policy specifies the requirements for a transaction endorsement. Specifically, the policy
specifies the stakeholders that must “endorse” the transaction in order for the transaction to be considered valid
during the validation phase (of consensus) by peers participating in the channel. Endorsement policy is specified
for a chaincode during chaincode instantiation on the channel. An endorsement is a signed response of the
result of a transaction execution from a principal (as per the requirements of endorsement policy). Principals are
expressed as MSP.ROLE where role can be member or admin.
• The problem here is to consider the nature of chaincode transaction and determine which parties in the channel
need to endorse the transaction. Specifically, one can consider the business rules/logic involved in the smart
contract and in the life cycle state transition of an asset. The first step is to determine if such logic/rules
concern specific parties, in which case those parties must consent to the transaction through endorsements.
• For instance, when a payment instruction is submitted to Blockchain by a Bank, if rules in smart contract
require application of certain validation rules pertaining to the Bank that will ultimately process that
payment instruction, then endorsement may be required from both Banks (e.g. policy such as OrgA.member
and OrgB.member). A regulator who is part of the same channel will not be part of endorsement policy
since they only need visibility to the payment instruction for compliance purposes (e.g.. AML)
Assumptions
Motivation
45
AD-CONS-001
(continued)

Subject
Area
Consensus
Alternatives 1. Ensure only minimal set of stakeholders/participants required for endorsing transaction are
specified in endorsement policy. This avoid requesting endorsements from participants who
do not have a direct stake in the transaction.
• Advantages:
• Provides optimal configuration for performance, scalability and availability
• Chaincode will need to be installed on minimal set of peers/participants mentioned in
the endorsement policy resulting in lower complexity from operations and change
management standpoint.
• Trade offs:
• Risk of requiring too few endorsers that may defeat the purpose of endorsement policy
which is to ensure that parties that have a stake in the transaction are party to endorsing
such a transaction.
46
AD-CONS-001
(continued)

Subject Area Consensus
Alternatives 2. All parties in the channel are required to endorse a transaction. While this may be
legitimately required in a use case, care must be exercised with this option.
• Advantages:
• Simplicity of endorsement policy
• Trade offs:
• Adverse impact on scalability and performance ( with having to wait for more
endorsements than necessary)
• Adversely impact availability (if one of the participant is down or experiencing outage)
then transactions cannot be committed
• Requires chaincode installation, management and maintenance on all participants
resulting in high complexity from operations and change management standpoint.
Implications N/A
Derived
Reqts
N/A
Related
Decisions
47
AD-CONS-001

Fabric Composer and Hyperledger Fabric
Subject Area Tooling
Architectural
Decision
Determining tooling to develop blockchain solutions – Hyperledger Composer or Hyperledger Fabric
Issue or Prob
Stmt
• Blockchain development requires acquisition of new skills:
• Cryptography
• Distributed systems architecture
• Consensus Algorithms
• Remote procedure call interfaces
• Understanding threading and reentrancy models
• Programming languages – Go/Javascript. etc
• The tools for blockchain-based development require integration with best-of-breed tools and processes for
enterprise application development: Continuous integration, DevOps pipelines, Blue-Green rolling deployment,
Artifact repositories, Sharing/versioning of binary assets and Versioning of source assets.
• A key choice that organizations face when starting on a new blockchain project on Fabric is the choice of tooling
to start the development – Using the Go language and developing the solution directly on Hyperledger Fabric or
Using the Javascript language to develop the solution using developer-friendly tooling.
Assumptions
Motivation
48
AD-TOOL-001
(continued)

Alternatives 1. Develop the application using Hyperledger Composer.
• Advantages:
• Composer is a modern programming model and toolset for building blockchain applications and uses
one language (Javascript) for writing business logic and calling the APIs.
• Learn one programming language and you can develop applications that go from the web-browser all
the way back to the blockchain.
• Hyperledger Composer is IBM’s strategic tool to develop blockchain applications.
• Composer integrates well with a modern development best practices and tools.
• Composer introduces higher-level abstractions over the blockchain that make it radically simpler to
map from business requirements to a running implementation.
• Composer enforces a clean separation between the distinct layers of a blockchain application:
• Data model for the assets, participants and transactions (the data stored on the ledger)
• Access control rules for the data on the ledger
• Certificate (identity) mapping to the solution participants
• APIs used by application developers to access the business network, either to query the ledger
or to submit transactions
• Trade offs:
• It is newer technology and still in beta phase, version 1 is yet to be released.
• Developers already familiar with programming with the Hyperledger Fabric SDK will have to go
through a learning curve again to learn the new tool.49
AD-TOOL-001
(continued)

Alternatives 2. Develop the application using Hyperledger Fabric SDK
• Advantages
• The Hyperledger Fabric SDK is designed in an Object-Oriented programming style.
• Its modular construction enables application developers to plug in alternative implementations of
key functions such as crypto suites, the state persistence store, and logging utility.
• Trade-offs:
• You need to be a developer to understand the Hyperledger Fabric SDK and create the business
network solution
• You need to have Go development skills as Hyperledger Fabric as the Go programming language is
used for many of its components
Implications N/A
Derived Reqts N/A
Related
Decisions
50
AD-TOOL-001

Enterprise Application Integration
Subject Area Integration
Architectural
Decision
Determination of architectural integration from enterprise applications to blockchain network.
Issue or Prob
Stmt
• Applications/systems/users need a way to interact with the Hyperledger Fabric based Blockchain network. This
would be for purpose of: committing transactions to the ledger, querying transactions from the ledger, receive
notification of events that occur within the ledger. provision credentials etc. Currently within Fabric 1.0 GA Node
SDK and Java SDK are two available options for integration with Blockchain network.
• Primary integration pattern is to expose a set of REST endpoints/APIs through an application server tier developed
using Node.js or Java. These REST API will be used by consumers to integrate with the Blockchain network (e.g.
invocation for chaincode).
• When there is need to integrate with existing enterprise systems, an integration hub (e.g. IBM Integration
Hub/DataPower) can be used to support various integration patterns (events based, message based etc.) and to
perform required data and protocol transformations prior to the invocation of the REST endpoints. For instance, a
system originating the transactions might produce messages to a queue, the integration hub can consume messages
from the queue and invoke the REST endpoint to submit transactions to the ledger.
• For scheduled tasks, a scheduler service can be used to run scheduled and recurring tasks through invocation of
REST APIs.
• Current integration model lends itself well to transactional workloads, i.e. where transactions are submitted one at
time (although may be submitted concurrently). For batch workloads, integration hub could be used, however
additional components may be needed to support staging of data and handle batch checkpoint/recovery
51
AD-INTG-001
(continued)

52
AD-INTG-001
(continued)
REST
Engine
NodeJS/Java
SDK
Integration
Hub
ENTERPRISE
APPLICATIONS
AND SERVICES
ENTERPRISE
DATA MGMT
USER
APPLICATIONS
ACTIONABLE
INSIGHT
Events
API calls
GBO/ASBO Transformation
Protocol Transformation
Event Processing Logic
Batch Processing Logic, etc
API calls

Subject
Area
Integration
Alternativ
es
1. Develop integration using Hyperledger Fabric or Fabric Composer APIs. Client applications
invoke blockchain transactions by invoking the REST APIs running in NodeJS or Java
application servers.
• Advantages: In an on-premise network this alternative would not require the network to decide
where or whom should host a common component. In small use cases with few participants
where integration between parties would be straightforward, this would be an option.
• Trade offs: Limited options in terms of integration flexibility with legacy enterprise systems
53
AD-INTG-001
(continued)

Subject Area Integration
Alternatives 2. When support for multiple integration patterns and processing logic is needed, an integration hub such
as IBM Integration Bus, intellectEU Smart Integration Engine (see appendix), can be used
• Advantages: More flexible to accommodate a variety of different integration needs. Orchestrations of
data and protocol handling or event processing can be handled. For instance, a system originating the
transactions might produce messages to a queue, the integration hub can consume messages from the
queue and invoke the REST endpoint to submit transactions to the ledger. The participants could
each consume the services with the right protocol for their need. If standards like EDI, Swift, ISO,
ACORD, etc are to be handled this would simplify and ensure correct adoption by all parties.
• Trade offs: More complex components that need administration, maintenance are added to the
solution. Development lifecycle governance would have to be previously defined by the participants
with definition of development and test procedures as well as repositories and tools for that process to
ensure all parties confidence in information process and resulting actions.
Justification N/A
Implications N/A
Derived Reqts N/A
Related
Decisions
54
AD-INTG-001

Smart contract design for flexibility &
governance
Subject Area Chaincode Design
Architectural
Decision
Designing smart contracts for flexibility, evolution and governance
Issue or Prob
Stmt
• In a blockchain solution, smart contracts encode and encapsulate transaction rules and processes that govern
transactions. Decision logic is often embedded in smart contracts. In many use cases, the decision logic usually
evolves faster than the rest of the application according to weekly or even daily changes in the market, or other
factors.
• Examples
• Smart contracts that include fraud detection logic in an asset transfer process require periodic addition of new
rules as new fraud patterns are discovered.
• Smart contracts that relate to transactions performed on multinational insurance policies require decision
logic that computes based on which country specific instance of the policy is in force.
• Involving business stakeholders to contribute in the implementation of the smart contract decision logic can result in
shorter development cycles and increased flexibility.
• A key design consideration is whether to introduce additional solution components such as a decision rules engine
in a blockchain solution to balance flexibility, governance and solution complexity
55
AD-CODE-001
(continued)

governance
Alternatives 1. Encapsulate decision logic in smart contract code
• Advantages:
• Runtime Support: Blockchain solution can be developed using either Hyperledger
Fabric or Hyperledger Composer
• Management: As this solution is native to Fabric or Composer, it is easier to manage
from a runtime perspective
• Trade offs:
• Flexibility: Less flexibility since it requires IT involvement to change smart contracts
each time a change should be made
• Governance: Using Hyperledger Fabric or Composer tooling support for governance.
The tooling is IT centric and more complex to manage evolution of the smart contract
logic where there is a need to have business stakeholder buy-in.
56
AD-CODE-001
(continued)

governance
57
AD-INTG-001
(continued)

governance
Alternatives 2. Smart contracts externalize decision logic to an external rules engine such as IBM Operational Decision
Manager
• Advantages:
• Flexibility: Offers business stakeholders the flexibility to evolve decision logic without having to open the
smart contract code. Easier to keep pace with market changes in fast changing business environments
• Governance: Helps to bring together business stakeholders (including policy managers, analysts, lawyers,
accountants, auditors) by giving them tools to express and govern the decision logic of their applications
in terms they are comfortable with.
• Trade offs:
• Runtime Support: Integration support is available for Hyperledger Composer only
• Management: The introduction of a new component in the solution architecture, adds to management
complexity of the solution.
Justification N/A
Implications N/A
Derived Reqts N/A
58
AD-CODE-001

Orchestration and Smart Contracts
Architectural
Decision
Externalizing asset state change logic to workflow engine
Issue or Prob
Stmt
• A Blockchain solution addresses interoperability, trust, and transparency issues in fragmented systems.
By using smart contracts to provide controlled access to the distributed ledger, multiple parties are
allowed to share an asset lifecycle process while maintaining a single shared and trusted version of the
truth.
• Transactions govern changes to the state of shared assets. A key architectural decision is how
transactions must be handled. There are two alternatives:
• Transaction chaincode proactively makes decision on state transitions. In this alternative, the asset
state change logic is implicitly captured within chaincode.
• State transition decision is made in the application or in an external system (for example, in a
workflow engine), with the Blockchain being used as a passive ledger to record transactions
59
AD-CODE-002
(continued)

Alternatives 1. Encapsulate asset state change and process orchestration logic within a smart contract
• Advantages:
• Contract consistency: Smart contracts control the execution of transactions between untrusted
parties and ensure that contractual conditions are met
• Runtime Support: Blockchain solution can be developed using either Hyperledger Fabric or
Hyperledger Composer
• Management: As this solution is native to Fabric or Composer, it is easier to manage from a runtime
perspective
• Trade offs:
• Flexibility: Each time a change to the process should be made it requires IT involvement to change
smart contracts
• Process governance: Using Hyperledger Fabric or Composer tooling support for governance. The
tooling is IT centric and more complex to manage evolution of the smart contract logic where there
is a need to have business stakeholder buy-in.
60
AD-CODE-002
(continued)

Alternatives 2. Smart contracts expose discrete functions, or tasks, to manage assets and events; process orchestration
is externalized to a workflow engine such as IBM Business Process Manager
• Advantages:
• Flexibility: Making incremental changes to the shared process is easier, business process can
evolve with lower impact to the smart contract code and without needing to redeploy the entire
shared process
• Process governance: The workflow engine provides comprehensive process design, test and
monitoring capabilities, bringing in the business stakeholder with tooling they are comfortable
with.
• Trade offs:
• Contract consistency: The granularity of discrete functions in the smart contract should be
carefully designed to guarantee that contractual conditions are met.
• Runtime Support: Integration support is available for Hyperledger Composer only
• Management: The introduction of a new component in the solution architecture, adds to
management complexity of the solution
Justification N/A
Implications N/A
Derived Reqts N/A
Related
Decisions
*** To be filled in once we have numbering of architecture decisions61
AD-CODE-002

Deployment models
Subject Area Deployment models
Architectural
Decision
Analyze architecture alternatives for deployment of Blockchain Solutions
Issue or Prob
Stmt
• Participants within a Blockchain network must make architecture decisions on deployment model.
• This includes determination of where participant specific Fabric components (e.g. peers, ledger, CA) and
shared Fabric components (e.g. orderer), and application components (e.g. front end, REST API etc.) will
be deployed.
62
AD-DEPL-001
(continued)

Deployment models
Alternatives 1. IBM Blockchain Platform
• Advantages:
• Security: Integrated HSM with highest level FIPS compliance. Secure Service Container is hardened
container that protects the entire Blockchain stack
• Operational Management and Cost: Lower operational and management complexity through pre-built
integration with critical infrastructure services including certificate and key management through HSM,
logging and monitoring. Results in faster time to market and lower operational costs.
• Change Management: Rolling upgrades of underlying fabric and access to new capabilities (upgrades,
patches etc.). Easier to manage changes to application components through Bluemix DevOps services.
• DevOps: Integrated tools for development, DevOps, administration and governance of network
• Availability & DR: Provides ability to provision redundant instances of peers and CA (on demand) for high
availability to meet QoS and SLA commitments. Provides highly available ordering service. Single Site
HA currently provided (99.95%) with multi-site DR in the roadmap
• Support: 24x7x365 support coverage for all solution components deployed in the SaaS platform backed by
deep Fabric expertise
• Trade Offs:
• Integration with Participant’s On Prem Systems: Introduces application integration and infrastructure
complexity. An example is integration with shared services such as IAM systems, monitoring & logging
infrastructures etc. In addition, client has to support an operational support model that involves both on
prem and cloud workloads63
AD-DEPL-001
(continued)

Deployment models
Alternatives 2. Hybrid Deployment
• Advantages:
• Control and Flexibility: Choice of deploying to on prem datacenter/cloud vendor, choice and in a deployment platform (e.g. Linux
x86)
• Integration with On Prem Systems: Easier integration with On prem systems since Blockchain solution components are deployed
on prem
• Trade offs:
• Security: Participant responsible for security hardening the on prem solution components. Management of keys and key
operations will be responsibility of client. Use of HSM and deployment of HSM in highly available configuration will introduce
additional cost and complexity.
• Operational Management and Cost: Increased operational and management complexity both in initial provisioning and ongoing
management of on prem deployment components adversely impacting time to market and resulting in increased operational
costs. Participant will be responsible for applying upgrades, patches to Fabric components. Further complexity could arise as a
result of certs & key management, HSM, provisioning HA/DR etc. Increased cost due to provisioning, managing on prem
components, software licensing (e.g. Docker EE) and support.
• Change Management: Participant is responsible for change management to both Fabric and common application components and
may encounter significant complexity as application scales to ensure coordinating and consistency in code promotion and testing
across environments.
• DevOps: Participant may use their own DevOps tools, however there will be complexity involved in integrating their DevOps
pipeline with shared DevOps service offered in SaaS making it challenging to coordinate code promotion, testing across
environments.
• Availability & DR: Participant is responsible to provide HA and DR for all components deployed On Prem in conformance with
QoS and SLA commitments required by the network. The participant is responsible for DR solution.
• Support: IBM Support limited to Docker EE and IBM Certified Docker images only. Participant needs to have a support model that
meets both SLAs its users. other participants and consortium.
Justification N/A
Implications N/A
AD-DEPL-001

High Availability
Subject Area Availability
Architectural
Decision
Designing for High Availability
Issue or Prob
Stmt
How do you guarantee participants in the blockchain network high availability of their Fabric nodes?
65
AD-AVL-001
(continued)

High Availability
Alternatives Each Participant Node needs to provide TWO active Hyperledger Fabric Peers at a minimum. If not, the
Application sending the endorsement proposal will fail to connect to the endorser which is temporarily
down. This means it will fail to get the endorsements it requires.
1. Endorsements: Hyperledger Fabric v1 introduces Endorsement Policies. These allow configuration of the
set of peers that are to be invoked to endorse a transaction, protecting it from malicious activity and non-
deterministic output. The policy can be configured to allow a transaction to be considered valid, even if a
subset of the endorsers do not respond because they are temporarily unavailable.
66
AD-AVL-001
(continued)

High Availability
Alternatives 2. Client application: Using Hyperledger Fabric v1, a client application connects to a peer using the Hyperledger Fabric Composer & the
Client Fabric Node SDK. Through the SDK the application sends transactions to the peer, and connects to other peers for endorsement
before sending the endorsed transaction to the ordering service for delivery across the network. If the peer to which the application is
connected is temporarily unavailable, the application can choose to connect to another peer on the same channel to continue submitting
transactions. All peers on the same channel will be recording all transactions submitted via peers connected to the channel.
Justification N/A
Implications N/A
67
AD-AVL-001

Disaster Recovery
Subject Area Availability
Architectural
Decision
Designing for Disaster Recovery
Issue or Prob
Stmt
68
AD-AVL-002
(continued)

Disaster Recovery
Alternatives
69
AD-AVL-002
(continued)

Disaster Recovery
Alternatives
Justification N/A
Implications N/A
70
AD-AVL-002

Next Steps
› Interoperability & Frameworks
› Pluggable architecture - What are the pluggable components?
› Smart Contract Governance – Making decisions as a group of peers
› Addition of code artifacts to support architectural decision making
where possible
› Off-chain data storage – global vs distributed stores
› Performance and Block Design
› Querying and Analytics
› Data Model Design
› Governance Topics
71

Blockchain Network Roles
72
• The business operator provides business
governance for operation of the network. This may
be in the form of a consortium legal entity, a key
network founder or other means
Technical
Operator
T
B
Business
Operator
P
Network
Participant
U
Network
User
• The technical operator provides IT governance and operation of the
nodes in a network, performing tasks such as: Define, Create, Manage
and Monitor the Blockchain network; Manage the different types of
certificates required to run a permissioned Blockchain; etc.
• Each business in the network can have a Blockchain Network
operator, or an Operator can manage all nodes in a SaaS environment
such as the IBM Blockchain Platform
• Network users are indirect participants,
where a member organization (usually a
smaller organization that does not want to
bear the full cost of using a node) uses
services provided by a network participant
using their application or exposed APIs.
• Network participants are direct participants,
who own (and may operate) a node in the
business network.

What defines Blockchain Architectural Style?
• Connectivity is provided by the business network as opposed to point-to-point.
• Transacting around assets managed by the network creates value for participants.
• The ledger (SoR) holds transaction information, is distributed and shared between
participants, and is append-only with immutable past (log).
• Smart contracts are executable code that represents transactions’ terms and
conditions. The code execute in context of the ledger.
• Consensus mechanisms make sure enough participants agree on the validity of
transactions before any update is made to ledger.
73

When to use Blockchain Architectural Style?
• Blockchain is an emerging technology
• Challenges: hype, skills shortage (developers), lack of standards, legal aspects
• Blockchain is a foundational capability
• It has the potential to do to trusted transactions what TCP/IP did to information
• Challenge: What Blockchain use case(s) make(s) sense for my organization
• When not to use? No business network (only one organization). < ms latency
required.
• When to use? (“litmus test”)
• Blockchain makes sense for a use case that drives significant business value, is
implementable, and for which Blockchain is a good fit (as opposed to a distributed DB).
• Must have: Business Network
• Plus at least one of: Consensus (transaction validation), provenance (audit trail),
immutability (tamper proof), finality (fewer disputes), currency (up to date, visibility)
74

Blockchain for Business – Architectural Principles
1. Trust: The network provides a level of trust between participants that they wouldn’t have outside the context of the
network: Trust in identity of participants, trust in validity of transactions, trust in data held in the shared ledger.
2. Control: Participants have control of their business and assets but no one is in control of or can take over the
network.
3. Permission: Participants are known. The Blockchain is permissioned, not anonymous.
4. Security: The network and its distributed ledger is secured and tamper-resistant.
5. Privacy: Bi/Multi-party private transactions and private data is supported within the context of the network.
6. Extensibility: The business network is extensible to new participants (e.g., regulators), new asset types, new
geographies, …
7. Scalability & Performance: The network can scale when the number of participants, assets, and/or transactions
grows. High performance means little or no lag for the shared ledger to update.
8. Integration: The network integrates with participants’ existing transaction processing systems and systems of
record.
75

Membership Management and Onboarding
76
Onboarding and management of organizational identities, Blockchain identities, relevant keys & certificates, and performing authentication
and authorization of transactions based on such identities and roles (organizational and Blockchain solution specific roles) can be quite challenging within a
large business network. IBM’s Membership Management & Onboarding Solution Asset offers a solution
Each user is mapped and
migrated manually,
potentially taking weeks
to fully onboard
necessary roles to
blockchain network.
Whenever a user’s role
changes or the solution
changes, the developer
and network admin need
to be repeat most of
these activities for
individual users
Enterprise System
ID
Hyperledger Fabric
Blockchain Platform
Blockchain Network
Blockchain Solution
Design/Review solution
business process Select enterprise users
for business process
Define blockchain user
roles
Build user authorization
table for solution in
enterprise systemAssociate blockchain
enrollment certificates
for users
Map & test users with
solution authorization
tables
Log into enterprise
system
Manage blockchain wallet
to access solution and
business process
Support any
authorization issues
sent in by enterprise
user
CIO
Ent.
Users
NW
Admin
Dev
With new identities to
manage outside of my
organization, am I
losing control over our
users and data?
How do I manage all of
my users, and their
solution roles, and
enroll them onto the
blockchain network?
Do I have to manage
my wallet and log
into multiple tools to
do my job? That’s a
pain!
Do we need to
redesign role profiles
and integration of the
solution every time we
connect it to a
member’s enterprise
system?
… + Potentially nobody
is educated in
blockchain
Complexity of managing identities on blockchain

77
› Bring your own identity provider
– Blockchain should not mean that CIOs lose control over identities of their organization users that participate in the
network.
– Through integration with IBMid. IBMid supports OpenID Connect and SAML and federates with over 100 organizations.
› Relieved from managing user certs and keys
– Management of enrollment certs (ecerts), public, and private key in Fabric CA is challenging. The overhead can be
significant once a solution graduates from a demo to a beta comprising hundreds of participants and beyond.
› Establish trust among solution components
– Multiple solution components need to communicate to establish trust (e.g., verify a user token and its role, retrieve its
blockchain creds)
› Manage identities used for fabric as well non-fabric
– Not all users need to have blockchain credentials, but need to be authenticated with their organization’s identity
provider.
› Role-based access control
– Participants in a blockchain network agree on roles, which are enforced through chains (currently not on chain)
– Enforcement of access is done at component level.
› Flexible deployment model to meet various solution needs
– One instance across all orgs (e.g., IBM manages fabric CAs of multiple orgs)
– One instance for some orgs (e.g., IBM manages fabric CAs of some orgs, other orgs manage their own CAs)
– One instance org (e.g., each org uses it to manage certs and hookup with their identity providers)

78
Fabric CA / Fabric Peer
Instance
Organization A
• User profile stored in IBM id
• Uses IBM cloud services;
• IBM ID is already integrated
OIC
Organization B
• User profile stored in org’s Idp
• Has their own ID provider (OpenID
Connect / SAML)
• Readily integrate with MMO through
IBM id federation (no change to
MMO)
SAML
Organization C
• User profile stored in org’s Idp
• Has their own LDAP provider but exposed
over Internet / Intranet
• LDAP requires some customization
LDAP
Organization D
• User data stored org’s Idp
• Does not use MMO
• Manually onboard each user per org on
blockchain network, manage creds
ID
IBM ID
Blockchain Network (SoftLayer or IBP)
For members using MMO,
IBM ID will federate client
user IDs and registers them
in batch on blockchain
• Relieve clients of overheard from managing users (identities, authorizations, public/private keys, enrollment certificates, etc) in blockchain network
• Clients may bring their own identity service provider to the blockchain network
• Assertion of roles for user identities for implementing role-based access control in a solution involving blockchain
Benefits
Fabric CA
Fabric Peer
MMO registers each user
with correct authorization.
User passwords are
maintained in IBM ID, and
blockchain creds are stored
securely in Cloudant.
MMO module can be setup for
each individual member
organization (per fabric
CA/peer), or one set for the
entire blockchain network
Enterprise User Selection
Blockchain business
process review
Map Enterprise User profile
with Blockchain User Profile
Define blockchain user
profile and authorization
Migrate User Profile
Test Migrated User Profile
Uses MMO Does not use MMO
Each user is
mapped and
migrated
manually,
potentially
taking weeks
to fully
onboard
necessary
roles to
blockchain
network
Cloudant
Recommended
path for first POC
(time to impl)
Recommended
path for prod
(time to impl)

Enterprise Application Integration – intellectEU
Connector
79

Enterprise Application Integration – intellectEU
Connector
80

Blockchain solution architecture deliverable

More Related Content

Blockchain solution architecture deliverable