Hyperledger Fabric v1.0 to Bring Improved Transactions and a Pluggable Data Store

Scheduled for March 2017, Hyperledger Fabric v1.0 is supposed to eliminate the existing confidentiality constraints, introduce a pluggable data store, and boost scalability. The next-generation consensus protocol is under consideration, too.

Previously, we have written about the changes to be introduced in release v1.0 and explored transactional privacy within Hyperledger Fabric v0.6.

At a recent meetup, IBM’s Solutions Architect Anthony O’Dowd and VP Global Blockchain John McLean provided a detailed overview of what Hyperledger Fabric v1.0 release brings to the table and how it differs from the current version.

Hyperledger Fabric v1 crowd


Issues to address in Hyperledger Fabric v0.6

Talking about today’s Hyperledger Fabric v0.6, Anthony enumerated some of the constraints:

  • In a PBFT blockchain network, a smart contract is run on all validating nodes.
  • If there is a large number of peers with update transactions being submitted, the network may not scale well.


He provided an example of a network built around Driver and Vehicle Licensing Agency (DVLA) in the UK. The thing is that with PBFT, DVLA, all the manufactures, and all the leasing companies have to process every update transaction if they run their own validating nodes.

Hyperledger Fabric v1 Fiat 1

However, the manufactures and leasing companies may not want their competitors to see details of the transactions made for, as Anthony highlighted, such information (e.g., evidence of discount rates) can be used against the manufacturer. Data encryption may appear as a way out, still majority of businesses would better not execute transactions on competitors’ nodes.

“Earlier (alpha and beta) versions 0.5 and 0.6 present a very democratic network. Everyone sees a copy of the ledger and transaction committers get to see the smart contracts.”
—Anthony O’Dowd, IBM

Hyperledger Fabric v1 Fiat 2Fiat only wants certain parties in the blockchain network to have access to its promo activity.

According to Anthony, this entailed the need “to move from a very homogeneous environment to one in which it’s defined who can see and do what.” Thus, there should be built “a much more sophisticated network, if you will. Only a certain set of endorser nodes actually hold the state (of a particular transaction). Certain nodes validate certain transactions, just like in the real world. Consensus nodes then finish the transactions.”


Changes to introduce in Fabric v1.0

Drawing the conclusions from that example, the developers of Hyperledger Fabric came up with a list of changes to be implemented in a v1.0 release:

  • Enable support for broader confidentiality
  • Scale the number of participants and transaction throughput
  • Eliminate non-deterministic transactions
  • Enable pluggable data store
  • Be able to dynamically upgrade fabric and the chaincode
  • Remove SPF and enable multiple providers of Membership Services


Anthony added that “there are also channels, a bit like a sub-ledgering idea. You can operate on, say, a ‘blue’ one and a ‘red’ one, in which the traffic and the data can be isolated.”

Meanwhile, as an intermediate deliverable a beta driver of v1.0 is to released on January 31.


A sample transaction in Fabric v1.0

Anthony then walked attendees through a typical transaction in the upcoming v1.0 environment.

Phase 1. In the first part of the transaction, a client app proposes a transaction for Smart Contract A to the endorsing peer E0. There is an endorsement policy that needs only E0, E1, and E2 to sign. The other peers are not part of this policy. Note how red and blue sub-ledgers are also present in this example.

Hyperledger Fabric v1 Smart Contract 1

Phase 2. Peer E0 then endorses the transaction, and optionally anchors it with respect to the ledger state version numbers. An anchor contains all the data read and written by the contract that is to be confirmed by other endorsers.

Hyperledger Fabric v1 Smart Contract 2

Phase 3. The client then requests further endorsement from E1 and E2. The client may decide to suggest an anchor obtained from E0 to E1 and E2.

Hyperledger Fabric v1 Smart Contract 3

Phase 4. The endorsing peers E1 and E2 send the endorsement to the client.

Hyperledger Fabric v1 Smart Contract 4

Phase 5. The client formats the transaction and broadcasts it to the consensus-service nodes for inclusion in the ledger.

Hyperledger Fabric v1 Smart Contract 5

Phase 6. The consensus service delivers the next block in the ledger with the consented transaction. E4 and E5 are not on the same channel and therefore do not receive an update.

Hyperledger Fabric v1 Smart Contract 6

“The consent network is just involved in ordering transactions. It’s just a technical function, and does not execute smart contracts. It just orders the data.” —Anthony O’Dowd, IBM

Phase 7. The peers then validate the block received from the consensus service and update their ledger and world state.

Hyperledger Fabric v1 Smart Contract 7

Enabling pluggable world state

In the current Hyperledger Fabric v0.6, smart contracts store data in the blockchain using a key-value store with data managed and persisted by an open-source RocksDB. The underlying persistence store is hidden from a developer by the chaincode APIs: GetState() and PutState(). At the moment, a world state is quite restrictive as Anthony gave an example of a limited capability to run complex queries against the stored data.

So, as he outlined when speaking about the changes to come, the underlying storage (world state) should be made pluggable, which would enable Ops to choose the implementation to use. The v1.0 will use Apache CouchDB.

