Book Image

Blockchain with Hyperledger Fabric - Second Edition

By : Nitin Gaur, Anthony O'Dowd, Petr Novotny, Luc Desrosiers, Venkatraman Ramakrishna, Salman A. Baset
Book Image

Blockchain with Hyperledger Fabric - Second Edition

By: Nitin Gaur, Anthony O'Dowd, Petr Novotny, Luc Desrosiers, Venkatraman Ramakrishna, Salman A. Baset

Overview of this book

Blockchain with Hyperledger Fabric - Second Edition is a refreshed and extended version of the successful book on practical Hyperledger Fabric blockchain development. This edition includes many new chapters, alongside comprehensive updates and additions to the existing ones. Entirely reworked for Hyperledger Fabric version 2, this edition will bring you right up to date with the latest in blockchain. Using a real-world Trade Finance and Logistics example, with working code available on GitHub, you’ll really understand both how and why Hyperledger Fabric can be used to maximum effect. This book is your comprehensive guide and reference to explore and build blockchain networks using Hyperledger Fabric version 2. This edition of the book begins by outlining the evolution of blockchain, including an overview of relevant blockchain technologies. Starting from first principles, you’ll learn how to design and operate a permissioned blockchain network based on Hyperledger Fabric version 2. You will learn how to configure the main architectural components of a permissioned blockchain network including Peers, Orderers, Certificate Authorities, Channels, and Policies. You’ll then learn how to design, develop, package, and deploy smart contracts, and how they are subsequently used by applications. This edition also contains chapters on DevOps, blockchain governance, and security, making this your go-to book for Hyperledger Fabric version 2.
Table of Contents (18 chapters)
Another Book You May Enjoy

Other considerations

There are a few other considerations to keep in mind apart from the previously mentioned aspects. They are briefly explained in the following sections.

Consensus, ACID properties, and CAP

A consensus model will never go to 0 because when NoSQL became the standard, various NoSQL systems solved their problems by understanding the CAP theorem, and the RDBMS enterprise community held steadfast to their ACID properties. Blockchain technology components and operational models aim to serve primarily as a transaction system. The distributed nature of the infrastructure and transaction processing tends to put the CAP theorem in high gear. It suggests that between the three desired properties of a transaction system—consistency, availability, and partition tolerance—at any given point, only one or two can be achieved. In the blockchain context, the CAP theorem implies that in the presence of a network partition, you must choose between consistency and availability. On the other hand, ACID properties—atomicity, consistency, isolation, and durability—constitute a set of properties of database transactions that are intended to guarantee validity even in the event of errors, power failures, and so forth. The technology design needs to consider the CAP and ACID principles when devising a system that can deliver industry and use case requirements.

CAP stands for consistency, availability, network partition tolerance:

  • C – Consistency: Consensus guarantees only one truth of what happened and in one order.
  • A – Availability: The fact that all calls to the blockchain are asynchronous allows the invoking application to make progress while ensuring consensus and durability. (Chaining also guarantees this.)
  • P – Network partition tolerance: Consensus again prevents split-brain with conflicts when things get back together after a network partition.

ACID stands for atomicity, consistency, isolation, durability:

  • A – Atomicity: The chaincode programming model is an all-or-nothing behavior that allows you to group activities together. It either all happens, or it doesn't.
  • C – Consistency: I think the new world of NoSQL fudges this one. This means the same as the "C" in CAP.
  • I – Isolation: Isolation indicates that two transactions are serialized, which is exactly what the block construction and chaining do.
  • D – Durability: The chaining and replication all over the network ensure that if one or more nodes go down, data won't be lost. This is why everyone wants to bring a node and why those nodes should not be co-located.

Attestation – SSCs are signed and encrypted

In secure service containers (SSCs), the software, operating system, hypervisors, and Docker container images cannot be modified. Certificates may be included in the SSC so that they can prove themselves to be genuine to a remote party. For example, including an SSL certificate when building SSCs helps ensure that you're speaking with a genuine instance, since the SSL certificate always stays protected (encrypted) within the SSC.

Use of HSMs

According to Wikipedia (, a "hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing." These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server.

It can be a real challenge to administer a high-security device like an HSM with sufficient security and controls. In fact, today's standards mandate certain methods and levels of security for HSM administrative (and key management) systems.