Unpacking HyperLedger Fabric 1.0 – Under the hood of a Permissioned Blockchain

It’s been a while I had been following the “HyperLedger” project initiatives under Linux foundation –  it is growing faster than I thought (Not sure, when Oracle will join HyperLedger..probably they are annoyed by HyperLedger use of RockDB, CouchDB)! I attempted to test drive HyperLedger 0.6 before — it didn’t get me anywhere with too many dependencies.  That said, a couple of months ago Linux Foundation released HyperLedger Fabric 1.0,  quite promising as it claims to be a  blockchain platform for deploying private Permissioned Blockchain.

Unlike Bitcoin and Ethereum based blockchain network which allows unknown and anonymous entities collaborate and trust each other on transactions using a “Proof-of-work” based consensus protocol,  whereas HyperLedger Fabric 1.0 allows to establish and deploy a “Trusted Members only” blockchain which means everyone knows each other and their identities. This makes it so compelling to be used within a group of legal entities or consortium of organizations using a well-established Identity management or Federated Identities over trusted networks. More importantly, HyperLedger does not support a CryptoCurrency. Certainly, it makes a great case for HyperLeger Fabric 1.0 deploying Private and Permissioned Blockchain which significantly reduces the risks of privacy and confidentiality breaches in sharing information and trusted business process collaboration without intermediaries.

HyperLedger Fabric 1.0

If we unpack and deploy HyperLedger Fabric 1,0 and it’s components, we will find the following core components :

  1.  Membership Service Provider (MSP) –  It provides the Identity management service (for establishing a member-only permissioned blockchain) that allows enrollment of members and establishes rules and access control lists (authorization of access rights and privileges). It makes use of its own PKI provider (Certificate Authority – CA) to issuing Public/Private keypairs (ECDSA) and associated X.509 certificates that can be used to identify peer nodes, Orderer (Ordering services), and for all enrolled members. It provides all required cryptographic mechanisms and CA services intended for issuing, validating, managing and till revoking certificates and validating digital signatures (cryptogen). Each participating organization peers or member can have its own MSP on a HyperLedger fabric network.
  2. Chaincode (Smart Contracts) – It holds state and ledger data by managing the lifecycle of transactions representing the business logic, rules, and policies executed within a transaction as agreed to by the participating members of a HyperLedger Fabric network. Chaincode defines endorsement policy and instantiates them and assign which peers need to endorse the transactions.  It also initializes and manages the Shared Ledgers through transactions. In HyperLedger Fabric 1.0, the Chaincode submitted by applications runs in a separate Docker container. The Chaincode can be created using APIs like Go, Node.js and Java (in the future — according to spec).           
  3. Peers – They are nodes that maintain the state and copy of a shared ledger.  Peers are authenticated by certificates issued by MSP. In HyperLedger Fabric, there are three types of peer nodes depending upon the assigned roles:
    • Endorsing Peers (Endorsers) – The endorsing peers take up the role of endorsing transactions before it is ordered and committed as per the policy defined in Chaincode. The client application creating the transaction and sends it to endorsing peers as per the policy in chaincode.  The endorsement policy is instantiated at the chaincode of the client application and forwarded to the endorsing peers. The endorsing peer evaluates and validates the transaction and produces an endorsement signature and then returns it to the application. There may be one or more pre-specified set of endorsing peers involved as per the endorsement policy. The transaction is evaluated and declared valid only if it has been endorsed by the endorsing peers as per policy.
    • Ordering Service Nodes (Orderers) – All transactions from the network are received by the orderer and it orders and groups them and then packages the transactions and creates blocks. The orderer service delivers blocks to the committing peers allowed to be part of a Channel. The orderer services do not review transaction information. The orderer makes guaranteed atomic delivery of blocks to committing peers on the channel. The orderer supports multiple channels using a publish/subscribe messaging system (based on Apache Kafka and Zookeeper). The ordered provides a practical Byzantine Fault tolerance for failures without a single-point of failure.
    • Committing Peers (Committers) – They receive blocks from Orderer service, which already endorsed by the endorsing peers. The Committing peers ultimately commit the transactional state by adding the blocks to the ledger. Before commital, the peers validate or invalidate the transaction by verifying if the endorsement policies are met, authenticate the signatures and also verify the version info (if there is any double spending).
  4. Channels – To ensure private and confidential communication between privileged member nodes, HyperLedger Fabric uses the notion of “Channel” specific to members and their shared ledger. In simpler terms, each channel corresponds to a shared ledger and intended executing a transaction on the network between peers using that ledger. Channels help to partition the fabric exchange confidential private transactions with the isolation of traffic between members and establish data privacy by separation of ledgers per channel.  The separation of the ledger by defining the specific channel for each ledger and peer node memberships are defined in Chaincode configuration (configtx). It is stored in the Genesis block of the ledger, which also stores the members, policies, and anchor peers.  The Genesis block defines the read/write access on a channel. Realistically, this is accomplished by Kafka as each channel maps to Kafka topic.
  5. Shared Ledger  –  The ledger maintains an append-only, tamper-proof sequential system of record and log of all transactions and successful/unsuccessful state changes from the beginning as “cryptographic hash-linked blocks” submitted by all peer nodes in the Hyperledger fabric network. All transaction results are committed to the ledger as a set of Key/Value pairs. The ledger stores all key/values included in the transactions specific to the channel – It is also referred to as World State Database.  HyperLedger fabric by default configures a LevelDB in all peers as Key/Value pair database, however, users can use CouchDB.
  6. Gossip Network Protocol –  The Gossip protocol is being used for “data dissemination” and to manage discovery and identification of peers, relaying new block information and synchronizing the state of ledger information to all participating peers.  As the data being sent are signed and verified at the receipt, there is no chance for spreading messages from unauthorized members.

