Hyperledger Fabric component design

Let's discuss various components that facilitate the blockchain technology tenets of shared ledger, encryption, the trusts system, and smart contracts. The components represent the Hyperledger Fabric infrastructure components and provide isolation from chain code or smart contract development constructs. Chain code or smart contract development details will be discussed in detail in a separate chapter.

The following diagram depicts the Hyperledger Fabric infrastructure components: 

Hyperledger Fabric infrastructure components

Following are the infrastructure components:

• Hyperledger Fabric CA is an implementation of membership services but is not required to be used (that is, any X509-based PKI infrastructure that can issue EC certificates can be used)
• Dedicated orderer nodes
  • Implements atomic broadcast API
  • Orders and batches transactions and signs each batch (block) to create a hash chain
  • Hyperledger Fabric provides two implementations—Solo (for dev/test) and a Kafka-based implementation for production/fault tolerance
  • The ordering service is pluggable—the implementer needs to only provide an atomic broadcast API based on the gRPC interface definition
• Peers are now responsible for existing smart logic (chaincode) and maintaining the ledger
  • Endorsement simulates transactions (that is, it executes them, but does not commit them)
  • Peers receive batches of endorsed transactions from the orderer nodes and then validate and commit transactions (this eliminates non-determinism)

Principles of Hyperledger design

Hyperledger Fabric, again, is a blockchain implementation that is designed for deploying a modular and extensible architecture. It has a modular subsystem design so that different implementations can be plugged in and implemented over time. This section covers the Hyperledger Fabric reference architecture and describes the details on the various components/modules and their interactions and functions. Understanding the reference architecture facilitates better solution and technology design decisions, especially around scalability, security, and performance.

While in this book we will discuss the reference architecture of Hyperledger Fabric, please note that all the Hyperledger projects (the frameworks referred to previously) follow a design philosophy that includes the following principles:

• Modular and extensible approach: This implies modularity in all components of all frameworks. Components defined by Hyperledger for all projects include (but are not limited to) the following:
  • Consensus layer
  • Smart contract (chain code) layer
  • Communication (gossip) layer
  • Data store (persistent, log, and ledger data)
  • Identity services (root of trust—to identify the participants)
  • APIs
  • Pluggable cryptography
• Interoperability: This principle is around backward interoperability and NOT the interoperability between the various Hyperledger project-powered blockchain systems or business networks.
• Focus on secure solutions: Enterprise and therefore business network security is paramount, hence the focus on security-and not just of the crypto abstraction-but the interaction between components and the structure that governs the permissioning nature of permissioned blockchains. Most industries embarking on the permissioned blockchain are established and regulated industries.
• Token (or coin or crypto-asset) agnostic approach: This is discussed in great length in the governance section, but Hyperledger projects do not use crypto-assets, cryptocurrency, tokens, or coin-like constructs as incentive mechanics to establish trust systems. While there is a notion of asset tokenization that represents a physical, virtual, or dematerialized asset, tokenization of assets is a vastly different concept than a systemic token that is generated in the system as a virtualization of incentive economics.
• Focus on rich and easy-to-use APIs: The focus here is to ensure that blockchain systems have not only enterprise middleware access, but access to business networks, existing participants, and new systems without exposing the details of blockchain powered business networks.

CAP Theorem

