Hyperledger Fabric Architecture Overview
Hyperledger Fabric Architecture Overview
fabric version v2.4.1
Hyperledger Fabric has released two major versions since its birth: 1.0 series version (July 2017) and 2.0 series version (January 2020). In September 2016, Fabric released the v0.6.0 preview version . Through this version, the community collected a large amount of feedback and suggestions from practice, mainly focusing on performance, security, scalability and other aspects. The 1.0 series version was launched in July 2017. This version redesigned the overall architecture, improved scalability and security, eliminated performance bottlenecks, and achieved throughput performance of thousands of times per second for the first time. The latest 2.0 series version further improves scalability and security. Chaincode life cycle management has been redesigned to support external chaincodes to decouple Peer and chaincode; at the same time, the consensus mechanism has been expanded to better support consensus algorithms with better scalability such as Raft.
Core features
Currently, in order to achieve a secure, scalable, and easy-to-manage enterprise-level distributed ledger, Fabric’s architectural design mainly includes the following features:
●Adopt the "Endorse -> Order -> Commit" model to decouple order processing and other logic to eliminate the overall bottleneck of the network.
●Transaction nodes are logically divided into roles such as endorsement nodes (Endorser) and accounting nodes (Committer), allowing deployment to be adjusted according to load conditions.
●Supports multi-channel features, and ledger data between different channels are completely isolated from each other. Cooperate with private database and permission management to achieve fine-grained privacy protection.
●Supports a pluggable architecture, including consensus, authority management, encryption and decryption, ledger mechanism, chain code execution and other modules, and supports multiple implementations and multiple contract languages.
●Supports a runtime management interface, which allows you to query the health status and various operating indicators of the system online, and change the log level in real time to facilitate operation and maintenance management.
●Integrated identity certificate management service, providing complete certificate issuance and revocation management functions through the Fabric CA project.
Overall structure
The overall architecture of Hyperledger Fabric includes multiple components such as applications, ledgers, chain codes, blockchain structures, databases, consensus, permission management, digital certificates, and network layers.
Among them, the ledger is the core resource, recording contracts and transaction data. Applications call contracts by initiating transactions to record data in the ledger. The logic of contract execution is implemented through chain code. Multiple nodes work together to form a network, and events that occur during network operation can be notified to applications and even other systems through the event mechanism. Rights management is responsible for appropriate access control throughout the process.
Ledger implementation relies on core blockchain structure, database storage, consensus mechanism and other technologies; chain code implementation relies on container, state machine and other technologies; authority management utilizes the existing PKI system, digital identity certificates, encryption and decryption algorithms, etc. safety technology.
The lowest layer consists of multiple nodes forming a P2P network, interacting with each other through the gRPC channel, and using the Gossip protocol for data synchronization. The hierarchical structure improves the scalability and pluggability of the architecture, and bottom-level developers only need to modify relevant module units during secondary development.
Typical workflow
According to the different characteristics of the workload at each stage of the transaction life cycle, Fabric divides the nodes in the network into three categories: CA nodes, Orderer nodes and Peer nodes. All Peer nodes logically correspond to the accounting nodes in the channel, and some Peer nodes can also serve as endorsement nodes (Endorser). This division of roles allows different types of nodes to focus on the business they are good at.
●Client creation request: The client application uses the SDK to deal with the Fabric network. First, the client obtains a valid identity certificate from the CA in order to join the application channel within the network. Before initiating a formal transaction, a transaction proposal (Proposal) needs to be constructed and submitted to Endorser for endorsement. After the client collects enough endorsement support (determined by the endorsement policy), it can use the endorsement to construct a legal transaction request and send it to the Orderer for sorting processing. The client can also monitor messages on the network through the event mechanism to learn whether the transaction has been successfully received.
●Endorser node endorses: It is mainly provided for client calls to complete the endorsement of transaction proposals (currently mainly signatures). After receiving the transaction proposal from the client, first check the legality and ACL permissions. If the check passes, the transaction will be simulated and the status changes caused by the transaction (recorded in the form of a read-write set, including the key and version of the read status, and the written The key value of the state) is endorsed and the result is returned to the client.
●Committer node updates the ledger: responsible for maintaining the blockchain structure and database (including status database, historical database, index database, etc.). The node regularly obtains the sorted batch transaction block structure from the Orderer or the leader node, and conducts final checks on these transactions before placement (including transaction message structure, signature integrity, whether it is repeated, whether the read-write set version matches, etc.) . After passing the check, the execution result of the legal transaction is written into the ledger, a new block is constructed, the BlockMetadata [2] (TRANSACTIONS_FILTER) metadata in the block is updated, and the legality mark is added. All Peers play the role of Committer.
●Sorting by the sorting node: The Orderer globally sorts all legal transactions in the network and combines the sorted batch of transactions to generate a block structure. Orderer does not need to deal with transaction content.
●CA manages identity certificates: Referring to the PKI architecture, it is responsible for the management of all certificates in the network (issuance, revocation, etc.). The implementation is in a separate fabric-ca project. After the CA issues the certificate, it does not participate in the transaction process on the network.
After these steps, transactions in the network gain consensus and are recorded in the ledger, and no node can overturn or tamper with the transaction history.