leaf

Bitcoin is considered a representative platform of the blockchain technology 1.0 era. With the emergence of the Ethereum platform, characterized mainly by smart contracts, blockchain technology entered the 2.0 era, while the open-source project Hyperledger Fabric marks the arrival of the blockchain technology 3.0 era. The recently released Fabric v1.4.1 (LTS) introduces many new design concepts, adds numerous new features, provides a highly modular and configurable architecture, supports the writing of smart contracts in general programming languages (such as Java, Go, and Node.js), and supports pluggable consensus protocols, making it possible to develop enterprise-level applications based on this platform, which is gaining increasing attention. This chapter will lead readers into the world of Hyperledger Fabric, exploring its basic operating principles to deepen understanding of the platform and lay the foundation for subsequent learning of application development technologies based on Fabric.

The Hyperledger project is an open-source initiative dedicated to advancing blockchain digital technology and transaction verification, aiming to enable members of the open-source community to collaborate in building an open platform that meets the needs of users in various industries and simplifies business processes. The project aims to create public standards for distributed ledgers to facilitate the exchange of value in virtual and digital forms.

Supported by blockchain technology, "digital cryptocurrencies" like Bitcoin have become a hot topic, with their active user numbers and transaction volumes increasing daily, developing at a pace far beyond people's estimates. Many entrepreneurs, companies, and financial institutions have gradually realized the value of blockchain technology, generally believing it has broader application prospects beyond just the "digital cryptocurrency" field.

To this end, Vitalik founded the Ethereum project, hoping to create a Turing-complete smart contract programming platform that allows blockchain enthusiasts to build and develop blockchain applications more easily and effectively. Consequently, many new types of blockchain applications emerged in the market, such as asset registration, prediction markets, identity authentication, and various other applications. However, at that time, blockchain technology itself still faced some insurmountable issues. For instance, first, transaction efficiency was low, with the entire Bitcoin network supporting only about seven transactions per second; second, the certainty of transactions could not be well guaranteed; and finally, the mining mechanism used to reach consensus caused significant resource waste. These issues led to the inability of the blockchain technology at that time to meet the needs of most commercial applications.

Therefore, designing and implementing a blockchain platform that meets commercial needs became a key focus of blockchain development at that time. In response to strong calls from various sectors of society, the Linux Foundation's open-source organization launched an open-source project named Hyperledger in December 2015, intending to collaboratively build an enterprise-level application platform for blockchain technology through cooperation among various parties, thereby promoting the development of cross-industry blockchain.

From its inception, Hyperledger attracted many well-known companies to join, such as IBM, Cisco, Intel, and other tech giants, while financial industry giants like Wells Fargo and JPMorgan also became among the first members. Its development community has now grown to over 270 organizations. Notably, more than a quarter of the project members come from Chinese companies, such as Qulian Technology, Xiaoyi, and Bubi, along with participation from well-known enterprises like Wanda, Huawei, and China Merchants Bank. From the composition of its members, the Hyperledger open-source project boasts a formidable presence, gathering numerous industry elites to collaboratively explore solutions and advance the development of enterprise-level blockchain platforms.

The Hyperledger project was the first to propose and implement complete member permission management, innovative consensus algorithms, and pluggable frameworks, which will have a profound impact on the development of blockchain-related technologies and industries. In fact, this already indicates that blockchain technology is no longer merely an open-source technology; it has been formally recognized by mainstream institutions and markets in other industries.

The Hyperledger project is a large open-source initiative that hopes to promote and advance the development of blockchain technology in commercial applications through collaborative efforts. Its structural composition includes many specific sub-projects. These sub-projects can be independent projects or projects related to other projects, such as construction tools, blockchain explorers, etc. Hyperledger does not impose significant constraints on the form of sub-projects; as long as there are good ideas related to it, proposals can be submitted to the Hyperledger committee.

The project's official address is hosted on the Linux Foundation website, with code hosted on Gerrit and mirrored on GitHub. To better manage sub-projects and develop the project, the Hyperledger project established a Technical Steering Committee (TSC), which is also the highest authority of the Hyperledger project. Important decisions regarding the management of sub-projects and the development of the entire project ecosystem will be executed by it. The Hyperledger project adopts a lifecycle approach in managing its sub-projects, assigning each project a lifecycle to facilitate its operation and management. The entire lifecycle is divided into five stages: proposal, incubation, active, deprecated, and finally end of life. At any given point in time during the development process, a project will correspond to only one stage. Of course, projects do not necessarily develop in the above order; they may remain in a certain stage indefinitely or may shift between multiple stages for various reasons. All projects need to emphasize modular design, including technical scenarios involving transactions, contracts, consistency, identity, and storage, and must achieve code readability to ensure that new features and modules can be easily added and extended, while continuously increasing and evolving new projects to meet the increasingly in-depth commercialization needs and gradually enriching application scenarios.

Fabric is an implementation of blockchain technology and a distributed shared ledger technology based on transaction calls and digital events. Compared to other blockchain technology implementations, it adopts a modular architectural design that supports the development and use of pluggable components. The data on its ledger is jointly maintained by multiple participating nodes, and once recorded, the transaction information on the ledger can never be tampered with, supporting traceability through timestamps. For other public chains, Fabric introduces member management services, so each participant must provide corresponding certificates to prove their identity to access the Fabric system, while also introducing a multi-channel and multi-ledger design to enhance the system's security and privacy. Compared to Ethereum, Fabric uses powerful Docker container technology to run services, supporting more convenient and powerful smart contract services than Ethereum, which can only write contracts using the provided Solidity language, while Fabric supports contract writing in multiple languages, such as Go, Java, and Node.js. In addition, Fabric also provides multi-language SDK development interfaces, allowing developers to freely and conveniently use the blockchain services it provides. The following sections will delve into the architecture and operation of Fabric.

Iroha is a distributed ledger project inspired by the Fabric architecture, which entered the incubation phase on October 13, 2016, with the approval of the Technical Steering Committee and moved out of the incubation zone on May 18, 2017. It aims to provide a development environment for Hyperledger projects for C++ and mobile application developers. The project hopes to implement reusable components for Fabric, Sawtooth Lake, and other potential blockchain projects in C++, and these components can be called using Go language. In other words, Iroha is a complement to existing projects, with the long-term goal of achieving a robust reusable component library, allowing Hyperledger technology projects to freely choose and use these reusable elements when running distributed ledgers.

Sawtooth Lake was approved by the TSC on April 14, 2016, and moved out of the incubation zone on May 18, 2017. It is a modular distributed ledger platform experimental project initiated by Intel, designed for multi-functionality and scalability. Sawtooth Lake provides a modular platform for building, deploying, and running distributed ledgers while supporting the deployment of both permissioned and permissionless chains. It includes a new consensus algorithm called PoET. PoET, like the proof-of-work algorithm used by Bitcoin, randomly selects a node according to certain rules to act as the block's bookkeeper, while other nodes are responsible for verifying that block and executing results. The difference is that PoET does not require a large amount of computing power and energy consumption but requires CPU hardware to support SGX (software guard extensions) features. Due to the hardware limitations of the PoET algorithm, it is currently only suitable for use in production environments.

