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.