IBM Blockchain Mastery Award Certification preparation guide


  • Overview

    What is blockchain? shared immutable ledger for recording the history of transactions.

    business blockchain, provides a permissioned network with known identities.

    Blockchain Accountability: blockchains bring trust to business networks through consensus, provenance, immutability, and finality.
    o Consensus: Participants agree that a transaction is valid.
    o Provenance: Participants know where the asset came from and how its ownership has changed over time.
    o Immutability: No participant can tamper with a transaction after it is agreed upon. Existing transactions cannot be changed, deleted, or reordered.
    o Finality: There is only one place to determine the ownership of an asset or completion of a transaction (the shared ledger).

    Bitcoin versus blockchain for business
         • Bitcoin uses an un-permissioned public ledger:
                  o Defines an unregulated shadow currency.
                  o The first blockchain application.
                  o Resource-intensive.
         • Blockchains for business are generally permissioned and private, and prioritize:
                  o Identity over anonymity.
                  o Selective endorsement over proof of work.
                  o Assets over cryptocurrency.

    Blockchain main components
               o Business Network set of distributed nodes that uses blockchain technology to generate agreement over transactions
               o Participants are known and require an identity.
               o Assets are exchanged between business network participants.
               o Transactions describe asset exchange.
               o Contracts underpin transactions.
               o Ledger is a log of transactions, it is a type of database, or system of record, that is distributed, shared, replicated, and synchronized among the members of a network

    Components of Shared ledger: 
          • Blockchain: The chain provides an immutable, transparent record of transactions:
                o A linked list of blocks, new blocks always added to the end
                o Each block contains zero or more transactions and some additional metadata.
                o Blocks achieve immutability by including the result of a hash function of the previous block.
                o The first block is known as the “genesis” block.
                o Every record in the distributed ledger has a time stamp and unique cryptographic signature,
                   thus making the ledger an auditable history of all the transactions in the network.
          • World State: The world state stores the current state of assets:
                o An ordinary database (for example, a key/value store).
                o Stores the combined outputs of all transactions.
                o Not usually immutable.
                o Supports private data collections.

    WorldState use LevelDB by default, it support for keyed queries, but you cannot query on the value, in production it is better to use CouchDB
    CouchDB advantages:
    • Full query support on key and value (JSON documents).
    • Meets a large range of chaincode, auditing, and reporting requirements.
    • ID/document data model that is compatible with the existing chaincode key/value programming model.
    • Index management capabilities to gain improved performance.

    Blockchain can be built by using two key Hyperledger projects:
    • Hyperledger Fabric is a blockchain that provides an implementation of a ledger, smart contracts, privacy, and consensus.
    • Hyperledger Composer is a suite of tools that makes it easy to develop blockchain applications.


  • Introducing Hyperledger Composer

    Opensource tool for quick solution creation, Reduce risk, and increase understanding and flexibility

    o Model your business networks, and test and expose through APIs.
    o Applications invoke APIs transactions to interact with the business network.
    o create REST APIs for integration by using LoopBack/REST.
    o Hyperledger Composer provides back-end integration with Node-RED Software, and IBM App Connect Enterprise and IBM API Connect, IBM StrongLoop.

     Note: Node-RED is a flow-based development tool that you use to create applications without having to write code. Instead


    Hyperledger Composer Architecture
    Business network archive (.BNA) is a package of the resources that are used by Hyperledger Fabric:
    o Model files (.CTO).
    o Transaction processors (.JS).
    o Access Control Lists (.ACL).
    o Static queries (.QRY).
    o Documentation and versioning (.MD).
    o .BNA does not contain the client application.

    Create BNA files from Playground or a command line 

    composer archive create –archiveFile my.bna 
                            –sourceType module –sourceName myNetwork

    Queries allow applications to perform complex searches:
    o They can be statically defined in a separate .qry file or generated dynamically by the application.
    o They are invoked in the application by using buildQuery() or Query().
    o Queries require the blockchain to be backed by CouchDB.

    Hyperledger Fabric uses LevelDB as the default state database, CouchDB is an optional alternative external state database that provides extra query support.


    Hyperledger Composer Playground
    • Web tool for defining and testing Hyperledger Composer models and scripts.
    • Designed for the application developer:
    o Define assets, participants, and transactions.
    o Implement business rules within transaction processor scripts (Smart Contracts).
    o Test by populating registries and invoking transactions.
    • Deploy to instances of Hyperledger Fabric, or simulate completely within a browser.

    Composer Connection profiles:
    – describe Hyperledger Fabric connection parameters. One connection profile is required per channel
    – Not necessary for a web-based simulation.
    – Enrollment in Hyperledger Fabric network is required. You issue a Hyperledger Fabric identity from the Hyperledger Composer participants.

    Business network cards: 
         Package identity and connection profile, Each card refers to a single participant and single business network
         Use cards to connect to Hyperledger Fabric from Playground, CLI, or from within your application.
         Manage cards from both Playground and the CLI:
                             o Create, delete, export, import, and list.
                             o Create requires a user ID/secret or certificate/private key.

    /*Install and Start new Network*/
    composer network deploy -a my.bna -c my.card



  • Blockchain solution architecture

    Design goals
    • specifying who endorses transactions.
    • Support broader regulatory requirements for privacy and confidentiality.
    • Scale the number of participants and transaction throughput.
    • Eliminate nondeterministic transactions.
    • Support rich data queries of the ledger.
    • Dynamically upgrade the network and chaincode.
    • Supports multiple credential and cryptographic services for identity.
    • Supports ”bring your own identity”.


    Digital identity

    • Identities consist of public/private key pairs that are known as certificates.
    • Identity documents are issued by trusted third parties that are known as certificate authorities (CAs).
    • Private blockchain networks also require CAs so that network members know with whom they are dealing.
    • CAs may sit within a regulatory body or a trusted subset of participants

  • Blockchain in-depth

    Peers :the main nodes that operate on a blockchain.
    • Peers:
          o Hold and maintain the ledger.
          o Receive transactions from clients, other peers, and orderers.
          o Can validate transactions.
          o Notify client applications about the outcome of submitted transactions.
          o Hold and run chaincode.
    • A peer is owned and maintained by an organization. Each organization might own one or more peers.
    • Each peer:
           o Runs in its own environment independently of other nodes,
           o Connects to one or more channels,
           o Maintains one or more ledgers, one for each channel.

    Peers types:
           – Endorser peer
           – Commiter peer: (include endoroser peer) 
           – Anchor peer : (one of commiter peers) replicate message to new network to save overhead.


    • Each client application uses Fabric SDK to:
              o Connect over channels to one or more peers.
              o Connect over channels to one or more orderer nodes.
              o Receive events from peers.
    • Clients usually query peers from their own organization.
    • Clients connect to peers from other organizations when they want to update the data in the ledger.
    • Clients can be written in different languages (Node.js, Go, Java, or Python).


    MSP (membership service providers)
    In permissioned business networks, network access is controlled
    MSP allows operations for issuing and the management of Hyperledger Fabric membership credentials
    Fabric-CA is the default implementation for the MSP interface

    MSPs provide functions for:
    o User credential validation.
    o User (anonymous but traceable) authentication: signature generation and verification.
    o User attribute authentication: attribute ownership proof generation, and verification.
    o (Optionally) User credential issuance.

    Smart contracts
    • Smart contracts govern interactions with the ledger
    • They consist of programmatic code that is deployed on the network, encapsulating business rules and business logic.
    • They define and enforce the terms that are agreed to by the network participants.
    • They are typically run and validated by multiple peers on the network during the consensus process.
    • They can enable network participants to run certain aspects of transactions automatically.

    • Hyperledger Fabric write smart contracts into chaincode
    • Developers can use chaincodes to develop business contracts, asset definitions, and collectively manage decentralized applications.
    • All transactions (initialization, query, or update) are done through chaincode.
    • Chaincode can be implemented in either Go or Node.js.
    • Access to chaincode is permissioned.
    • Chaincode is installed on peers to access the world state.
    • Chaincode runs within a channel.

    Channels are private subnets of the blockchain network where clients and peers communicate and transact privately.
    • Channels provide privacy between different ledgers.
    • Peers can participate in multiple channels.
    • Ledgers exist in the scope of a channel
    • Channels can be shared across an entire network of peers.
    • Channels can be permissioned for a specific set of participants.
    • Chaincode is instantiated on specific channel.
    • Channels provide concurrent execution for performance and scalability.


    In Hyperledger Fabric, registration for events occurs at the level of the channel
    Based on channel configuration, requests to receive events are accepted both from identities inside or outside of the peer’s organization.

    Events allow applications to act when a transaction occurs:
    o Events are defined in models (.cto file)
    o Events are emitted by transaction processor scripts (.js file)

    • Keep all peers up-to-date.
    • Fix any peers in error.
    • Ignore all malicious nodes.

    Consensus algorithms
    1) Proof of work
                Requires validators to solve difficult cryptographic puzzles.
                Pros: Works in untrusted networks.
                Cons: Uses much energy, and slow to confirm transactions.
                Example usage: Bitcoin and Ethereum

    2) Proof of stake
                Requires validators to hold currency in escrow.
                Pros: Works in untrusted networks.
                Cons: Requires intrinsic (crypto)currency, and the ”Nothing at stake” problem.
                Example usage: Nxt

    3) Proof of Elapsed Time
                Wait time in a trusted execution environment randomizes block generation.
                Pros: Efficient.
                Cons: Requires processor extensions.
                Example usage: Hyperledger Sawtooth

    4) Solo / No-ops
               Pros: Quick, and suited to development.
              Cons: No consensus, which can lead to divergent chains

    5) PBFT-based
               Practical Byzantine Fault Tolerance (PBFT) implementations
               Pros: Reasonably efficient and tolerant against malicious peers.
               Cons: Validators are known and connected.

    6) Kafka / Zookeeper
               Ordering service distributes blocks to peers.
               Pros: Efficient and fault-tolerant.
               Cons: Does not guard against malicious activity.

    Consensus tradeoffs: Permissioned versus permissionless

       Permission Lotary based  Permission Voting base  Proff of work (Bitcoin)
     Speed  Good  Good  Poor
     Scalability  Good   Moderate  Good
     Fanality  Moderate  Good  Poor

    Hyperledger frameworks reach consensus by logically separating two activities:
    • Ordering of transactions
    • Validating transactions

    Advantage of logically separating these activities:
    • Any Hyperledger framework can work with any Hyperledger consensus module.
    • Separation of concerns enables better performance and scalability of the network.


    Hyperledger Fabric consensus implementation steps:

    • Simulate transactions.
    • Collect results.
    • Collect endorsements.

    • Order transactions.
    • Create blocks.
    • Broadcast blocks.

    • Validate endorsements.
    • Eliminate invalid transactions.
    • Update the ledger.


    Transaction lifecycle
    1) Client requests endorsement of the proposal
    2) Endorsing peers decide that the proposal is valid.
    3) Endorsers send the proposal response
    4) Client submits the transaction to orderer 
    5) Ordering service creates the block of transactions, and sends it to all the peers in the channel.
    6) Committing peers (all peers in the channel) validate each transaction in the block, and commit the block
    7) Peers emit notifications

    Endorsement policy describes the conditions by which a transaction can be trusted.
    A transaction can be considered valid only if it is endorsed according to its policy.
    Endorsement policies are defined at chaincode instantiation on a specific channel.

    Endorsing peer has Endorsement System Chaincode (ESCC) signs the proposal response (RW sets: set of read and written data) and also include each record’s version number.

    Ordering service perform access control to check whether clients are allowed to broadcast a transaction on the channel

    Ordering service ensuring the following:
    • Agreement: A block is delivered with the same sequence number to all peers.
    • Hash chain integrity: For all peers, the current block contains the hash of the previous one.
    • Sequential Delivery: Each block is delivered sequentially to every peer. No block is skipped or missed.
    • No transaction creation: Blocks are composed only of transactions that are broadcast by clients.
    • Eventual validity: If a client broadcasts a transaction, it eventually is delivered in a block.

    The ordering service is run by specialized nodes that:
    • Do not hold smart contracts.
    • Do not hold endorsement policies.
    • Do not need to store the world state to work.
    • Do not update the ledger by themselves.
    • Can see all transactions by default, but do not need to inspect the details of a transaction.

    Different configuration options for the ordering service include:
    • SOLO: Single node for development
    • Kafka: Crash fault tolerant consensus:
                • Three nodes minimum.
                • Odd number of nodes are preferred.

    Committing peers (including endorsing peers) run validation and update their copy of the blockchain and world state.
    Committing peers may hold smart contracts, but they do not execute them at this stage.
    every committing peer use Validation System Chaincode (VSCC) to :
                • Validates the endorsements against the endorsement policy.
                • Checks that the RW sets are still valid for current world state.

    Validated transactions are applied to the world state and retained on the ledger.
    Invalid transactions are also retained on the ledger, but do not update world state.

    Notify the transaction: The committing peers notify the applications.
    Applications can register to be notified when transactions succeed or fail, and when blocks are added to the ledger.
    Applications are notified by each peer to which they are connected.


  • Hyperledger Fabric application development

    Types of chaincodes:

    1) System chaincodes (SCC) implement the system’s behavior:
    o They run within the peer process.
    o They are bound with the peer’s startup.


    2) User chaincodes implement the smart contract logic:
    o They run in isolated containers.
    o They depend on the peer, but they can be bootstrapped after the peer’s startup.


    Every chaincode program must implement the chaincode interface, which defines the methods that are run during the chaincode’s lifecycle:
    o The Init() method is called in response to an instantiate or upgrade transaction, to perform any necessary initialization of the application state.
    o The Invoke() method is called in response to an invoke transaction proposal or Query() requests.

    Note: ChaincodeStub Interface object is passed as parameter to both Init() and Invoke(), it used to discover information on the request (invoking an identity, target channel, or arguments) and talk with the peer to retrieve or update the application state.


    Bootstrap chaincode

    1) Install the chaincode: chaincode is installed onto the peers that must run it.

    2) Instantiate the chaincode: Peers instantiate the chaincode on the channels on which they want to transact.


    Chaincode deployment approaches:

    1) CLI-based: Easy to use (through peer commands). But this impacts security due to direct interaction with peers to perform actions, and May not be possible in real-life production scenarios.

    2) SDK-based: Places an abstraction layer between the application and the blockchain, but In more complex scenarios, it introduces another debugging layer to be managed.

    3) API-based: Easy to use (through Hyperledger Composer or other platform, for example, IBM Blockchain Platform APIs).  but Less flexibility and control over the chaincode compilation process.


    Developing the client and chaincode

    1) Client SDK: Go, NodeJS, Java, and (Python under development)

    2) Chaincode: Go, NodeJS, and (Java, Solidity under development)


    Chaincode structure

    1) Import declaration 

    2) Shim.start()

    3) Load Chain code interface init(), invoke()

    4) Implement chain code interface 


    NodeJs import fabric-shim module and pass ChaincodeStub object to init and invoke, while

          GO  import shim package and pass ChaincodeStubInterface object to init and invoke.




    Chaincode implementation:

    All transactions are processed through the Invoke() or Init() methods:

    shim provides the interface methods to handle
    1) transaction input: GetArgs(), GetStringArgs(), GetFunctionAndParameters()

    2) transaction context: (Who invoked the transaction, when, and on which channel) GetTxID(), GetCreator(), GetTxTimestamp(), GetChannelID(), SetEvent()

    3) Handling data: getState(), putState(), delState(), getHistoryForKey(), GetQueryResult()
         PutState() requires [] byte as the argument. so, we may using json.Marshal() to convert json variable into byte array.


    world state save values as a byte array, Data models eventually must be converted into a JSON string.

    CouchDB need indexes to perform json queries with sort


    Query System Chaincode QSCC: provides convenient APIs to retrieve information about the blockchain

    • GetChainInfo: retrieves blockchain Height, currentBlockHash, and previousBlockHash
    • GetBlockByNumber
    • GetBlockByHash
    • GetTransactionByID


    Implementing Query():

    – Level DB: GetState, GetStateByRange, GetStateByPartialCompositeKey

    – Couch DB: same as Level DB + getQueryResult


    – When Instantiate the chaincode on the channel from the CLI we can pass – c ‘{“Args”:[]}’
       it specifies an array of arguments that you want to pass to the Init function in your chaincode.
    – The chaincode container is automatically created by the Hyperledger Fabric peer every time you upgrade or instantiate chaincode.
       the containser name standard is “dev-” + PeerName + CodeName + CodeVersion
    – When install the same code again after modify it, we should change the version number
    – Install and upgrade chaincode needs code name -n and code version number -v
    – When install chaincode online on IBM Blockchain Platform, it give use “connection profiles” 
       connection profile includes all the information required by a blockchain user application to connect to peers, orderers, and certificate authority nodes.
    – To connect and interact with the Hyperledger Fabric network use utilities such as Fabric SDK or Hyperledger Composer. 
    – the first method run on GO script is main[] 
    – To indicate success start Init() by return
               GO: return shim.Success(nil)
               Node return shim.success();

    – To print to console write
              Go: fmt.Println(“Greetings from the Init function!”)
              Node:‘Greetings from JavaScript Init!’);

    /*Sample Go script*/

    package main
    import (“
    sc “””)
    type SmartContract struct { }

    type Vehicle struct {
    ModelType string `json:”modelType”`
    Colour string `json:”colour”`

    func (s *SmartContract) Init(APIstub shim.ChaincodeStubInterface) sc.Response {
    return shim.Success(nil)

    func (s *SmartContract) Invoke(APIstub shim.ChaincodeStubInterface) sc.Response {
    function, args := APIstub.GetFunctionAndParameters()
    if function == “queryVehicle” {
    return s.queryVehicle(APIstub, args)
    } else if function == “initLedger” {
    return s.initLedger(APIstub)
    } else if function == “recordVehicle” {
    return s.recordVehicle(APIstub, args)
    } else if function == “changeVehicleOwner” {
    return s.changeVehicleOwner(APIstub, args)
    return shim.Error(“Invalid Smart Contract function Call “)

    func main() {
    err := shim.Start(new(SmartContract))
    if err != nil {
    fmt.Printf(“Error creating Smart Contract: %s”, err)


    /*Sample Node JS */

    const shim = require (‘fabric-shim’); // This is Fabric shim interface for nodejs
    var chaincode = class {

    Init(stub) {
    return shim.success(); // Indicates the success of the init of the chaincode

    Invoke(stub) {
    let functionAndParams = stub.getFunctionAndParameters();
    let fcn = functionAndParams.fcn;
    let params = functionAndParams.params;
    var vehicle ={};
    switch (fcn) {
    case “recordVehicle”:
    case “changeVehicleOwner”:
    return shim.error(“Specify correct invocation method”);

    shim.start(new chaincode());



  • Blockchain deployment options

    Deployment scenarios: 
    1) Docker host
    2) Kubernetes cluster
    3) SaaS

    Optional deployment components
    1) Fabric-CA
    2) CouchDB
    3) Hardware Security Module

    How to setup development environment?
    Prerequisites: Git, Node, Go, Docker, Docker composer
    Install: HyperLedger composer CLI, ComposerPlayGround, VS IDE, Install DockerImages, install HyberLedgerFabric 


    Deployment configuration files 
    1) crypto-config.yaml : Organization-specific certificate structure for peers, orderers, and users (excluding Fabric-CA)
                                      contains network topology, define “who-is-who” in the Fabric network
                                      OrdererOrgs and PeerOrgs sections define (name, domain, hostname)
                                      Peer Admin Certificate:
                                      – “Template” section, “Count” under it indicates how many certificates must be generated for the peers in the network.
                                         It will match the number of peers. Each peer has its own certificate.
                                      Network Admin Certificate:
                                       – “Users” section, “Count” under it specify the number of user certificates to be generated in addition to the Admin certificate.
                                         Alternatively, you can ignore the user certificates in this configuration file and instead run fabric-ca,
                                         which is a different container to issue certificates dynamically.

                                      – All peers in the same organization can discover each other automatically, exchange data, and synchronize automatically.
                                        The certificate defines the identity. It indicates to the peer and the orderer the organization to which they belong.
    2) configtx.yaml : Hyperledger Fabric initial instance, blockchain, channel, and anchor peer configuration
                              (define anchor peers address, orderers type and address and MaxMessageCount,BatchSize, MSPDir points to certification location)
    3) Docker-compose or Kubernetes configuration file : Container deployment and environmental variable configuration


    Pre-launch operations
    1) cryptogen: Generate certificates based on configuration in cryptoconfig.yaml 
    2) configtxgen: use configtx.yaml and Generate
                           a) genesis.block : it is the first block in the blockchain.
                               It is used to bootstrap the ordering service and holds the channel configuration.
                               A genesis block is the configuration block that initializes a blockchain network or channel.
                               The genesis block usually contains an arbitrary key value that is used to initialize the hash function.
                           b) channel.tx: Use to create the channel (ledger) and the mechanism that enables peers join business networks.
                           c) anchorPeer.tx: specify each organization’s anchor peer on this channel

    cryptogen generate –config=./crypto-config.yaml
    configtxgen -outputBlock ./genesis.block -profile TwoOrgsOrdererGenesis 
    configtxgen -outputCreateChannelTx ./channel.tx -channelID mychannel -profile TwoOrgsChannel 
    configtxgen -outputAnchorPeersUpdate ./anchorsP.tx -channelID mychannel -asOrg Org1MSP -profile TwoOrgsChannel 

    Network deployment
    1) Start a Docker-based network with peer, orderer, CAs, and CLI containers.
         – Inject Certificate to peers, Orderers, and CA
         – Inject genesis.block to peers, and Orderers

    2) use CLI Container to:
    • Creates a channel, joins orderers, and peers using channel.tx 
       (Create channel on the orderer node,command will create .block file, take the result block and deploy on peers to join this channel)
    • Updates the anchor peers with configuration updates using anchorPeer.tx
    • Install code on each peer and start it once on Orderer peer with the enrose policy
     – the next 3 commands (channel create/channel update/chaincode instantiate) need -o parameter to defind orderer location
     – peer chaincode install by degault run Go script and to run node script pass (-l node) as parameter
     – peer chaincode instantiate use -c parameter to pass parameter to Init() function

    peer channel create -o -c mychannel -f ./channel.tx –tls –cafile ./ORDERER_ca.-cert.pem
    peer channel join -b mychannel.block
    peer channel update -o -c mychannel -f ./anchorsP.tx –tls –cafile ./ORDERER_ca.-cert.pem //Install code on each peer and start it once on Orderer peer with the enrose policy
    peer chaincode install -n chaincode -v V1 -p Path2ChainCode
    peer chaincode instantiate -o -C mychannel -n chaincode
    -v V1 -c ‘{“Args”:[]}’ -P “OR(‘Org1MSP.member’)”

    Job Roles catagories in BlockChain

    1) Network Services: fouce on Peers, channels, ordering service

    2) Business Services: focus on Smart contracts and the APIs that invoke them


    Blockchain participant roles

    1) Network Service Provider (Infrastracture Team) : 

                           o covers changes to the network
                           o consortium of network members or designated authority.
                           o Initiating the network.
                           o Creating membership, channel, and smart contract policies.

    2) Network Service Consumer (Peer Support Team): 
                           o Common recurring tasks (for example, certificate management)
                           o represents an organization on the business network
                           o Installing and instantiating smart contracts
                           o Managing certificates for Business Service Consumers in their organization
                           o Monitoring network resources
                           o Creating channels (in accordance with defined policies)
                           o has Full access to APIs and logs for transparent problem determination

    3) Business Service Provider (Developer) :
                          o develop Smart contracts
                          o develop Business logic (Business applications and integration services)
                          o develop Presentation logic (Client applications)

    4) Business Service Consumer (Customer IT) : 
                          o Hosting business logic that invokes smart contracts
                          o Managing the user identity, Users authenticate to invoke transactions by using a proxy identity that is provided by the Network Service Consumer’s certificate authority.



    BlockChain network has 3 layers: Presentation Layer, Business Application Layer, and Data Layer.
    – Normal system user talk to “presentation layer” that consume “Business Application layer”.
    – Business Service Consumer response on “Business application layer” (APIs)
    – Network Service Provider, Network Service Consumer, and Business Service Provider all focus on “Data layer”






  • blockchain security

    Security when register new user in Hyperledger Fabric
    1) Admin use CA client to connect to Fabric-CA and register new user 
    2) Admin Send enrollment ID and Password to the user 
    3) User use Client SDK to connect to Fabric-CA and send enrollment ID and Password to get his certificate 

    Security when submit transaction
    1) User sign transation perposal and send to peers using client SDK
    2) Peers validate client signature before simulate transaction
    3) Peer sign response and send back to client
    4) Client validate endrosed signature before send accepted transaction after sign it to Orderer.
    5) Orderer validate client signature before sign transation and send to all peers
    6) peers validate transaction signature before validate transaction and commit it

    Send Private data collections (PDC) Lifecycle
    1) Propose the transaction
    2) Endorsing the peer simulates the transaction and distributes data based on policy
    3) The proposal response is sent back to the client
    4) Client Send reponse to Orderer, privte data send as hashed
    5) Order send to All peers to commit 
    6) The peers validate the transactions. The private data is validated against the hashes. private data does not go through orderer, instead pull from peers directlly.
    7) Commit data:
                          a) Commit private data to the private state DB.
                          b) Commit hashes to the public state DB.
                          c) Commit the public block and private write set storage.
                          d) Delete the transient data.


    Application-level encryption (data in-transit, data at rest)

    1) Client encrypt transaction before submit it
    2) ChainCode decrypt transaction and validate it 
    3) ChainCode encrypt data at rest by encrypt WorldState data and Transaction Blocks data

    How Hyperledger Fabric Secure (Identities, Consensus, Data in transit, and Data at rest)?
    1) Identities: By MSP, certificate authority, and Enrollment
    2) Consensus: by sign Endorse/Order/Validate, and Transaction
    3) Data in transit: Application-level encryption
    4) Data at rest: Application-level encryption, channels, and private data.

    How Hyperledger Composer Secure (Identities, Access for transaction, and Data in transit)?
    1) Identity: ID and business network cards
    2) Access for transaction: Access control lists and REST Server OAuth 2.0 support
    3) Data in transit: REST Server HTTPS/TLS support

    How IBM Blockchain Platform Secure?
    Identities : Hardware security module
    Infrastructure : Secure services containers (No root access)
    Data at rest : Encrypted storage

    How security works summary

       Fabric  Composer Application  IBM Cloud
     Identity  MSP, certificate authority, and Enrollment  ID and
    business network cards
      Hardware security module
     Data in transit  Application-level encryption  REST Server HTTPS/TLS support  Encrypt transaction  
     Data at rest  Application-level encryption, channels, and private data.    Encrypt transaction block and world state data Encrypted storage
     Infrastructure        Secure services containers
    (No root access)
     Consensus  Sign Endorse/Order/Validate, and Transaction      
     Access for transaction    Access control lists and REST Server OAuth 2.0 support    


    Hyperledger Composer Business network cards contains: 
    1) Identity
    2) Connection profile
    3) Metadata


    Types of Certificates 

    1) admincerts: admin certificates used to administrate the peer (installing/instantiating chaincode, creating channels, etc)
    2) cacerts: Each organization has unique root certificate that binds specific components (peers and orderers) to that organization.
    3) Keystore: private key, used to Sign communication
    4) signcert: public key, used to verify signature
    5) CRLs: List of revoked admin certificates



    the command “peer chaincode invoke” has transient parameter, 
    The transient parameter is the technique that is used to pass confidential data to the chaincode.
    The key that is provided by following this approach is not recorded in the blockchain transaction log or in the world state database.

    -transient “{”ENCKEY”:”${MYKEY}”}” indicates a transient map of arguments in the form of JSON encoding.

    – when need to encrypt data with encryption key pass in transient parameter , The data passed to the chaincode in clear text; the encryption is performed inside the chaincode function

    – encryption key should be base64 with 32 bytes length, we can generate random one by run the command “openssl rand 32 -base64”

    When query data from the ledger, no need to go through orderer, because the query does not create a blockchain transaction.

  • Blockchain integrated

    Key components of the Hyperledger Fabric architecture

    Applications can interface with peer nodes through Hyperledger Fabric Client SDK
    “Composer REST Server” needs “Hyberledger composer SDK” which base on Hyperledger Fabric Client SDK

    Hyperledger Fabric SDK provides APIs to interact with a Hyperledger Fabric blockchain.
    The fabric-client package encapsulates the APIs to interact with Peers and Orderers of the Fabric network to install and instantiate chaincodes, send transaction
    invocations, and perform chaincode queries.

    Fabric Client SDK available for Node.js and Java.

    Blockchain can calls external systems.

    Events Integrating with existing systems: 
    1) Blockchain publishes events. An external system subscribes to events and triggers transactions.
    2) An external system publishes events, which trigger blockchain transactions.

    Use Transformation and Connectivity component for Enterprise integration and Data transformation

    Transformation and Connectivity: Integration Hub
    Integration Hub provides the following features:
    • Protocol transformation before REST endpoint invocation.
    • Support for integration patterns (event-based and message-based).
    • Data transformation between blockchain and existing systems’ formats using (approaches):
       1) Generic Business Object (GBO)
       2) Application-Specific Business Object (ASBO)

    IBM App Connect Enterprise contains a LoopBack connector.

    Integration Hub appliance

    API Management technologies, such as IBM API Connect, are used to:
    o Apply policies and management to APIs.
    o Ensure API security through authentication and authorization.
    o Enforce traffic management, and mediation policies at run time.
    • The API manager receives the request, determines which services or applications in the applications server to invoke, and determines whether the user has the appropriate authority.

    Interaction API Management
    1) API discovery/documentation Used by blockchain developers to find and use smart contract APIs securely.
    2) API management Provides a management view into smart contract API usage by user and enterprise applications.


    Blockchain and data storage: On-chain or off-chain, use off-chain if the size of document is very big to avoid impact performance otherwise use on-chain


  • Hyperledger Commands

    Hyperledger Composer 

    Open the local Hyperledger Composer Playground on localhost:8080.


    Hyperledger Composer CLI

    composer –help

    Install BusinessNetwork1.bna using admin peer card “PeerAdmin@Channel1”.

    composer network install –card PeerAdmin@Channel1 –archiveFile ./BusinessNetwork1.bna

    Start BusinessNetwork1 after install it, start process will create new network admin certificate to manage the network with name “networkadmin.card”

    composer network start –networkName BusinessNetwork1
    –networkVersion v1 –networkAdmin admin
    –networkAdminEnrollSecret adminpw –card PeerAdmin@Channel1
    –file ./networkadmin.card
    -o endorsementPolicyFile=./endorsement-policy.json

    View the current cards install on the system.

    composer card list

    Install network admin card “networkadmin.card”

    composer card import –file ./networkadmin.cart

    Load Hyperledger Composer REST API (it is a LoopBack stand-alone Node.js project), start REST API at http://localhost:3000/explorer


    Remove PeerAdmin@hlfv1 card 

    composer card delete –card PeerAdmin@hlfv1

    register new admin2 user, this command will generate a one time use password to enroll this new user

    fabric-ca-client register – admin2 –id.affiliation org1.department1 –id.attrs ‘hf.Revoker=true,admin=true:ecert’

    enroll new admin2 user 

    fabric-ca-client enroll -u http://admin2:<>@localhost:7054

    Update the business network that is running (user must restart Hyperledger Composer REST server after upgrade)

    composer network upgrade -n vehicle-manufacture-network -V 0.2.5 -c PeerAdmin@hlfv1

    Ping blockchain network

    composer network ping –card PeerAdmin@hlfv1




    Hyperledger Fabric

    Create new blockchain network and generate “Peer admin certificates” and “Network admin certificate” 

    cryptogen generate –config=./crypto-config.yaml

    Create the orderer genesis block

    configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./genesis.block

    Create the channel configuration transaction

    configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel.tx -channelID mychannel

    Define anchor peers for each organization

    configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./anchorsP.tx -channelID mychannel -asOrg Org1MSP

    Decode the genesis block into readable format

    configtxlator proto_decode –type=common.Block

    Create channel, This command targets the orderer (where the channels must be created), will create “mychannel.block”

    peer channel create -o -c mychannel -f ./channel.tx –tls –cafile ./ORDERER_ca.-cert.pem

    peer channel create command returns a genesis block that will be used to join the channel.

    peer channel join -b mychannel.block

    List the channels that the peer is subscribing to

    peer channel list

    Establish peer as an anchor peer

    peer channel update -o -c mychannel -f ./anchorsP.tx –tls –cafile ./ORDERER_ca.-cert.pem

    Sign file will peer certificate

    peer channel signconfigtx -f file.pb

    Request genesis block and save it to file mychannel.block

    peer channel fetch 0 mychannel.block -o -c mychannel –tls –cafile ./ORDERER_ca.-cert.pem

    Install chaincode in the peer

    peer chaincode install -n chaincode -v V1 -p Path2ChainCode -l node

    Instantiate the chaincode on the channel

    peer chaincode instantiate -o -C mychannel -n chaincode
    -v V1 -c ‘{“Args”:[]}’ -P “OR(‘Org1MSP.member’)”

    Invoke request to peer0 to create a car in the ledger (status:200 is the commands success message)

    peer chaincode invoke -o -C mychannel -n chaincode
    -c ‘{“Args”:[“recordVehicle”, “2”, “next car”, “Blue”, “1504054226”, “Europe”, “Robert”]}’

    Read the data that is associated with vehicle ID “2”

    peer chaincode query -C mychannel -n chaincode -c ‘{“Args”:[“queryVehicle”,”2″]}’

    Update chain code after install it first to all peers

    peer chaincode upgrade -o -C mychannel -n chaincode
    -v V2 -c ‘{“Args”:[]}’ -P “OR(‘Org1MSP.member’)”


  • Docker commands

    View current running dockers

    docker ps -a

    remove current running dockers

    docker rm -f $(docker ps -aq)

    Clear any residuals left in the system

    docker system prune -f


  • Example of Hyper Ledger Composer project (.bna file)

    User can update the next files then create new .bna project by run “npm run prepublish”
    .cto file (define: participant, asset, transaction, event)
           the file can contains one namesapace only, but can import info from other namesapces

    namespace org.acme.vehicle_network

    participant Person identified by username {
    o String username
    o String email optional

    asset Vehicle identified by vin {
    o String vin
    o String trim
    o String interior
    o String[] extras
    –> Manufacturer make
    o String modelType
    o String colour
    o Integer yearOfManufacture default = 2018 range = [2018, ]

    transaction PlaceOrder {
    o Order order

    event UpdateOrderStatusEvent {
    o OrderStatus orderStatus
    o Order order

     .acl file

    rule PersonPlaceOrder {
    description: “Allow Persons to place orders and view they’ve done this”
    participant(p): “org.acme.vehicle_network.Person”
    operation: CREATE, READ
    resource(o): “org.acme.vehicle_network.PlaceOrder”
    condition: (o.orderer.getIdentifier() == p.getIdentifier())
    action: ALLOW


    .js file



    query selectPlacedOrders {
    description: “Select all placed orders”
    SELECT org.acme.vehicle_network.Order
    WHERE (orderStatus == “PLACED”)



  • Commands Summary

    Composer network (install – start – upgrade – ping)
                     card      (list – import – delete)

    fabric-ca-client (register – enroll)

    cryptogen generate

    configtxgn -output (block – CreateChannelTx – AnchorPeersUpdate)

    Peer channel     (create – join – update – list – fetch – SignConfigTx)
            chaincode (install – instantiate – upgrade – invoke – query)


  • Course abbreviation

    certificate signing request (CSR)

    Memebership service provider (MSP)

    Endrose system chaincode (ESCC)

    Validate system chaincode (VSCC)

    Query system chaincode (QSCC)

    Private data collections (PDC)

    Generic Business Object (GBO)

    Application-Specific Business Object (ASBO)


  • Leave a Comment

    Your email address will not be published. Required fields are marked *