The Blockchain Explorer project aims to create a user-friendly web application for Hyperledger to query information on the Hyperledger blockchain, including block information, transaction-related data, network information, contract code, and related information stored in the distributed ledger. The project was approved by the TSC on August 11, 2016, and subsequently entered the incubation phase.

The Cello project was approved by the TSC on January 5, 2017, entering the incubation state. The Cello project aims to provide a blockchain-as-a-service (BaaS) solution to reduce the manual workload of creating and destroying blockchains. Through Cello, operators can easily create and manage blockchains using a dashboard, while users (contract code developers) can immediately obtain blockchain information with a single request. In other words, it provides operators with a simple and convenient blockchain operation platform.

Hyperledger Fabric is a unique implementation of distributed ledger technology (DLT) that provides enterprise-level network security, scalability, confidentiality, and high performance based on a modular blockchain architecture. The current latest version of Fabric is v1.4.1 (LTS), which has made many improvements over the previous v0.6 version in terms of security, confidentiality, deployment, maintenance, and actual business scenario needs. For example, architectural design improvements include the functional separation of Peer nodes, privacy isolation of multi-channels, and pluggable implementations of consensus, introducing Raft crash fault tolerance consensus services, improving maintainability and operability, and adding private data support, all of which provide better service support for Fabric. Therefore, the subsequent content of this book regarding Fabric will be based on version v1.4.

Hyperledger Fabric v1.4 has the following features:

• Identity management. The Fabric blockchain is a permissioned chain network, so Fabric provides a member service for managing user IDs and authenticating all participants on the network. In the Hyperledger Fabric blockchain network, members can recognize each other through identity information, but they do not know what each other is doing, which is the confidentiality and privacy provided by Fabric.

• Privacy and confidentiality. Hyperledger Fabric allows competing commercial organizations and any other groups with privacy and confidentiality needs for transaction information to coexist within the same permissioned chain network. It limits the propagation path of messages through channels, providing transaction privacy and confidentiality protection for network members. All data in the channel, including transactions, members, and channel information, is invisible, and network entities that have not subscribed to that channel cannot access it.

• Efficient processing. Hyperledger Fabric assigns network roles based on node types. To provide better network concurrency and parallelism, Fabric effectively separates transaction execution, transaction ordering, and transaction submission. Executing transactions before ordering allows each Peer node to handle multiple transactions simultaneously, greatly improving the processing efficiency of Peer nodes and accelerating the delivery process of transactions to consensus services.

• Chaincode functionality. Chaincode is the encoded logic of transaction calls in the channel, defining the parameters used to change asset ownership, ensuring that all transactions for the transfer of digital asset ownership comply with the same rules and requirements.

• Modular design. The modular architecture implemented by Hyperledger Fabric provides functional choices for network designers. For example, specific identity recognition, consensus, and encryption algorithms can be inserted as pluggable components into the Fabric network, allowing any industry or public sector to adopt a generic blockchain architecture and ensuring that its network can interoperate across market, regulatory, and geographical boundaries.

• Serviceability and operations. Improvements in logging, along with the addition of health check mechanisms and operational metrics, have achieved significant leaps in maintainability and operability in version v1.4. The new RESTful operational services provide three services for production operators to monitor and manage the operation of peer nodes and consensus service nodes. The first service uses the logging/logspec endpoint, allowing operators to dynamically retrieve and set the logging levels for peer nodes and consensus service nodes; the second service uses the health check/healthz endpoint, allowing operators and business process containers to check the activity and health of peer nodes and consensus service nodes; the third service uses the operational metrics/metrics endpoint, allowing operators to utilize Prometheus to record operational metrics from peer nodes and consensus service nodes.

• Anchor nodes

  The Gossip protocol uses anchor nodes to ensure that peer nodes in different organizations are aware of each other. When a configuration block containing anchor node updates is submitted, peer nodes can detect anchor nodes and learn about all peer nodes known to the anchor nodes. Since organizations communicate through Gossip, at least one anchor node must be defined in the channel configuration. Each organization providing a set of anchor nodes can achieve high availability and reduce redundancy.

• Access Control Lists

  Access Control Lists (ACLs) associate access to specific peer node resources (such as system contract code APIs or transaction services) with policies (specifying the number and type of required organizations or roles). ACLs are part of the channel configuration and can be updated using standard configuration update mechanisms.

• Blocks

  A block contains a set of ordered transactions, created by the consensus system and validated by peer nodes. In the channel, it is first cryptographically linked to the previous block and then connected to the subsequent block. The first block is called the genesis block.

• Blockchain

  A blockchain is a transaction log structured from a series of transaction blocks connected by hashes. After peer nodes receive transaction blocks from the consensus service, they mark the transactions in the blocks as valid or invalid based on endorsement policies and concurrency conflicts, and append the blocks to the hash chain in the peer node's file system.

• Smart Contracts

  Smart contracts are codes called by clients external to the blockchain network, used to manage access and modification of key-value pairs in the world state, installed on peer nodes, and instantiated on channels. Smart contracts are also referred to as contract code.

• Channels

  A channel is a private blockchain built on the Fabric network, defined by configuration blocks, ensuring data isolation and privacy. All peer nodes share specific ledgers in the channel, and interactions between parties and the ledger must be validated for correctness through the channel.

• Submission

  Each peer node in a channel verifies the order of transaction blocks and then submits (writes or appends) the blocks to the various copies of the ledger in that channel. Peer nodes also mark whether transactions are valid.

• Concurrency Control Version Check

  Concurrency Control Version Check (CCVC) can keep the states of peer nodes in the channel synchronized. Peer nodes execute transactions in parallel, and before submitting transactions to the ledger, peer nodes check whether the data read during execution has been modified. If modified, a CCVC conflict is triggered, marking the transaction as invalid in the ledger, and its value will not be updated in the state database.

• Configuration Blocks

  Configuration blocks contain configuration data defining members and policies for the system chain (consensus service) or channel. Modifications to the configuration of a channel or the entire network (such as members leaving or joining) will generate a new configuration block and append it to the appropriate chain. This configuration block will contain the content of the genesis block plus increments.

• Consensus

  Consensus is used to confirm the ordering of transactions and the correctness of the transaction set itself.

• Agreement Set

  In the Raft consensus service, the agreement set consists of ordering nodes actively participating in the consensus mechanism on the channel. If there are other ordering nodes on the system channel that are not part of the channel, those ordering nodes do not belong to the channel's ordering set.

• Consortium

  A consortium is a collection of unordered organizations on the blockchain network. These collections form and join channels and have their own peer nodes. Although a blockchain network can have multiple consortia, most networks only have one consortium. When a channel is created, all organizations joining the channel must be part of the consortium. Organizations not defined in the consortium may be added to existing channels.

• World State

  The world state, also known as the current state of the ledger, represents the latest values of all keys in the blockchain transaction log. Peer nodes update the world state of the ledger with the value changes corresponding to each transaction they have recently processed. Since the world state can directly access the latest values of keys rather than traversing the entire transaction log, contract code must first know the key-value world state and then execute transaction proposals against this world state.

• Dynamic Member Management

  Fabric supports dynamically adding/removing members, peer nodes, and consensus service nodes without affecting the operationality of the entire network. Dynamic member management is crucial when business relationships change or when entities need to be added/removed for various reasons.