Hyperledger Fabric Pluggable World State v2

Noting that Hyperledger Fabric is not focused on real-time transactions, Anthony nevertheless pointed out that scalability will be increased by limiting the number of parties, which have access to each transaction.

He said the community is looking at volumes of “the high hundreds of transactions per second, but it’s tough to say” because earlier versions are still fully distributed. In any case, upon the v1.0 release, “integrated volume will depend on how many nodes you have,” while noting that the n-squared issue is present in any system as nodes increase.


Focus on transaction and identity privacy

On demonstrating how private ledger access is to work, Anthony scrutinized the three backbones of the transaction and identity privacy:

  1. Transaction certificates (TCerts)
    • disposable certificates, typically used once, requested from Transaction CA
    • A TCert is derived from a long-term identity—an enrollment certificate (ECert)
    • Only Transaction CA can link ECert and TCert
  2. Permissioned interactions
    • A consumer shares a public TCert with a provider
    • A provider invokes chaincode transactions as usual, but signs with the provider’s private TCert for authentication and encrypts with provider and consumer TCerts for subsequent access
    • Consumers can subsequently access ledger data using a private key
  3. Secure chaincode
    • Chaincode can also be signed and encrypted to verify and secure contract details
    • Signing is by a contract owner/author
    • Encryption ensures only validators can see and execute transaction chaincode



Next-generation consensus protocol

At the final part of his session, Anthony touched upon the proposed Hyperledger next-generation consensus protocol. Major changes might encompass validation roles and introduction of endorsement policies and channels. Thus, a validation role might be split into two independent roles:

  • Endorsement. On “signing” the contract, users endorse a transaction to verify that its content obeys a given smart contract.
  • Consensus. It will be responsible for consenting the inclusion of a verified transaction in the ledger. So, consensus controls the processes within a ledger, making sure that it is consistent.

The roles of the nodes in the proposed protocol would be as following:

  • Peer: Commits transactions, maintains a ledger and a state.
  • Endorsing peer: It embodies a specialized role of a peer that receives a transaction proposal for endorsement, granting or denying it.
  • Consensus-Service: Approves the inclusion of transaction blocks into a ledger and communicates with a peer and endorsing peer nodes.

The endorsement policies are to identify the conditions by which a transaction can be endorsed, thus determining whether a transaction is valid or not. So, a set of such policies would be maintained at a peer level and specified on deployment of the chaincode.

As long as peer broadcast and receive messages from the consensus service via channels, Anthony concluded with the details of a channel workflow, noting that it enables partitioning of confidentiality:

  • Messages can be partitioned into separate channels.
  • Nodes can connect to one or more channels, while channels themselves don’t have to be connected by all nodes.
  • Peers can be connected to a channel via an access control policy.
  • The consensus service orders the transactions broadcast to a channel.
  • All peers receive transactions in exactly the same order for a channel.
  • Transactions are delivered in cryptographically linked blocks.
  • Each peer validates the delivered blocks and commits them to the ledger.


Contributors are welcome

In providing an introduction to Anthony’s presentation, John said IBM’s interest in open-source blockchain builds upon its work within the Cloud Foundry and Node.js communities, and that “the best ideas, concepts, design, technical requirements, and input across topic areas come within open-source projects.”

Hyperledger Fabric v1 John McLean v2

John also noted that 40% of IBM’s current blockchain clients are not in financial services and that he expects these clients to move more quickly “because of lower regulatory control hurdles” facing them.

There are now more than 100 members of the Hyperledger Project, which was launched in December 2015. John and Anthony urged people to listen in on the weekly Technical Steering Committee (TSC) calls, and also participate further.


Want details? Watch the video!

Table of contents

  1. The updated roadmap for the Hyperledger Fabric v1.0 (3’50”)
  2. Hyperledger Fabric v1.0 architecture (9’15”)
  3. How will transactions work in Hyperledger Fabric V1.0? (10’05”)
  4. What is the world state of blockchain with Hyperledger Fabric v0.6? (19’00”)
  5. How will the world state of blockchain change with Hyperledger Fabric v1.0? (20’15”)
  6. What is next for Hyperledger Fabric v1.0? (23’45”)



Related slides


Related reading

About the speakers

John McLean, VP Global Blockchain Labs Engagement, IBM bio
John McLean is VP Global Blockchain Labs Engagement and Federal Europe Cloud at IBM. He is a software development executive of 30 years industry experience, having a proven track record of project delivery and execution, with leadership knowledge of large technology organizations, technology trends, and innovation agendas. At IBM, John is responsible for Client Engagement for Blockchain worldwide, explaining IBM strategy and POV, engagement with customer to help clients define use cases and solutions across all industries with the blockchain technology.


Anthony O'Dowd, Solution Architect, Blockchain Technologies, IBM bio
Anthony O’Dowd is a Solution Architect, Blockchain Technologies at IBM. He is helping clients with solution architecture and application design for decentralized ledger systems. Anthony has hands-on design experience with Linux Foundation Open Ledger project and other open-source blockchain technologies.

This post was written by Roger Strukhoff and Sophie Turol with assisstance from Carlo Gutierrez and Alex Khizhnyak.