Hyperledger Fabric v1.0 to Bring Improved Transactions and a Pluggable Data Store
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.
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.
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
Fiat 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.
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.
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.
Phase 4. The endorsing peers E1 and E2 send the endorsement to the client.
Phase 5. The client formats the transaction and broadcasts it to the consensus-service nodes for inclusion in the ledger.
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.
“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.
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.
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:
- 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
- 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
- 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.”
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
|
Related slides
Related reading
- Hyperledger Fabric Approaches v1.0 with Better Scalability and Security
- Hyperledger Fabric: Industry Use Cases and Requirements
About the speakers
This post was written by Roger Strukhoff and Sophie Turol with assisstance from Carlo Gutierrez and Alex Khizhnyak.