• Genesis Block

  The genesis block is the configuration block that initializes the blockchain network or channel and is also the first block on the blockchain.

• Gossip Protocol

  The Gossip data transmission protocol has three functions: managing peer nodes, discovering members on the channel; broadcasting ledger data among all peer nodes on the channel; synchronizing ledger data among all peer nodes on the channel.

• Ledger

  The ledger consists of the blockchain and the world state. The blockchain is immutable; once a block is added to the chain, it cannot be changed. The world state is a database containing the current values of key-value pairs added, modified, or deleted by validated and submitted transaction sets from the blockchain. Each channel in the network has a logical ledger; in fact, each peer node in the channel maintains its own copy of the ledger, which is kept consistent with the copies of other peer nodes through the consensus process. The term distributed ledger technology (DLT) is often associated with this ledger.

• Follower

  In leader-based consensus protocols (such as Raft), followers are nodes that replicate log entries generated by the leader. In Raft, followers also receive "heartbeat" messages from the leader; if the leader stops sending these messages within a configurable time, the followers will initiate a leader election, and one of the followers will be elected as the leader.

• Leader

  In leader-based consensus protocols (such as Raft), the leader is responsible for extracting new log entries, replicating them to follower consensus nodes, and managing when records are considered committed.

• Main Peer Node

  Each organization can have multiple peer nodes on the channels they subscribe to, with at least one serving as the main peer node to communicate with the network's consensus service on behalf of that organization. The consensus service provides blocks to the main peer nodes on the channel and then distributes them to other peer nodes within the same organization.

• Logging

  Logging is the primary working unit in the Raft consensus service, distributed from the leader to the followers. The complete sequence of these records is called the "log." If all members agree on the records and their ordering, the log is considered consistent.

• Member Service Provider Component

  The Member Service Provider (MSP) refers to the system abstract component that provides certificates for client nodes and peer nodes. Client nodes use certificates to authenticate their transactions; peer nodes use certificates to authenticate their transactions (endorsements). This interface is closely related to the transaction processing component of the system, designed to allow the defined membership service components to be smoothly integrated without modifying the core of the system's transaction processing component.

• Member Management Service

  The member management service authenticates, authorizes, and manages identities on the permissioned blockchain. The member management service runs agents in peer nodes and ordering service nodes.

• Ordering Service or Consensus Service

  A collection of nodes that sorts transactions into blocks. The ordering service operates independently of the peer node processes and sorts transactions for all channels on the network in a first-come, first-served manner. The ordering service supports pluggable implementations, with the default implementations being Solo and Kafka.

• Organization

  Organizations, also known as "members," are invited by blockchain service providers to join the blockchain network. Organizations join the network by adding their MSP to it. The transaction endpoint for organizations is the peer node, and a group of organizations forms a consortium. While all organizations on the network are members, not every organization will be part of the consortium.

• Node

  A network entity that maintains the ledger and runs contract containers to perform read and write operations on the ledger. Nodes are owned and maintained by members.

• Policy

  • Policies are expressions composed of attributes of digital identities (digital identity), such as Org.Peer and Org2.Peer, used to restrict access to resources on the blockchain network. Policies can be defined before booting the consensus service or creating channels, or specified when instantiating contract code on the channel.

  • Private Data

    Private data is confidential data stored in the private databases of each authorized peer node, logically separated from the channel ledger data. Access to private data is limited to organizations defined on the private data set. Unauthorized organizations can only have the hash of private data on the channel ledger as evidence of transaction data. Furthermore, to further protect privacy, the hash of private data is transmitted through the consensus service rather than the private data itself, keeping the private data confidential from consensus service nodes.

  • Private Data Set

    A private data set is used to manage organizations on the channel that wish to keep their data confidential from other organizations on that channel, describing a subset of organizations authorized to store private data, and only these organizations can transact with the private data.

  • Raft

    Raft is a new feature added in v1.4.1, based on the Raft protocol's etcd library for crash fault tolerance (CFT) consensus service implementation. Raft follows the "leader and follower" model. Compared to the Kafka-based consensus service, the Raft consensus service is easier to set up and manage and allows organizations to contribute nodes for distributed consensus services.

Hyperledger is currently one of the more recognized implementations of consortium chains in the industry, and as its most important sub-project, Fabric has received significant attention. From incubation to development to the present, the architectural design of Fabric has gradually improved and refined during its evolution. The basic content and functions of Fabric have been introduced earlier, and now we will begin to explore Fabric in depth, analyzing its latest overall architecture and discussing the characteristics and advantages of the new architecture compared to past architectures.

Fabric adopts a modular design concept in its architectural design. As shown in the overall logical architecture in Figure 4.1, Fabric mainly consists of three service modules: membership service, blockchain service, and chaincode service. The membership service provides member registration, identity management, and authentication services, making platform access more secure and facilitating permission management; the blockchain service is responsible for consensus management between nodes, distributed computation of ledgers, implementation of P2P network protocols, and ledger storage, serving as the core component of the blockchain and providing underlying service support for the main functions of the blockchain; the chaincode service provides an execution engine for smart contracts, offering a deployment and runtime environment for Fabric's contract code (smart contracts). Additionally, the logical architecture diagram shows that an event stream runs through the three service components, providing technical support for asynchronous communication among the components. In the Fabric interface section, three types of interfaces are provided: API, SDK, and CLI, which users can use to manage Fabric operations.

This illustrates the operational architecture of Fabric. The structure of version v0.6 is very simple, with the application-member management-Peer presenting a triangular relationship, where all business functions of the system are completed by Peer nodes. However, the Peer nodes bore too many business functions, exposing numerous issues regarding scalability, maintainability, security, and business isolation. Therefore, in version v1.4, the official architecture was improved and restructured, completely separating the consensus service part from the Peer nodes to form a new node that provides consensus and broadcasting services. Version v1.4 also introduced the concept of channels, achieving a multi-channel structure and multi-chain network, bringing more flexible business adaptability. It also supports stronger configuration and policy management functions, further enhancing the system's flexibility.

Runtime Architecture (v1.4)

Compared to version v0.6, the new architecture significantly enhances the system in many aspects, with the following major advantages.

• Chaincode Trust Flexibility. In version v1.4, the architectural design separates the trust assumptions of chaincode from those of the consensus service. The new version of the consensus service can be provided by a group of separate nodes (orderers), even allowing for some failed or malicious nodes. For chaincode programs, it can specify different endorsement nodes, greatly enhancing the flexibility of chaincode.

• Scalability. In the new architecture, the endorsement nodes responsible for endorsing specific chaincode and the consensus nodes are orthogonal, so compared to the v0.6 architecture where all business functions were executed on Peer nodes, the scalability of the v1.4 version architecture has greatly improved. Especially when the endorsement nodes specified by different chaincodes have no overlap, the system can simultaneously perform endorsement operations for multiple chaincode programs, significantly improving the efficiency of system processing.

• Confidentiality. The multi-channel design makes it easier to deploy chaincode that requires confidentiality for content and execution state updates. It also adds support for private data, and zero-knowledge proofs (ZKP) currently under development will be available in the future.