HyperLedger Transaction Flow:

Assuming the HyperLedger Fabric 1.0 up and running, in a typical transaction flow of asset exchange:

  1. All application users and peer node members are registered in the MSP and issued with Keys/certificates from the CA for authenticating the network.  The Chaincode representing the initial state is installed on the peers and the channels are active.
  2. The application client initiates a transaction (Client A makes a request to Client B to transfer an asset). The endorsement policy states that the request must be endorsed by Peer A and Peer B.
  3. The application submits a transaction proposal to the endorsing peers A and B.
  4. The endorsing peers receive and verify the transaction proposal and its signature, then executes the transaction and return a signed proposal response back to the application client.
  5. The application client verifies the responses from the endorsing peers. It assembles the response into a transaction and sends it to the Orderer service.
  6. The Orderer services order the transactions chronologically and package those transactions as blocks specific to a channel.
  7. The Orderer service delivers the blocks of the transactions to all the peers on the channel.
  8. The peers perform the validation of the blocks for endorsement policy, signatures verification and version info,  and finally appends the block to the chain and commit the state database – Notifies the application client.

Data Protection & Crypto Key security?

Just wanted to share a known risk:

  • HyperLedger Fabric certainly assures data privacy by providing support for segregation of channels between nodes based chaincode and ledgers and data confidentiality/integrity during transit using TLS 1.2 protocol.  However, there is no assurance for data protection at rest and security of cryptographic material, particularly private keys.  Users may choose to use File system encryption options like dm-crypt (Linux) or Bitlocker (Windows) and using PKCS#11 integrating Hardware security modules (HSMs) in each peer for securing private keys.

I will post the cheatsheet of detailed steps for putting together a HyperLedger Fabric 1.0 setup for testing purposes…  Stay tuned.  Indeed,  HyperLedger Fabric 1.0 is promising.  I also noticed, HyperLedger Fabric 1.0 has an optional HyperLedger Fabric CA — Which I am yet to review, that potentially give an option for integrating HSMs.

References:

https://hyperledger-fabric.readthedocs.io/en/latest/

Leave a Reply

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