The CAP Theorem as postulated by Eric Brewer in 2000 at ACM Symposium on Principles of distributed computing (PODC) (https://dl.acm.org/citation.cfm?id=343502) states that in a distributed data store it is impossible to guarantee more than any two of the following three properties: Consistency (C), Availability (A), and Partition Tolerance (P). A distributed data store thus can be characterized on the two properties it guarantees namely  CA, CP or AP.

More specifically, the theorem is aimed at distributed systems deployed across unreliable networks (networks with faults and delays such as the Internet) leading to a partitioning of the system components. According to CAP, in these environments, the system design must focus on the balance between availability and consistency. For example, the ACID (Atomicity, Consistency, Isolation, Durability) approach typically provided by RDBMS (Relational Database Management Systems) guarantees consistency on a single node on the expense of availability across multiple nodes (CP type of systems). However, note that, different configurations may yield different combinations namely CA or AP as well.

In contrast, Fabric is designed similarly as many other Blockchain platforms as AP type of system with Eventual Consistency also referred to as BASE (Basically Available, Soft state, Eventual consistency).

In context of blockchain CAP properties can be defined as following:

• Consistency: The blockchain network avoids any forks of the ledger
• Availability: Transactions submitted by clients are permanently committed into the ledger and available on all the network peers
• Partition tolerance: The blockchain network continues to operate despite an arbitrary number of transaction proposals or blocks are being dropped (or delayed) by the physical network medium between the peers

Fabric achieves the CAP properties as follows:

• Consistency: By a total order of transactions and version control using MVCC
• Availability: By hosting a copy of the ledger on each of the peers
• Partition tolerance: By maintaining operation despite failed nodes (up to a threshold)

As you can see, availability and partition tolerance (AP properties of the CAP theorem) are guaranteed by default in most blockchain systems. However, consistency is harder to provide.

Fabric achieves consistency by combining the following elements:

• The transaction processing is split into a sequence of steps across multiple components of the network.
• Clients connect to a communication channel and submit transaction proposals to endorsing peers and then to the ordering service.
• The ordering service orders transactions into blocks with a total order i.e. the order of the transactions is guaranteed to be consistent across the whole network. The blocks once created are broadcasted to each member peer of the channel. The broadcasting protocol guarantees reliable delivery of the blocks to the peers in a correct order namely total-order broadcast.
• As we will explain in Multiversion concurrency control, upon reception of the block on the peer, the peer uses MVCC to validate each transaction based on the key versions stored in the transaction ReadSet. The MVCC validation guarantees consistency of the resulting ledger and of the Worldstate and prevents attacks such as double spending. However, it can also lead to elimination of otherwise valid transactions, which have been submitted in an order violating the ReadSet version validation check. The transactions are then marked either valid or invalid in the ledger.
• The ledger then contains a sequence of totally ordered blocks, where each block contains a sequence of totally ordered transactions (either valid or invalid), yielding a ledger imposing a total order across all transactions.

Hyperledger Fabric reference architecture

Hyperledger Fabric follows a modular design, and the following are some of the possible components or modules that can be plugged in and implemented. Note that this list is not exhaustive:

• Membership services: This module is essentially a permissioning module and acts as a vehicle to establish a root of trust during network creation, but this is also instrumental in ensuring and managing the identity of members. Membership services are essentially a certificate authority as well as utilized elements of the public key infrastructure (PKI) for things such as key distribution, management, and establishing federated trust as the network grows. The membership services module provides a specialized digital certificate authority for issuing certificates to members of the blockchain network, and it leverages cryptographic functions provided by Hyperledger Fabric.
• Transactions: A transaction is a request to the blockchain to execute a function on the ledger. The function is implemented by a chaincode. Cryptography ensures integrity of transactions by linking the transaction to previous blocks and ensuring the transactional integrity, if protected, by linking the cryptogram or hash from previously linked blocks. Each channel in Hyperledger Fabric is its own blockchain.
• Smart contract or chaincode services: Chaincode is an application-level code stored on the ledger as a part of a transaction. Chaincode runs transactions that may modify the world state. Transaction logic is written as chaincode (in the Go or JavaScript languages), and executes in secure Docker containers. The transaction transforms data, scoped by chaincode on the channel from which it operates.

Here are the smart contract or chaincode elements enabled by chaincode services. Chaincode is installed on peers, which require access to the asset states to perform reads and writes. The chaincode is then instantiated on specific channels for specific peers. Ledgers within a channel can be shared across entire networks of peers or include only a specific set of participants. Peers are able to participate in multiple channels:

• Events: The process of validating peers and chaincodes can produce events (pre-defined events and custom events generated by chaincode) on the network that applications may listen for and take actions on. These events are consumed by event adapters, which may further deliver events using vehicles such as WebHooks or Kafka. Fabric-committing peers provide an event stream to publish events to registered listeners. As of v1.0, the only events that get published are Block events. A Block event gets published whenever the committing peer adds a validated block to the ledger:

• Consensus: Consensus is at the heart of any blockchain system. It also enables a trust system. In general, the consensus service enables digitally signed transactions to be proposed and validated by network members. In Hyperledger Fabric, the consensus is pluggable and tightly linked to the endorse-order-validation model that Hyperledger proposes. The ordering services in Hyperledger Fabric represent the consensus system. The ordering service batches multiple transactions into blocks and outputs a hash-chained sequence of blocks containing transactions.
• Ledger: Another component is a distributed encrypted ledger, including an append-only data store. This provides the ability to query and write data across distributed ledgers. There are two options:
  • Level DB (default embedded KV DB) supports keyed queries, composite key queries, and key range queries
  • Couch DB (external option) supports keyed queries, composite key queries, key range queries, plus full data rich queries
• Client SDK: A client SDK enables the creation of applications that deploy and invoke transactions atop a shared ledger. The Hyperledger Fabric Reference Architecture supports both Node.js and Java SDK. A software developer kit is like a programming kit or set of tools that provide developers with the environment of libraries to write and test chaincode applications. SDKs are critical in blockchain application development and will be discussed in detail in further chapters. Specific capabilities included in the SDK are the application client, chaincode, users, events, and crypto suite.

Hyperledger Fabric runtime architecture

Now that we've looked at the reference architecture, let's consider the runtime architecture for Hyperledger Fabric:

 

The following outline demonstrates a Hyperledger Fabric runtime transaction processing flow:

• Transaction proposal (application SDK):
  1. Transaction proposal is submitted by application SDK
  2. It receives a transaction proposal response back (includes ReadWrite set) post endorsement
  3. It submits the transaction (includes ReadWrite set) to the ordering service
• Transaction endorsement:
  1. The transaction is sent to the counter-parties represented by endorsing peers on their channel
  2. Each peer executes the transaction by calling the specified chaincode function and signs the result, which becomes the read-write-set of the transaction
  3. Each peer may participate in multiple channels, allowing concurrent execution

• Transaction submitted to the ordering service:
  1. The ordering service accepts endorsed transactions and orders them according to the plug-in consensus algorithm, and then delivers them on the channel
  2. Peers on the channel receive transactions and validate before committing to the ledger
• Transaction validation:
  1. Validates each transaction and commit block
  2. Validates the endorsement policy
  3. Validates ReadSet versions in state DB
  4. Commits the block to blockchain
  5. Commits the valid transaction to state DB

Strengths and advantages of componentized design

Hyperledger Fabric's component design offers several advantages. Many of these strengths relate to business network governance, which is an important compliance and costs consideration for Hyperledger Fabric in the enterprise.

These benefits include the following:

• Delineates development design from runtime design: Separating development and runtime design is important because the delineation is important from development best practices and infrastructure/hybrid cloud variations, and ensuring adherence to the current enterprise and their connectivity to the business network's application development, as well as DevOps practices.
• Discerning between design imperatives and infrastructure/deployment capabilities: Componentized design allows us to separate infrastructure design, which includes things such as network connections, security, permissioning, and contractual vehicles, from the overall application design of the business network blueprint that dictates the technology blueprint.

• Incorporates network design principles: The modularity of Hyperledger Fabric can address infrastructure scaling issues, such as the number of connections, co-location, security, container deployment practices, and so on. There are various considerations when it comes to network design, such as cloud deployment, hybrid and/or on premises, and a combination of any of the available options, which are dependent on the requirements of individual members in a business network. Network design also addresses the business challenges of network growth and the resulting performance and security driven Service Level Agreements (SLA) to its members.
• Addresses channel design principles: Modularity, or componentized design, can also address isolation, data privacy, and confidentiality between participants and controlled/permissioned access with robust audit capability. Channel constructs in Hyperledger Fabric enable us to address the business blueprint requirements around implementing business-defined transactions that may be bilateral, trilateral, or event multilateral. Channels also provide an avenue to limit the visibility of transaction data to a few participants or provide full access when required, such as to a regulator. Channel design also addresses critical business requirements around transaction processing, data visibility, business rules enforcement, and so on. It also has technology implications, such as a scalability, security, and the costs of the infrastructure that supports the business network. Finally, channel design addresses the business challenges of network growth and the resulting performance and security-driven SLAs to members.
• Adopts Hyperledger Fabric composer model-driven development: Hyperledger Composer, one of the tools discussed previously under Hyperledger tools, provides an avenue to modular development with a portable, standardized vehicle to add governance and control, similar to JEE constructs such as JAR/WAR/RAR, and so on. Business network archive (BNA) is an archive that can be integrated into DevOps practices for cross-enterprise team development and collaborative life cycle management capabilities. The idea is to separate chaincode development from infrastructure design and separate the competencies needed to maintain the two facets of enterprise or business network application technology practices. More details around Hyperledger Fabric composer will be discussed in a separate chapter dedicated to the composer and tooling.

Each of the advantages of componentized design described previously have cost implications in terms of runtime/infrastructure design (that is, use of resources and resulting costs), flexible design (such as products and relationships morphs), and the longevity of the solution (the global footprint of the enterprise cloud infrastructure, including robust access to technical and business SMEs in the form of maintenance and support)—all of which are essential for compliance, governance, and longevity of the solution, and resulting business networks powered by blockchain.