The business requirements of blockchain are diverse, and some require that a block can be added to the blockchain only after a quick network consensus and quick confirmation of the block. Some accept relatively slow processing times in exchange for a lower level of trust. Different industries have different needs and uses for extensibility, credibility, legitimacy, workflow complexity, and security. Let’s take a look at the common modules in an enterprise blockchain system, as shown in Figure 3-1.
As can be seen from the figure, some common functional modules are: application, member management, smart contract, ledger, consensus mechanism, event mechanism, system management, etc. The vertical axis represents what users or developers care about most, the higher the user cares about most, such as apps and wallets, and the lower the developer cares about most, such as event mechanics. The horizontal axis is viewed in time, with the left side showing the features you focus on until all the features are completed.
Hyperledger Fabric 1.0 is a general-purpose blockchain Technology designed to implement Distributed Ledger Technology (DLT) using a number of proven technologies. Super ledger adopts modular architecture design, reuse common function modules and interfaces. The modular approach brings advantages such as scalability and flexibility, reduces the impact of module modification and upgrade, and makes good use of microservices to realize the development and deployment of blockchain application systems. The Hyperledger Fabric 1.0 design has several features:
**1) Module plug-in: ** Many functional modules (such as CA module, consensus algorithm, state database storage, ESCC, VSCC, BCCSP, etc.) are plugable, the system provides a common interface and default implementation, which meets most business requirements. These modules can also be extended and integrated into the system as required.
**2) Make full use of container technology: ** Not only nodes use containers as running environment, chain codes also run in secure containers by default. An application or external system cannot manipulate the chain code directly and must do so by forwarding it to the interface provided by the endorsement node. Container provides a safe sandbox environment for chain code operation, which separates the environment of chain code from that of endorsement node. Security problems in chain code will not affect endorsement node.
**3) Scalability: **Hyperledger Fabric 1.0 split the roles of Peer nodes on the basis of version 0.6, including Endorser node, Orderer node, Committer node, etc. Nodes with different roles have different functions. Nodes can be added to different channels, and chain codes can run on different nodes, which can better improve the efficiency and throughput of parallel execution.
**4) Security: **Hyperledger Fabric 1.0 provides the blockchain network with authorized access. The nodes jointly maintain member information, and the Membership Service Provider (MSP) module verifies and authorizes end users to use the blockchain network function. Multi-chain and multi-channel designs can easily achieve data isolation, and also provide a secure channel between the application and chain code to achieve privacy protection.
1
System logical architecture
The logical architecture diagram for Hyperledger Fabric 1.0 is shown below.
The system logical architecture diagram shown in the figure above is divided from different perspectives. From the perspective of application programs, the upper layer provides a standard gRPC interface and encapsulates the SDK of different languages on the basis of API, including Golang, Node.js, Java, Python, etc. Developers can use THE SDK to develop blockchain-based applications. Blockchain requires strong consistency, which requires a long execution time to reach consensus among nodes. It is also developed in the mode of asynchronous communication. The event module can execute pre-defined callback functions when triggering block events or chain code events. Here are a few factors to focus on, both from an application and an underlying perspective.
1. Application perspective
(1) Identity management
After a user registers and logs in to the system, the user registration certificate (ECert) is obtained. All other operations need to be signed by the private key associated with the user certificate. The message receiver performs signature verification before subsequent message processing. Network nodes also use issued certificates, such as system startup and network node management for user identity authentication and authorization.
(2) Account management
Authorized users can query ledger data in a variety of ways, including querying blocks by block number, querying blocks by block hash, querying blocks by transaction number, querying transactions by transaction number, and retrieving queried blockchain information by channel name.
(3) Transaction management
Ledger data can only be updated through transaction execution. After submitting a Proposal and obtaining an Endorsement through transaction management, the application will submit a transaction to the ranking service node, and then package and generate blocks. SDK provides an interface to generate transaction numbers locally using user certificates, and endorsement nodes and billing nodes will verify whether repeated transactions exist.
(4) Smart contracts
Implement a “Programmable Ledger” that executes submitted transactions through chain codes, enabling blockchain-based smart contract business logic. Only smart contract can update the ledger data, other modules cannot directly modify the World State data.
2. Bottom Angle
The following is a look at how distributed ledger technology can be implemented to provide blockchain services to applications from a Hyperledger Fabric 1.0 underlying perspective.
(1) Member management
Membership Service Provider (MSP) abstracts member management. Each MSP establishes a Root of Trust Certificate system. The Public Key Infrastructure (PKI) is used to authenticate members and verify the signatures of member users to submit requests. Combine with fabric-CA or third-party CA systems to register members and manage member certificates, for example, adding and revoking certificates. 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 services
In the distributed node environment, it is necessary to achieve the consistency of blocks of different nodes on the same chain, and at the same time ensure that the transactions in the block are efficient and orderly. The consensus mechanism is completed in three stages: the client submits the proposal to the endorsement node for signature endorsement, and the client submits the endorsed transaction to the sorting service node for transaction sorting, generating block and sorting service, and then broadcast it to the accounting node to verify the transaction and write it into the local account book. The P2P protocol of network nodes uses data distribution based on Gossip to synchronize data within the same organization and improve network transmission efficiency.
(3) Chain code service
The implementation of smart contracts relies on a secure execution environment to ensure secure execution process and isolation of user data. Hyperledger Fabric uses Docker to manage common chain codes, provide a secure sandbox environment and mirror file repository. Its advantage is easy to support a variety of language chain code, scalability is very good. Docker’s scheme also has its own problems, such as high environmental requirements, high resource occupation, low performance, and compatibility problems with Kubernetes, Rancher and other platforms in the implementation process.
(4) Security and password services
Security is a concern for enterprise blockchain, especially in projects that focus on national security. The underlying cryptography support is particularly important. Hyperledger Fabric 1.0 specifically defines a BCCSP (BlockChain Cryptographic Service Provider), Make it realize key generation, hash operation, signature check, encryption and decryption and other basic functions. BCCSP is an abstract interface, the default is the soft implementation of the GB algorithm, the community and more manufacturers are implementing the gb algorithm and HSM (Hardware Security Module).
Hyperledger Fabric 1.0 is architected to be very scalable and is currently the most active of the many visible blockchain technologies, worthy of further study by blockchain enthusiasts.
2
Network node Architecture
Node is the communication subject of blockchain and is a logical concept. Multiple nodes of different types can run on the same physical server. There are many types of nodes: client, Peer, sort service, and CA nodes. The following figure shows the network node architecture diagram.
Next, explain in detail the different node types shown in Figure 3-3.
1. Client node
The client or application represents an entity operated by the end user and must be connected to a Peer or sequencing service node to communicate with the blockchain network. The client submits a Transaction Proposal to the Endorser node. After collecting enough Endorser, the client broadcasts the Transaction to the sequencing service, conducts sequencing, and generates blocks.
2. The Peer node
All Peer nodes are committers, responsible for verifying transactions from the sequencing service node block and maintaining a copy of the status data and ledger. Some nodes will execute the transaction and endorse the result, acting as endorsement nodes. Endorsement node is a dynamic role, which is bound to a specific chain code. Each chain code will set endorsement strategy during the instantiation to specify which nodes are effective after endorsing the transaction. It is an endorsement node only when the application program initiates a transaction endorsement request to it, and at other times it is an ordinary billing node, which is only responsible for verifying the transaction and billing.
The Peer node as shown in Figure 3-2 also plays the role of Leader Peer, representing the node that communicates with the ranking service node and is responsible for obtaining the latest block from the ranking service node and synchronizing it within the organization. The primary node can be mandatory or dynamically elected.
It can also be seen in Figure 3-2 that some nodes are endorsement node and billing node at the same time, endorsement node, master node and billing node at the same time, or just billing node. In later chapters, there are places where ledger nodes are used to represent ordinary Peer nodes.
3. Sort service nodes
The Ordering Service Node (Orderer) receives the transactions with the endorsement signature, sorts the unpacked transactions to generate blocks, and broadcasts the blocks to the Peer Node. The sorting service provides Atomic Broadcast, which ensures that nodes on the same chain receive the same messages in the same logical order.
The MultiChannel sorting service implements data isolation of multiple chains, ensuring that only Peer nodes of the same chain can access the data on the chain and protecting the privacy of user data.
Sorting services can be centralized or distributed. And Tolerence is now available in Apache Kafka clusters, with transaction sorting, and only CFT (Crash Fault Tolerence). BFT (Byzantine Fault Tolerance) is not supported.
4. CA nodes
The CA node is the Certificate Authority of Hyperledger Fabric 1.0 and consists of server and client components. The CA node receives the registration request from the client and returns the registration password for user login to obtain the identity certificate. All operations on the blockchain network verify the user’s identity. The CA node is optional and can be issued with other mature third-party cas.
Next period: explore the typical transaction flow of Hyperledger technology and application
Explore blockchain in depth
Hyperledger technology and application
Block chain
Zhang Zengjun, Dong Ning, Zhu Xuantong, Chen Jianxiong
The book is recommended by Brian Behlendorf, executive director of Super Ledger, and written by the blockchain front-line practice team and the Core group of Hyperleger members. Hyperledger Fabric 1.0 architecture, execution logic, implementation of core functions, deployment from zero, and a ticket case as an example to explain specific development practices, interweaving the best practices needed for development and problem solving.
Mechanical industry
Press.
Huazang Technology is a brand of China Machine Press. It has published nearly 30 classic series such as “Computer Science Series”, taking a leading position in various subdivisions, including “Java Programming Ideas”, “Introduction to Algorithms”, “Principles of Compilation”, “Data Mining: Concepts and Technology, In-depth Understanding of Computer Systems, In-depth Understanding of The Java Virtual Machine and other books are like brilliant pearls in the field of computer books, which will never be lost!
This article is excerpted from “First Experiences with Hyperledger”, chapter 2 of “Deep Exploration of Blockchain: Hyperledger Technology and Applications”.
Authors: Zhang Zengjun, Dong Ning, Zhu Xuantong, Chen Jianxiong
Thanks to China Machine Press Huazhang Branch for your support and sharing.
The following is our community introduction, welcome all kinds of cooperation, exchange, learning 🙂
