Introduction#
The previous article "Detailed Explanation of Hyperledger Fabric Architecture" provided a detailed interpretation and analysis of the architecture and working principles of Fabric. As an enterprise-level blockchain system, how does it build networks based on complex business requirements, what security issues exist during operation, and how does Fabric prevent them through mechanisms?
This article will use examples to illustrate how a simplified enterprise Fabric network is built and analyze its network and security system. If there are any errors or omissions, please feel free to provide feedback.
Hyperledger Fabric Network#
Hyperledger Fabric Application Scenarios#
Business Roles#
Let's assume there is an application scenario that uses the Fabric system.
There are 4 organizations: R1, R2, R3, and R4. R4 is the network initiator, and R1 and R4 jointly serve as network administrators.
The system has 2 channels, namely C1 and C2. R1 and R2 use channel C1, and R2 and R3 use channel C2.
Application A1 belongs to organization R1 and runs on channel C1. Application A2 belongs to organization R2 and runs on both channel C1 and channel C2. Application A3 belongs to organization R3 and runs on channel C2.
P1, P2, and P3 are nodes of organizations R1, R2, and R3, respectively.
The ordering node is provided by O4 and belongs to organization R4.
Construction Process#
Compared to real-world business application scenarios, the roles and business logic in this scenario are simplified but suitable for understanding the functions and interactions between different nodes and roles. Next, I will explain the process of building the network step by step.
Create the network and add network administrators
Each organization needs to join the network with certificates issued by the CA organization in MSP, so each node needs to have the corresponding CA.
As the network initiator, R4 needs to configure the network and establish the ordering node O4 first! After the network is created, add R1 as the network administrator so that R1 and R4 can configure the network (NC4).
Define consortium and create channels
R1 and R2 will interact with each other through C1, so it is necessary to define a consortium in the network. Since both R1 and R4 can configure the network now, they can both define the consortium.
Then create channel C1 for this consortium (connected to ordering service O4).
Join nodes, deploy smart contracts, and applications
Node P1 joins the established channel C1 and maintains a ledger L1.
At this point, smart contracts can be installed and instantiated on the node. The smart contract of Fabric is called chaincode. Installing the chaincode on the node's file system is called installing the smart contract. After installation, the chaincode needs to be started and instantiated on a specific channel. At this point, the application can send transaction proposals to endorsement nodes (subject to the endorsement policy set by the chaincode).
As shown in the following figure, after node P1 installs chaincode S5 and instantiates it on channel C1, it can respond to chaincode invocations from application A1. After node P2 installs chaincode S5 and instantiates it on channel C1, it can respond to chaincode invocations from application A2.
Each node in the channel is a committing node, which can receive new blocks (from ordering nodes) for verification and commit them to the ledger. Nodes that have deployed the chaincode can become endorsement nodes.
Define a new consortium and create a new channel
Define a new consortium in the network and join channel C2.
Join new nodes and deploy smart contracts and applications
It is worth noting that some nodes may join multiple channels and play different roles in different businesses. The other processes are the same as above.
Network construction completed
Fabric uses mechanisms such as access control and channels to improve system efficiency and ensure security and privacy in complex business scenarios. Powerful chaincode and customizable endorsement policies ensure system scalability and the ability to handle complex business logic.
Hyperledger Fabric Security Analysis#
Fabric Security Mechanisms#
Fabric has designed many mechanisms to ensure the security of the system.
System Configuration and Member Management#
Unlike public chains such as Bitcoin and Ethereum, joining the Fabric network requires permission verification. Fabric CA uses the X.509 certificate mechanism for member management to ensure their permissions and prevent potential spoofing attacks.
Existing system members need to establish rules for new member admission, such as majority voting. Existing members also need to decide on updates and changes to the network and smart contracts, which can greatly prevent malicious nodes from compromising system security. Existing nodes cannot upgrade their permissions on their own. In addition, decisions need to be made regarding the general data model and other settings of the system.
The network transmission in Fabric uses TLSv1.2, which ensures the security of data. Operations in the system, such as initiating transactions and endorsements, are recorded using digital signature technology, making it easy to trace malicious operations. However, it is worth noting that ordering nodes can access transaction data from all nodes in the system. Therefore, the setting of ordering service nodes is particularly important for the security of the entire system. The fairness of ordering service nodes will greatly affect the operation of the entire system and even determine whether the entire system is trustworthy. Therefore, careful selection should be made based on business and system structure.
In public chain systems, all nodes have copies of the blockchain ledger and execute smart contracts. In the Fabric system, business-related nodes form node groups and store ledgers related to their transactions (business). The updating of ledgers through chaincode is also limited to the scope of the node group, thereby ensuring the stability of the entire system.
The execution of smart contracts, known as transactions in Fabric system, must also maintain consistency. Cryptographic techniques are often used to prevent tampering of transactions, such as using SHA256, ECDSA, etc., to detect modifications. Fabric adopts a modular and pluggable design, separating the execution, verification, and consensus of transactions. Therefore, different consensus mechanisms or rules can be adopted, which not only allows the selection of different consensus mechanisms according to requirements but also improves system security.
These configurations and rules collectively determine the security of the system and need to be balanced in terms of business requirements, efficiency, and security.
Smart Contract Security#
Fabric's chaincode needs to be installed and instantiated on nodes. Installing chaincode requires CA verification, so attention should be paid to permission management. After it is started, it runs in an independent Docker container, which is more lightweight. However, because it can access the Fabric network, if it has not undergone strict code auditing and network isolation, it can cause some malicious consequences.
Fabric's chaincode can be written in various general-purpose programming languages such as Go and Java, which gives the system greater scalability and makes it easier to integrate with existing systems and tools. However, because the execution result is deterministic, certain features of programming languages (such as random numbers, system timestamps, pointers, etc.) may cause different execution results on different endorsement nodes, resulting in system inconsistency. In addition, because chaincode can access external web services, system commands, file systems, third-party libraries, etc., it can also pose potential risks. Therefore, chaincode developed using these general-purpose languages needs to be relatively independent and undergo enhanced code auditing to avoid security risks caused by programming languages.
Transaction Privacy#
Fabric uses channel mechanism to divide the entire system into multiple sub-blockchains (ledgers). Only nodes that join the channel can view and store transaction information, but ordering nodes can see it.
How can privacy of some private data be ensured in the channel?
Fabric provides a way to store private data, allowing nodes in the channel to select specific data sharing objects (nodes).
In this mechanism, the actual data is sent to the specified nodes via the gossip protocol and stored in a private database. Only authorized nodes can access it through chaincode. Since this process does not involve the ordering service, ordering nodes cannot obtain the data.
The data propagated, ordered, and written to the ledger within the system is a hashed and encrypted version, so transactions can still be verified by each node. However, due to the nature of hashing, the original data can be effectively protected from leakage.
However, it is worth noting that if data needs to be used during the transaction simulation process on endorsement nodes, additional mechanisms need to be adopted to ensure the readability of data for endorsement nodes and the invisibility to other nodes (such as asymmetric encryption).
Conclusion#
The above is an analysis of the construction of the Hyperledger Fabric network and its security system. Next, we will start learning Go and chaincode development to gain a deeper understanding through project practice!
References#
- FITE3011 Distributed Ledger and Blockchain, Allen Au, HKU