• Consensus Modularity. The v1.4 architecture separates the consensus service from Peer nodes to become independent consensus nodes, and the consensus service is designed as a pluggable modular component, allowing different consensus algorithms to be applied to complex and diverse business scenarios.

The membership service can provide identity management, privacy, confidentiality, and authentication services for participants in Fabric. Below, we will focus on the relevant content of the PKI system and the user registration process.

1. PKI System

   The goal of PKI (public key infrastructure) is to enable secure communication between different members without meeting in person. The model currently adopted by Fabric is based on trusted third-party institutions, namely, certificates issued by certification authorities (CAs). The CA issues certificates after confirming the identity of the applicant and provides the latest revocation information for the issued certificates online, allowing users to verify whether the certificates are still valid. A certificate is a document containing a public key, relevant information about the applicant, and a digital signature. The digital signature ensures that the contents of the certificate cannot be tampered with by any attacker, and the verification algorithm can detect any forged digital signatures. In this way, the public key and identity are bound together, cannot be tampered with or forged, enabling member management.

   The member service combines the PKI system with a decentralized consensus protocol, transforming a permissionless blockchain into a permissioned blockchain. In a permissionless blockchain, entities do not need authorization, and all nodes in the network do not have role distinctions; they are all uniform peer entities with equal rights to submit transactions and keep accounts. In a permissioned blockchain, entities need to register to obtain long-term identity certificates (e.g., registration certificates), which can be differentiated based on entity types. For users, during registration, the transaction certificate authority (TCA) issues an anonymous certificate to the registered user; for transactions, the required transaction must be authenticated by the transaction certificate, and the transaction certificate will be stored on the blockchain for certification service to trace transaction use. In fact, the member service acts as a certification center, responsible for providing certificate authentication and permission management functions, managing and authenticating nodes and transactions in the blockchain network.

   In the implementation of the Fabric system, the member service consists of several basic entities that cooperate to manage user identities and privacy on the network. Some of these entities are responsible for verifying user identities, some are responsible for registering identities for users in the system, and some provide the necessary certificate credentials for users when entering the network or invoking transactions. PKI is a framework based on public key encryption that ensures secure data exchange on the network and can also be used to confirm and manage the identity of the other party. Additionally, in the Fabric system, PKI is also used to manage the generation, distribution, and revocation of keys and digital certificates.

   Typically, the PKI system includes certificate authorities (CAs), registration authorities (RAs), certificate databases, and certificate storage entities. Among them, the RA is a trusted entity responsible for verifying user identities and reviewing the legality of data, certificates, or other materials used to support user requests, and is also responsible for creating the registration credentials required for registration. The CA issues digital certificates to specified users based on the recommendations of the RA, and these certificates are certified directly or hierarchically by the root CA.

Further introduction of the entities in the figure.

• Root Certificate Authority: The root CA represents the trusted entity in the PKI system and is also the top-level certification authority in the PKI architecture.

• Enrollment CA (ECA): After verifying the registration credentials provided by the user, the ECA is responsible for issuing registration certificates (ECerts).

• Transaction CA (TCA): After verifying the registration credentials provided by the user, the TCA is responsible for issuing transaction certificates (TCerts).

• TLS CA: Responsible for issuing TLS (transport layer security) certificates and credentials to allow users to use their network.

• ECerts (enrollment certificates): ECerts are long-term certificates issued for all roles.

• TCerts (transaction certificates): TCerts are short-term certificates for each transaction, issued by the TCA based on authorized user requests. Users can configure TCerts to carry no identifying information, allowing them to participate in the system anonymously and preventing transaction linkability.

• TLS-Certs (TLS-Certificates): TLS-Certs carry the identity of their owners, used for communication between systems and components and maintaining network-level security.

• CodeSignerCerts (Code Signer Certificates): Responsible for digitally signing software code, identifying the source of the software and the true identity of the software developer, ensuring that the code is not maliciously tampered with after signing.

The financial IC card system also uses the PKI system, as shown in the architecture diagram. Compared to Fabric's PKI system, it does not have TCerts, and each transaction is completed using ECerts, so transactions in this system are not anonymous.

Having introduced the entities and basic functions of the PKI system in the member service, we will now provide a brief introduction to the specific user registration process. The figure shows a high-level description of a user registration process, divided into two stages: offline process and online process.

User Registration Process

• Offline Process

  (1) Each user or Peer node must provide identification (ID proof) to the RA registration authority, and this process must be transmitted through out-of-band (OOB) data to provide the evidence required for the RA to create (and store) an account for the user.

  (2) The RA registration authority returns the user-related username and password, as well as a trust anchor (including the TLS-CA Cert). If the user can access the local client, the client can use the TLS-CA certificate as a way of trust anchor.

• Online Process

  (1) The user connects the client to request login to the system, during which the user sends the username and password to the client.

  (2) The client on behalf of the user sends a request to the member service, which accepts the request.

  (3) The member service sends a package containing several certificates to the client.

  (4) Once the client verifies that all cryptographic materials are correct and valid, it stores the certificates in the local database and notifies the user, completing the user registration.

The blockchain service consists of four modules: consensus management, distributed ledger, ledger storage, and P2P network protocol. Consensus management is used to achieve consensus on messages in a distributed complex network of multiple nodes, while distributed ledger and ledger storage are responsible for all data storage in the blockchain system, such as transaction information, world state, private data, etc. The P2P network protocol is the communication method between nodes in the network, responsible for communication and interaction among various nodes in Fabric.

1. P2P Network

   The P2P network is a distributed application architecture formed by the peer-to-peer computing model at the application layer, used for distributing tasks and workloads among peer entities. Multiple computers connected to each other in a P2P network environment are on equal footing, having the same functions without distinction between master and slave. A computer can act as a server, setting shared resources for other computers in the network, and can also act as a workstation to request services. Generally, the entire network does not rely on dedicated centralized servers or dedicated workstations. In the distributed environment of blockchain, each node should be equal, making it naturally suitable for the P2P network protocol.

   In the Fabric network environment, nodes are the communication entities of the blockchain. There are three types of nodes: client nodes (Client), peer nodes (Peer), and consensus service nodes (Ordering Service Node or Orderer).

   Client nodes represent end-user entities. They must connect to peer nodes to communicate and interact with the blockchain. At the same time, client nodes can connect to any peer node of their choice to create transactions and invoke transactions. In the actual system operating environment, the client is responsible for communicating with peer nodes to submit actual transaction calls and for communicating with the consensus service to request broadcasting of transaction tasks.

   Peer nodes are responsible for communicating with consensus service nodes to maintain and update the world state. They receive messages broadcasted by the consensus service, receiving ordered transaction information in the form of blocks, and then updating and maintaining the local world state and ledger. Meanwhile, peer nodes can additionally take on the role of endorsement nodes, responsible for endorsing transactions. The special function of endorsement nodes is set for specific transactions, performing endorsement operations before submitting them. Each chaincode program can specify an endorsement policy that includes a set of multiple endorsement nodes. It is important to note that there is a special case in the deployment transaction of installing new chaincode, where the (deployment) endorsement policy is specified by the endorsement policy of a system chaincode and cannot be specified by itself.

   The consensus service node Orderer is part of the consensus service. The consensus service can be seen as a communication organization that provides delivery guarantees. The responsibility of the consensus service nodes is to order transactions, ensuring that all transactions are output in the same sequence and providing broadcast communication services for delivery guarantees.

