The business needs of the blockchain are diverse, and some require that blocks can be added to the blockchain after quickly reaching network consensus and quickly confirming blocks. There are some where relatively slow processing times are acceptable in exchange for a lower level of trust. All industries have different needs and uses in terms of scalability, trustworthiness, legitimacy, workflow complexity, and security. Let's first look at the common module composition in enterprise-level blockchain systems, as shown in Figure 3-1.
From the figure, we can see that some commonly used functional modules are: application, member management, smart contract, ledger, consensus mechanism, event mechanism, system management, etc. The vertical axis represents the content that users or developers are more concerned about. The higher the vertical axis, the more concerned the user is, such as applications and wallets, and the lower the module is the more concerned about the developer, such as the event mechanism. The horizontal axis is from the time dimension, and the left side is the function that you focus on at the beginning until all the functions are completed.
Hyperledger Fabric 1.0 is a general-purpose blockchain technology whose design goal is to use some mature technologies to realize Distributed Ledger Technology (DLT). Hyperledger adopts a modular architecture design and reuses common functional modules and interfaces. The modular approach brings the advantages of scalability and flexibility, reduces the impact of module modification and upgrade, and can make good use of microservices to realize the development and deployment of blockchain application systems. Hyperledger Fabric 1.0 is designed with several features:
1) Module plug-in: Many functional modules (such as CA module, consensus algorithm, state database storage, ESCC, VSCC, BCCSP, etc.) are pluggable, and the system provides a common interface and default implementation, which satisfies Most business needs. These modules can also be expanded upon demand and integrated into the system.
2) Make full use of container technology: Not only nodes use containers as running environments, but chaincodes also run in secure containers by default. Applications or external systems cannot directly manipulate the chaincode, and must forward it to the chaincode for execution through the interface provided by the endorsing node. The container provides a secure sandbox environment for chaincode operation, which isolates the chaincode environment from the environment of the endorsement node. Security issues in the chaincode will not affect the endorsement node.
**3) Scalability: **Hyperledger Fabric 1.0 splits the roles of peer nodes on the basis of version 0.6, including Endorser, Orderer, and Committer. etc. Nodes with different roles have different functions. Nodes can be added to different channels, and chaincodes can run on different nodes, which can better improve the efficiency and throughput of parallel execution.
**4) Security: **Hyperledger Fabric 1.0 provides a blockchain network with authorized access. Nodes jointly maintain member information. The MSP (Membership Service Provider) module verifies and authorizes end users before they can use the blockchain network. Function. The multi-chain and multi-channel design is easy to achieve data isolation, and also provides a secure channel between the application and the chain code to achieve privacy protection.
1
System Logical Architecture
The following figure shows the system logic architecture diagram designed by Hyperledger Fabric 1.0.
The system logic architecture shown in the figure above is divided from different angles. The upper layer provides a standard gRPC interface from the application point of view, and encapsulates SDKs in different languages on the basis of API, including Golang, Node.js , Java, Python, etc., developers can use the SDK to develop blockchain-based applications. The blockchain requires strong consistency. It takes a long time to reach a consensus between each node. It is also developed in an asynchronous communication mode. The event module can execute a predefined callback when a block event or chaincode event is triggered. function. The following is an analysis of several elements that should be paid attention to from the perspective of the application and the underlying layer.
1. Application angle
(1) Identity management
After the user registers and logs in to the system, and obtains the user registration certificate (ECert), all other operations need to be signed by the private key associated with the user certificate. The message recipient will first perform signature verification before proceeding with subsequent message processing. Network nodes will also use the issued certificates, such as system startup and network node management, which will authenticate and authorize user identities.
(2) Ledger management
Authorized users can query the ledger data (ledger), which can be queried in various ways, including querying blocks based on block numbers, querying blocks based on block hashes, querying blocks based on transaction numbers, and querying based on transaction numbers. Transactions, you can also obtain the queried blockchain information based on the channel name.
(3) Transaction management
The ledger data can only be updated through transaction execution. After the application submits the transaction proposal (Proposal) through transaction management and obtains the transaction endorsement (Endorsement), it submits the transaction to the ordering service node, and then packs and generates a block. The SDK provides an interface that uses the user certificate to generate the transaction number locally. Both the endorsement node and the accounting node will check whether there are duplicate transactions.
(4) Smart contracts
Implement "Programmable Ledger", execute submitted transactions through chaincode, and implement blockchain-based smart contract business logic. Only smart contracts can update the ledger data, and other modules cannot directly modify the state data (World State).
2. Bottom view
The following content is from the perspective of the bottom layer of Hyperledger Fabric 1.0, how to implement distributed ledger technology and provide blockchain services for applications.
(1) Member management
MSP (Membership Service Provider) abstracts member management. Each MSP will establish a set of Root of Trust Certificate (Root of Trust Certificate) system, use PKI (Public Key Infrastructure) to authenticate membership, and verify that member users submit requests. sign. Combined with Fabric-CA or a third-party CA system, it provides member registration functions and manages membership certificates, such as certificate addition and revocation. The registered certificates are divided into registration certificate (ECert), transaction certificate (TCert) and TLS certificate (TLS Cert), which are used for user identity, transaction signature and TLS transmission respectively.
(2) Consensus service
In the distributed node environment, it is necessary to achieve the consistency of the blocks of different nodes on the same chain, and at the same time to ensure that the transactions in the blocks are valid and orderly. The consensus mechanism is completed in three stages: the client submits a proposal to the endorsement node for signature endorsement, the client submits the endorsed transaction to the ordering service node for transaction ordering, generates a block and an ordering service, and then broadcasts it to the accounting node to verify the transaction Then write to the local ledger. The P2P protocol of network nodes adopts Gossip-based data distribution, which uses the same organization as the transmission range to synchronize data to improve the efficiency of network transmission.
(3) Chaincode service
The implementation of smart contracts relies on a secure execution environment to ensure secure execution and isolation of user data. Hyperledger Fabric uses Docker to manage common chaincodes, providing a secure sandbox environment and image file repository. The advantage is that it is easy to support chain codes in multiple languages and has good scalability. Docker's solution also has its own problems, such as higher requirements on the environment, more resources, low performance, and compatibility issues with Kubernetes, Rancher and other platforms in the implementation process.
(4) Security and Password Services
Security issues are a concern for enterprise-level blockchains, especially in projects that focus on national security. The underlying cryptographic support is particularly important. Hyperledger Fabric 1.0 specifically defines a BCCSP (BlockChain Cryptographic Service Provider), which enables it to implement basic functions such as key generation, hash operation, signature verification, encryption and decryption. BCCSP is an abstract interface, and the default is a soft-implemented national standard algorithm. At present, the community and many manufacturers are implementing the national secret algorithm and HSM (Hardware Security Module).
Hyperledger Fabric 1.0 has good scalability in its architectural design. It is currently the most active among the many visible blockchain technologies, and is worthy of in-depth study by blockchain technology enthusiasts.
2
Network Node Architecture
The node is the communication subject of the blockchain and is a logical concept. Multiple nodes of different types can run on the same physical server. There are several types of nodes: clients, peer nodes, ordering service nodes, and CA nodes. The following figure shows the network node architecture diagram.
Next, the different node types shown in Figure 3-3 are explained in detail.
1. Client node
A client or application represents an entity operated by an end user and must connect to a peer or ordering service node to communicate with the blockchain network. The client submits a Transaction Proposal to the Endorser, and when enough endorsements are collected, it broadcasts the transaction to the ordering service, sorts it, and generates a block.
2. Peer node
All peer nodes are committers, responsible for validating transactions in blocks from ordering service nodes, maintaining state data and a copy of the ledger. Some nodes will execute the transaction and sign and endorse the result, acting as an endorsement node. Endorsing nodes are dynamic roles that are bound to specific chain codes. Each chaincode will set an endorsement policy when it is instantiated, specifying which nodes are valid after the endorsement of the transaction. It is also an endorsement node only when the application initiates a transaction endorsement request to it. At other times, it is an ordinary accounting node, which is only responsible for verifying transactions and accounting.
Another role of the peer node shown in Figure 3-2 is the leader peer, which represents the node that communicates with the ordering service node and is responsible for obtaining the latest block from the ordering service node and synchronizing it within the organization. It can be forcibly set as the master node, or it can be dynamically elected.
It can also be seen in Figure 3-2 that some nodes are both endorsement nodes and accounting nodes, and can also be endorsement nodes, master nodes, and accounting nodes at the same time, or just accounting nodes. In later chapters, accounting nodes will be used to represent ordinary peer nodes in some places.
3. Ordering service node
The ordering service node (Ordering Service Node or Orderer) receives the transaction containing the endorsement signature, sorts the unpackaged transaction to generate a block, and broadcasts it to the peer node. The ordering service provides Atomic Broadcast, which ensures that nodes on the same chain receive the same message and have the same logical order.
The multi-channel (MultiChannel) of the ordering service realizes the data isolation of multiple chains, ensuring that only peer nodes in the same chain can access the data on the chain, protecting the privacy of user data.
The ordering service can use a centralized service or a distributed protocol. Different levels of fault tolerance can be implemented. The currently officially released version only supports Apache Kafka clusters and provides transaction sorting functions. It only implements CFT (Crash Fault Tolerence, crash fault tolerance), and does not support BFT (Byzantine Fault Tolerance, Byzantine fault tolerance).
4. CA node
The CA node is the Certificate Authority (Certificate Authority) of Hyperledger Fabric 1.0 and consists of server and client components. The CA node receives the client's registration application and returns the registration password for user login in order to obtain the identity certificate. All operations on the blockchain network verify the identity of the user. The CA node is optional, and other mature third-party CAs can be used to issue certificates.
Next notice: In-depth exploration of the typical transaction process of Hyperledger based on Hyperledger technology and applications
Deep dive into blockchain
Hyperledger Technology and Application
blockchain
By Zhang Zengjun, Dong Ning, Zhu Xuantong, Chen Jianxiong
This book is recommended by Brian Behlendorf, Executive Director of Hyperledger, and is written by the blockchain first-line practice team and the core group of Hyperleger members. In-depth explanation of Hyperledger Fabric 1.0's architecture, execution logic, core function implementation, and zero-deployment, and taking ticket cases as an example to explain specific development practices, interspersed with best practices required for development and problem solving.
mechanical industry
publishing house
Huazhang Technology is a brand of Machinery Publishing House. It has published nearly 30 classic series such as "Computer Science Series", and is in a leading position in various sub-fields. Among them, "Java Programming Ideas", "Introduction to Algorithms", "Compilation Principles" ", "Data Mining: Concepts and Techniques", "In-depth Understanding of Computer Systems", "In-depth Understanding of Java Virtual Machines" and other works are like bright pearls in the field of computer books, and they are sold for a long time!
The content of this article is excerpted from Chapter 2 "Hyperledger First Experience" in the book "Deep Exploration of Blockchain: Hyperledger Technology and Application".
Authors: Zhang Zengjun, Dong Ning, Zhu Xuantong, Chen Jianxiong
Thanks for the support and sharing of Huazhang Branch of Machinery Industry Press.
The following is the introduction of our community, all kinds of cooperation, exchanges and learning are welcome:)