Regarding the types of nodes, let's take a look at the network topology. In version v0.6, the entire network consists of two types of nodes: validating peers (VP) and non-validating peers (NVP). As shown in the figure, the network includes four validating nodes, and each node is connected to two non-validating nodes, with the consensus of the entire network composed of the four validating nodes. In version v1.4, the network topology has undergone significant changes with the change in node types, where consensus service nodes together form the consensus service, separating the consensus service, while peer nodes can be divided into endorsement nodes or submitting peer nodes, and they can also be grouped, forming a new complete network together with the consensus service.

In versions after v1.0, Fabric introduced the concept of channels, and message passing on the consensus service supports multiple channels, allowing peer nodes to subscribe to any number of channels based on application access control policies. A subset of peer nodes can be specified by applications to set up related channels, forming a set of peer nodes that share the same channel, submitting transactions for that channel, and only these peer nodes can receive related transaction blocks, completely isolating them from other transactions. Fabric supports multi-chain and multi-channel, meaning that multiple channels and multiple chains can exist in the system, as shown in the figure. Applications determine which transactions to send to one or more specified channels based on business logic, and transactions on different channels will have no connection.

• Starting from v1.2, Fabric can create private data sets in the ledger, allowing a subset of organizations on the channel to recognize, submit, or query private data without creating a separate channel, achieving confidentiality of a set of organizations' data from other organizations on the channel. The actual private data is stored in the private state databases of authorized organizations' peer nodes (sometimes referred to as side databases or SideDB), accessible through the Gossip protocol by contract code on authorized nodes. The consensus service does not involve or see private data. Since the Gossip protocol distributes private data among authorized organizations, it requires establishing anchor nodes in the channel and configuring CORE_PEER_GOSSIP_EXTERNALENDPOINT on each node to facilitate cross-organization communication. The hashes of private data can be recognized, ordered, and written into the ledgers of each peer in the channel as evidence of transactions, used for state validation and auditing.

In summary, some restructuring and new features in Fabric regarding nodes and networks have enhanced Fabric's transaction processing capabilities and effectively achieved privacy isolation.

• Consensus Service

  The Orderer nodes in the network gather to form the consensus service. It can be seen as a communication organization that provides delivery guarantees. The consensus service provides a shared communication channel for client and peer nodes and also provides broadcast service functionality for messages containing transactions. After connecting to the channel, clients can send messages to all peer nodes through the consensus service by broadcasting messages. The consensus service can provide atomic delivery guarantees for all messages, meaning that in Fabric, the consensus service ensures that message communication is serialized and reliable. In other words, the consensus service outputs the same messages to all peer nodes connected to the channel, and the logical order of the outputs is also the same.

  The consensus service can have different implementations. In version v1.4, Fabric designed the consensus service as a pluggable module, allowing different consensus options to be configured based on different application scenarios. Currently, Fabric provides three modes of implementation: Solo, Kafka, and Raft.

  Solo is a simple sequential service deployed on a single node, mainly used for development testing, and it only supports single chain and single channel. Kafka is a cluster consensus service that supports multiple channel partitions and can tolerate crash faults (CFT). It tolerates partial node failures but cannot tolerate malicious nodes. Its basic implementation is based on Zookeeper services, requiring that the total number of nodes in the distributed environment meets n ≥ 2f + 1, where f is the number of failed nodes. Raft follows the "leader and follower" model, where each channel elects a "leader," whose decisions will be replicated to the "followers," supporting CFT. As long as the total number of nodes meets n ≥ 2f + 1, it allows for some nodes, including the leader, to fail. Compared to the Kafka-based consensus service, Raft should be easier to set up and manage, and its design allows organizations to contribute nodes for decentralized consensus services.

• Analyzing blockchain technology from its underlying construction, it can be viewed as a shared ledger technology. The ledger is a core component of the blockchain, storing all historical transaction and state change records. In Fabric, each channel corresponds to a shared ledger, and each peer node connected to the shared ledger can participate in the network and view ledger information, meaning that it allows all nodes in the network to participate in and view ledger information. The information on the ledger is publicly shared, and a copy of the ledger is maintained on each peer node. Figure 4.9 illustrates the structure of the Fabric ledger.

Shared Ledger Structure

From the figure, it can be seen that the shared ledger is stored locally in the form of a file system. The shared ledger consists of two parts: the Chain part, which has a chain structure, and the State part, which stores state data on the right side of the figure. The Chain part stores information about all transactions, which can only be added and queried, not deleted or modified. The State part stores the latest values of all variables in the transaction log, as it represents the latest values of all variable key-value pairs in the channel, sometimes referred to as the "world state."

Contract code calls execute transactions to change the current state data, and to enable efficient interaction of these contract codes, the latest key-value data is stored in the state database. The default state database uses Level DB, but it can be switched to Couch DB or other databases through configuration.

The chaincode service provides a secure and lightweight way to sandbox the execution of contract code on validation nodes, offering secure container services and secure contract code registration services. Its runtime environment is a "locked" and secure container, where the contract code is first compiled into a standalone application running in an isolated Docker container. During contract code deployment, a set of signed Docker base images for smart contracts will be automatically generated. In the Docker container, the interaction process between the contract code and peer nodes is illustrated in the figure.

The steps are as follows.

(1) After the peer node receives a contract code execution request from the client, it interacts with the contract code through gRPC, sending a contract code message object to the corresponding contract code.

(2) The contract code executes the Invoke() method, performing GetState() and PutState() operations, requesting the ledger state database from the peer node and sending the pre-commit state of the ledger. To read and write private data, it uses the GetPrivateData() and PutPrivateData() methods.

(3) After the contract code executes successfully, it sends the output results back to the peer node, and the endorsement nodes sign the input and output information, responding to the client once completed.

From the architectural interpretation, it can be seen that the chaincode service is a core component of the Fabric architecture. This section will further study the contract code running in the chaincode service, introducing how to write, deploy, and invoke specific contract code.

The chaincode is a piece of code running on the blockchain, representing the implementation of smart contracts in Fabric. Additionally, in Fabric, the chaincode is the only source of transaction generation. The shared ledger is a continuously growing hash chain formed by connecting blocks, and each block contains all transaction information represented in a Merkle tree data structure, making transactions the most basic entity unit on the blockchain. So how are transactions generated? Transactions can only be generated through operations invoked by chaincode, making chaincode a core component of Fabric and the only channel for interacting with the shared ledger.

Currently, Fabric supports writing chaincode using Java, Go, and Node.js languages by implementing interfaces. According to Fabric's design, the shim package located in the /core/chaincode directory provides the SDK for chaincode development, theoretically allowing for independent use, but currently may not be well independent due to the need to call certain other dependent modules.

The chaincode in Fabric runs on peer nodes, and operations related to chaincode, such as deployment, installation, and invocation, are also performed on peer nodes. Chaincode is installed and initialized on peer nodes in the Fabric network through SDK or CLI, enabling interaction between users and the shared ledger of the Fabric network. Currently, there are two modes of operation for chaincode nodes:

General mode and development mode.

The general mode is the default mode of the system, where chaincode runs in Docker containers. Using Docker containers to run the Fabric system provides an isolated environment for the operation of the Fabric system and chaincode, enhancing the overall security of the system. However, in this mode, the development and debugging process for developers is very complex and cumbersome, as every time code is modified, the Docker container needs to be restarted, which greatly reduces the efficiency of program development.

Therefore, considering the efficiency of developers, Fabric provides another operating mode, namely the development mode. In development mode, chaincode no longer runs in Docker containers but is directly deployed, run, and debugged locally, greatly simplifying the development process.

Chaincode is one of the most important parts of Fabric development, enabling interaction and operation of entities such as ledgers and transactions, while implementing various business logic. Currently, chaincode supports being written in Go, Java, and Node.js languages, by implementing the chaincode interface. Below, we will introduce it using Go language as an example.

The structure of chaincode mainly includes the following three aspects.

1. In Fabric v1.4, the chaincode interface includes two methods: Init() method and Invoke() method. The Init() method is called when the chaincode is deployed for the first time, somewhat similar to a constructor in a class. As its method name suggests, the Init() method generally performs some initialization operations required by the chaincode. The Invoke() method is called when invoking the chaincode method to perform actual operations, with each call treated as an execution of a transaction. The detailed transaction process will be introduced in section 4.6. The interface code for chaincode in Go language is as follows:

Type Chaincode interface {
    // Initialization work, generally called only once
    Init(stub ChaincodeStubInterface) pb.Response
    // Query or update world state, can be called multiple times
    Invoke(stub ChaincodeStubInterface) pb.Response
}

When the chaincode's Init or Invoke interface is called, Fabric passes the shim.ChaincodeStubInterface parameter to the chaincode and returns the pb.Response result. These parameters can be manipulated through API methods to operate ledger services, generate transaction information, or invoke other chaincode.

Currently, API methods are defined in the shim package located in the /core/chaincode directory and can be generated using the following command:

godoc github.com/hyperledger/fabric/core/chaincode/shim

The main API methods can be divided into six categories: state read/write operations, args read/write operations, transaction read/write operations, private data read/write operations, inter-chaincode calls, and event settings. Table 4.2 presents these methods and their corresponding functions.

API Methods and Functions

Chaincode returns information in the form of protobuffer, defined as follows:

message Response {
// Status code
    int32 status = 1;
    // Response message
    string message = 2;
    // Response content
    bytes payload = 3;
}

Chaincode will also return event information, including Message events and Chaincode events, defined as follows:

messageEvent {
    oneof Event {
        Register register = 1;
        Block block = 2;
        ChaincodeEvent chaincodeEvent = 3;
        Rejection rejection = 4;
        Unregister unregister = 5;
    }
}
messageChaincodeEvent {
    string chaincodeID = 1;
    string txID = 2;
    string eventName = 3;
    bytes payload = 4;
}

Once the development of the chaincode is completed, there are two ways to interact with the chaincode: through the SDK or through CLI commands. The interaction through CLI commands will be introduced later, while the interaction through the SDK can be referenced.

After writing the chaincode, it is essential to understand how to deploy and invoke the chaincode. To perform deployment and related operations, it is necessary to start the Fabric system. Fabric provides a CLI interface that supports command-line operations related to peer nodes. Through the CLI interface, Fabric supports starting and stopping peer nodes, various operations related to chaincode, and operations related to channels.

The current CLI commands supported by Fabric are shown in Table 4.3.

Among them, logging getlevel, logging setlevel, and logging revertlevels are not recommended for use and will be removed in subsequent versions.

Additionally, the following command can be used to view more information related to the peer command.

# This command requires
cd /opt/gopath/src/github.com/hyperledger/fabric
build /bin/peer

# Or enter the CLI container after starting the network
docker exec -it cli bash
# Run the peer command after entering the CLI container
peer

After running the above commands, you will see something like the figure.

The execution process of the chaincode is illustrated in Figure 4.12, with specific introductions as follows.

• The client (SDK/CLI) creates a transaction proposal, including the contract code function and invocation parameters, and sends it to the endorsement node.

• The endorsement node calls methods from the shim package to create the simulated transaction execution content for the chaincode.

• The endorsement node initializes the contract and invocation parameters, generating a read/write operation set based on the keys read and written.

• The endorsement cluster nodes simulate the proposal execution: executing read operations, sending requests to the ledger to query the state database; simulating write operations, obtaining the version number of the key's value, and simulating updates to the state data.

• If the execution returns success, the endorsement operation is performed; if it returns failure, an error code 500 is pushed.

• The endorsement node signs the transaction result and sends the proposal result back to the client (SDK/CLI), including the execution return value, transaction result, endorsement node signatures, and endorsement results (agree or reject).

The content of the chaincode can be viewed in the project/examples/chaincode/ directory for more information.

The official documentation of Hyperledger Fabric analyzes the architecture and transaction endorsement process in Fabric, first introducing the mechanism of the Fabric transaction endorsement process, then describing its general process through a simple case, followed by a detailed analysis of the endorsement process, and finally briefly introducing the endorsement strategies of Fabric and the use of ledger validation and PeerLedger checkpoints.

In the Fabric system, a transaction is a call to chaincode, which may have the following two types.

• Deployment Transaction: A deployment transaction creates new chaincode using a program as a parameter. After successfully executing the deployment transaction, the chaincode is installed on the blockchain.

• Invocation Transaction: An invocation transaction executes chaincode and its provided functions in the context of previously deployed transactions. When successfully executing an invocation transaction, the chaincode executes the specified function, possibly modifying the corresponding ledger's state and returning output.

Transactions executed on the blockchain are packaged into blocks, and the blocks are connected to form a hash chain in the shared ledger. This section will introduce the execution process of a transaction in the Fabric system. To better understand the transaction endorsement process in the Fabric system, this section will first use a simple illustrative case to demonstrate a successful transaction execution process.

First, in this illustrative case, some assumptions need to be made, which are the configuration work required in real development. The assumptions are as follows.

• Node Types: E0, E1, E2, E3, E4, E5 are all Peer nodes, with E0, E1, E2 being the endorsement nodes for this transaction, and the Ordering Service being composed of consensus service nodes.

• Channel Configuration: In this case, there are two channels, where E0, E1, E2, and E3 are all connected to the same channel Channel1, while E4 and E5 are in another channel Channel2.

• Endorsement Policy: E0 and E1 must sign endorsements, while E2, E3, E4, and E5 are not part of the policy.

After making the assumptions, the case process begins, as shown in the figure.

(1) The client application sends a transaction proposal to the endorsement node E0 through the SDK. It is used to receive requests for related functions in the smart contract and then update ledger data (i.e., the asset's key/value). Before sending, the client packages this transaction proposal into a recognizable format (such as protocol buffers on gRPC) and signs the transaction proposal using the user's cryptographic credentials.

(2) The endorsement node E0 receives the transaction proposal sent by the client, first verifying whether the client's signature is correct, then using the parameters of the transaction proposal as input to simulate execution, generating a transaction result containing the execution return value, read operation set, and write operation set (at this point, the ledger will not be updated), and then performing the endorsement operation, attaching anchor information and sending it back to the client. If the data in this transaction proposal contains private data, the endorsement node E0 will first store the private data in its local temporary database, then propagate it to other authorized peer nodes through the Gossip protocol. Only after propagating to a certain number can the endorsement node return the transaction result to the client, which does not carry private data, only the hash value of the private data key-value pairs.

(3) The client wants to further obtain E1's endorsement, so it needs to send the transaction proposal to E1, and at this time, it can decide whether to attach the anchor information obtained from E0.

(4) The endorsement node E1, like the previous E0, verifies the client's signature, and after verification, simulates execution, sending the verified Transaction-valid information back to the client.

(5) The client will continue to wait until it collects enough endorsement information, then broadcasts the transaction proposal and results to the consensus service. The transaction includes readset, signatures from endorsement nodes, channel ID, and the hash value of private data. The consensus service will not read the detailed information of the transaction but will sort the received transaction information by channel and package it into blocks, so the consensus service cannot see private data.

(6) The consensus service will package the agreed transactions into blocks and send them to all nodes connected to this channel. E4 and E5 will not receive any messages because they are not connected to the current transaction's channel.

(7) Each node verifies the received block, checking whether it meets the endorsement policy and whether the state values on the ledger have changed to determine whether the transaction is valid. Upon successful verification, the ledger and world state are updated, and the nodes will notify the client through the event mechanism whether the transaction has been added to the blockchain and whether the transaction is valid. If the block contains the hash value of private data, after successful verification, the private data in the temporary database will be stored in the private database.

In Fabric, a transaction refers to a call to chaincode, and the following will analyze the process of transaction endorsement in detail.

1. Client Sends Transaction Proposal to Designated Endorsement Nodes

   To invoke a transaction, the client sends a PROPOSE message to a selected set of endorsement nodes (these messages may not be sent simultaneously, as in the previous example). Regarding how to choose the set of endorsement nodes, the client can obtain the set of endorsement nodes using the given chaincodeID through Peer, or conversely, can obtain the set of endorsement nodes through the endorsement policy. For example, the transaction will be sent by the client to all relevant endorsement nodes through chaincodeID. Additionally, some endorsement nodes may be offline or may refuse to sign the transaction, so there may be endorsement nodes that do not endorse the transaction. The submitting client will strive to meet the endorsement policy through valid endorsement nodes.

   This section will first introduce the format of the PROPOSE message, followed by possible interaction modes between the submitting client and endorsement nodes.

(1) PROPOSE Message Format

The format of a PROPOSE is PROPOSE = <PROPOSE, tx, [anchor]>, containing two parameters, where the tx transaction message field is mandatory, and the anchor is an optional parameter. Below is a detailed analysis of these two parameters.

The tx parameter contains various information related to the transaction, with the field format as follows.

tx=<clientID, chaincodeID, txPayload, timestamp, clientSig>

• clientID: Submitting client ID

• chaincodeID: ID of the invoked chaincode

• txPayload: Carrier containing transaction information

• timestamp: Timestamp

• clientSig: Client signature

For the txPayload field, the detailed information for invocation transactions and deployment transactions will differ slightly.

If the current transaction is an invocation transaction, the txPayload only contains two fields.

txPayload = <operation, metadata>

• operation: Refers to the function and parameters called in the chaincode

• metadata: Refers to other attributes related to this invocation

If the current transaction is a deployment transaction, the txPayload will also include a policies field.

txPayload = <source, metadata, policies>

• source: Refers to the source code of the chaincode

• metadata: Refers to other attributes related to this invocation

• policies: Refers to policies related to the chaincode, such as endorsement policies

The anchor parameter contains the readset (a set of version-dependent key-value pairs read from the original ledger), which is the versioned dependency in the world state. If the client sends a PROPOSE message with the anchor parameter, the endorsement nodes will also need to verify whether the corresponding key's value matches the local one.

At the same time, the encrypted hash tid of the tx field will be used by all nodes as the transaction identifier (tid=HASH(tx)), and the client will store it in memory while waiting for responses from the endorsement nodes.

(2) Message Modes

Since the client's message needs to be sent to a set of endorsement nodes, the order of sending can be controlled by the client. For example, typically, the client will first send a PROPOSE message to a single endorsement node without the anchor parameter, and after the endorsement node receives it, it will process the message and return it to the client with the anchor parameter attached. The client will then send a PROPOSE message with the anchor parameter to the remaining endorsement nodes. Alternatively, the client may directly send a PROPOSE message without the anchor parameter to the set of endorsement nodes and wait for their responses. The client can freely choose the message mode for interaction with the endorsement nodes.

The endorsement node, upon receiving the client's <PROPOSE, tx, [anchor]> message, will first verify the client's signature. If the verification passes, it will simulate the execution of the transaction content. It is important to note that if the client specifies the anchor field, the corresponding key's value in the local KVS must be verified, and only if it matches the anchor parameter will the endorsement node simulate the execution of the transaction.

The simulated execution will experimentally execute the operations in txPayload by calling the chaincode corresponding to the chaincodeID while obtaining a copy of the world state maintained locally by the endorsement node. After the execution is completed, the endorsement node will update the information of the readset and writeset (which stores state updates), a mechanism also known as MVCC+postimage information in DB databases. The specific key-value operations are as follows.

Given the state s of the endorsement node before executing the transaction, for each key k read by the transaction, (k, s(k).version) will be added to the readset. For each key k modified by the transaction, (k, v') will be added to the writeset, where v' is the updated new value. Additionally, v' can also be the difference relative to the previous value (s(k).value).

After the simulated execution, the peer node will decide whether to endorse the transaction based on the so-called endorsement logic. By default, the peer node will receive the transaction proposal message and simply sign it. However, the endorsement logic can be set, for example, the peer node may interact with legacy systems using tx as input to decide whether to endorse the transaction.

If it decides to endorse the transaction, it will send a <TRANSACTION-ENDORSED, tid, tran-proposal, epSig> message back to the client.

tran-proposal := (epID, tid, chaincodeID, txContentBlob, readset, writeset)

• txContentBlob: Transaction information txPayload

• epSig: Signature of the endorsement node

If it refuses to endorse the transaction, it will send (TRANSACTION-INVALID, tid, REJECTED) message back to the client.

It is important to note that the endorsement node's simulated execution does not change any hash chains or world state information; it only simulates execution and stores the state changes caused by the operations in the writeset.

• Client Collects Transaction Endorsements and Broadcasts Through Consensus Service

  Within a certain time interval, if the client receives enough endorsement messages back from the endorsement nodes (TRANSACTION-ENDORSED, tid, *, *), then the endorsement policy is satisfied, and this transaction will be considered successfully endorsed. It is important to note that at this point, it has not yet been submitted. Otherwise, if sufficient endorsement messages are not received within a certain time interval, the client will abandon the transaction or retry later.

  For successfully endorsed transactions, the client will call the consensus service through the broadcast(blob) method, where blob refers to the endorsement message. If the client does not have the ability to directly call the consensus service, it can choose a trusted peer node to act as a proxy for the call; otherwise, the transaction may be considered invalidly endorsed.

• Consensus Service Delivers Blocks to Peer Nodes

  After the consensus service sorts the transactions and reaches a block, it will trigger the deliver(seqno, prevhash, blob) event and broadcast this block to all nodes connected to Fabric and the same channel.

  After receiving the block broadcasted by the consensus service, peer nodes will perform two types of checks.

  The first type is to verify whether blob.endorsement is valid according to the endorsement policy contained in the chaincode pointed to by (blob.tran-proposal.chaincodeID); the second type, after completing the first type of verification, will verify whether the blob.endorsement.tran-proposal.readset collection is correct.

  For the verification of the readset collection, different methods can be adopted based on consistency and isolation guarantees. If the corresponding endorsement policy is not specified in the chaincode, serialization (serializability) will be the default verification method. For serialization, each key in the readset must correspond to the version in the state, and transactions that do not meet this condition will be rejected.

  If the above verifications pass, the transaction can be considered valid or committed. After verification, the peer node will mark this transaction with 1 in the bitmask of the corresponding peerLedger ledger and apply the updates from the writeset to the state of the Fabric blockchain. If the verification fails, the transaction will be considered invalid, and the peer node will mark this transaction with 0 in the bitmask of peerLedger, and invalid transactions will not trigger any changes or updates.

  Under the guarantees of the consensus service, the above process ensures that all normal peer nodes have the same world state after executing a deliver event. In other words, all correct nodes will receive a completely identical sequence of deliver events. Thus, this transaction process concludes.

The endorsement strategy mechanism provided by Fabric is used to specify the rules for transaction verification by blockchain nodes. Whenever an endorsement node receives a transaction request, the system will verify the validity of the transaction through the VSCC (validation system Chaincode). In the transaction process, a transaction may contain one or more endorsements from endorsement nodes, and the VSCC mechanism will determine the validity of the transaction based on the following rules.

• Whether the number of endorsements meets the requirements;

• Whether the endorsements come from expected sources;

• Whether all endorsements from endorsement nodes are valid (i.e., whether they come from valid signatures of expected certificates).

The endorsement policy is used to specify the above requirements for the number of endorsements and the expected sources of endorsements. Each endorsement policy consists of two parts: principal and threshold gate. The principal P is used to identify the entities expected to sign; the threshold gate T has two input parameters, t representing the number of endorsements, and n representing the list of endorsement nodes, meaning that it meets the condition of t. For example, T(2, 'A', 'B', 'C') indicates that endorsements from more than two of 'A', 'B', 'C' are required. T(1, 'A', T(2, 'B', 'C')) indicates that either an endorsement from 'A' is required or two endorsements from 'B' and 'C' are required.

In the CLI command-line interaction, the endorsement policy is represented in the syntax EXPR([E, E...]), where EXPR has two options AND or OR, with AND indicating "and," meaning each one is required, while OR indicates "or." For example, AND('Org1.member', 'Org2.member', 'Org3.member') indicates that signatures from three groups are requested, while OR('Org1.member', 'Org2.member') indicates that a signature from either of the two groups is sufficient. Meanwhile, OR('Org1.member', AND('Org2.member', 'Org3.member')) indicates two choices: the first is to request a signature from organization 1, and the second is to request signatures from both organization 2 and organization 3.

When interacting with the blockchain using CLI, the -P option can be used after the command to specify the corresponding endorsement policy for the executed chaincode, for example, the following chaincode deployment command:

peer chaincode deploy -C testchainid -n mycc -p $ORDER_CA -c '{"Args":["init","a","100","b","200"]}' -P "AND('Org1.member', 'Org2.member')"

This indicates that deploying the chaincode mycc requires signatures from organizations 1 and 2.

Fabric plans to further enhance and improve endorsement policies in the future. In addition to currently identifying principals through relationships with MSPs, Fabric plans to add the form of organizational units (OU) to fulfill the current certificate functions, while also planning to improve the syntax of endorsement policies to use more intuitive syntax to verify that the ledger is derived from a hash chain containing only valid and committed transactions. In addition to the world state and ledger, peer nodes can maintain a validation ledger.

The VLedger block (vBlock) is a block filtered of invalid transactions, with a dynamic size and can be empty. Since PeerLedger blocks may contain invalid transactions (i.e., transactions with invalid endorsements or invalid version dependencies), these transactions will be filtered out by peer nodes before being added to the vBlock. Each peer node links the vBlock to a hash chain, with each vBlock containing the hash of the previous vBlock, the vBlock number, an ordered list of all valid transactions submitted by the last estimated peer node, the hash of the corresponding block derived from the current vBlock, and the hash of all this information.

The ledger may contain invalid transactions that are not necessarily permanently recorded. However, once a peer node establishes a connection with the corresponding vBlock, they cannot simply discard the PeerLedger block to achieve trimming of the PeerLedger. To facilitate trimming of the PeerLedger, version 1.4 of Hyperledger Fabric provides a checkpoint mechanism: using vBlocks that traverse the peer node network, allowing the checkpoint vBlock to replace discarded PeerLedger blocks. Since there is no need to store invalid transactions and no need to establish the validity of individual transactions when replacing PeerLedger to reconstruct the state, storage space is reduced, and the work of reconstructing the state for newly joined network peer nodes is minimized, but it may only replace the state updates contained in the validation ledger.

Peer nodes periodically perform checkpoints, where CHK is a configurable parameter. Peer nodes broadcast a message <CHECKPOINT, blocknohash, blockno, stateHash, peerSig> to other peer nodes to initiate a checkpoint, where blocknohash is their respective hash, blockno is the current block number, stateHash is the hash of the latest state validated on the blockno block, and peerSig is the signature of the peer. (CHECKPOINT, blocknohash, blockno, stateHash) refers to the validated ledger.

Peer nodes collect checkpoint messages until they receive enough messages with correct signatures (blockno, blocknohash, and stateHash) to establish a valid checkpoint. If blockno > latestValidCheckpoint.blockno, then the peer node should mark latestValidCheckpoint=(blocknohash, blockno), storing the corresponding peer node signature set that constitutes the valid checkpoint in the collection latestValidCheckpointProof, with the state corresponding to stateHash stored in latestValidCheckpointedState, trimming the PeerLedger for block numbers larger than blockno.

The validity policy for checkpoints not only defines when peer nodes can trim their PeerLedger but also defines how many CHECKPOINT messages count as "enough." Here are two feasible methods, which can also be combined.

The first is the Local Checkpoint Validity Policy (LCVP): Given a local policy for peer node p, it can specify a set of peer nodes that p trusts, and their CHECKPOINT messages are sufficient to establish a valid checkpoint.

The second is the Global Checkpoint Validity Policy (GCVP): A globally specified checkpoint validity policy, similar to the local peer node policy, but defined at the system (blockchain) granularity rather than the peer node granularity.

Hyperledger Fabric has been deeply interpreted, helping readers to understand the underlying implementation principles of Fabric. First, it introduced the current development status and management model of Hyperledger and its sub-projects, focusing on Hyperledger Fabric. Secondly, it conducted an in-depth analysis of the Hyperledger Fabric architecture, exploring the architectural composition and characteristics of Hyperledger Fabric from the perspectives of membership service, blockchain service, and chaincode service, providing the design and modular components of the Fabric architecture. Finally, it presented the code structure, invocation methods, and execution processes of chaincode, followed by a detailed analysis of the transaction endorsement process.