Blockchain Technology | The Evolution of Fabric Architecture

Hyperledger Fabric is one of the mainstream open source alliance chain products. Since the opening of the code warehouse on May 12, 2016, it has been almost 4 years since the product has stabilized and its functions have become more and more perfect. Match the requirements in different business scenarios.

Throughout the release process of Fabric, the architecture has undergone significant changes during the v0.6.1-preview version to v1.0.0 version migration. After v1.0.0, some new features have been added to each minor version to support different Business scenarios and the corresponding functions. Next, let's talk about a little thought in the process of fabric evolution from a personal point of view.

 

• Opinion: Facebook enters the encryption market or becomes a positive catalyst for Bitcoin
• Thunder teamed up with Hong Kong University of Science and Technology, Guangdong, Hong Kong and Macau, Dawan District, blockchain cooperation accelerated running
• MGC wallet stolen revelation

#Fabric v0.6

The v0.6 version of the technical architecture stays in the development process for a relatively short period of time. Compared with the current v1.x version, it is not stable and is suitable for testing in the poc phase.

The following figure is the architecture diagram of the Fabric v0.6 version:

In the v0.6 version, it is mainly divided into core modules such as Membership, Consensus, Chaincode, Ledger, P2P, and Event Stream.

-Membership: Responsible for issuing certificates such as E-cert, T-cert, and TLS-cert.

-Consensus: Responsible for the consensus of the entire blockchain, unify the transaction order, and ensure the consistency of the blockchain.

-Chaincode: The chain code (smart contract in the fabric) used to execute transactions in the blockchain network.

-Ledger: Used to store the Transaction log and the Key-Value in the transaction.

-P2P: The underlying network communication layer based on Google's Grpc framework.

-Event Stream: Event subscription publishing component for receiving transactions and block events.

The consensus algorithm used in Fabric v0.6 is the PBFT algorithm (Practical Byzantine Fault Tolerance), which can avoid Byzantine problems in scenarios with low trust. However, due to the limitations of the algorithm itself, n>=3f+1 can tolerate a Byzantine node, so in the v0.6 version, the number of vp nodes is at least 4. In the v0.6 version, the node roles are classified into three types: VP (Validating Peer), NVP (None validating Peer), and Membership nodes for issuing certificates. Of course, Fabric started with the docker-based runtime environment from the first version of v0.6.0-preview, which reduced the trouble for deployment and shielded the operating system. Of course, the most important point may be due to the design mechanism of Chaincode. The deployment and operation of the entire production environment chain code is based on docker, perhaps due to the stability of docker and the relatively safe operating environment. Fabric's smart contract design can theoretically support any development language as long as the corresponding interface is implemented. Because it is based on a two-way communication between the Peer node and the chain code container to complete the corresponding interaction.

The following figure is a network topology diagram of the Fabric v0.6 version:

In this picture, there are two roles of VP and NVP. NVP will share part of the work of VP here, receive the transaction sent from the client to check and forward the transaction request to the consensus node VP, and the VP node will make a real consensus. , the transaction is written to the block. Here NVP can share the pressure of the consensus node VP to process transactions, which can improve the performance of the consensus.

The following picture shows the trading flow chart of Fabric v0.6:

The application needs to apply for the E-cert to the Membership, apply for the T-cert through the E-cert, and send the signed client transaction to the VP node for the three-phase consensus by the private key corresponding to the T-cert. After the completion, each node will pass the Chaincode. The transactions in the block are executed in order and the books are updated.

Fabric v0.6 version may not continue to maintain due to the 1.0 architecture refactoring, but compared to the 1.0 version of the architecture, the blockchain role is relatively symmetric compared to the 1.0-1.4 version. There is no centralized Kafka presence, and there is a more rational peer design in the actual scenario.

# Fabric v1.x

When Fabric was in version 1.0, the architecture was refactored. Compared to the v0.6 version, there was a disruptive change. The functional modules were closed, with better scalability and performance. Level of security isolation, consensus algorithm pluggable, higher operability, richer features, better experience for developers, Membership in v0.6 is also upgraded to a separate Fabric CA project.

In the Fabric v1.x version, the functions of the nodes are split, the accusations of each node are clarified, and the trust hypothesis of the endorsement and the trust hypothesis of the sorting are split. The biggest change is that the execution of the transaction is advanced in the consensus process, and the Endorser node performs the simulation execution and endorsement. The sorting node Orderer will uniformly package all the transactions and distribute them to the Committer node. The advantage of this design is that it can perform parallel and unrelated transactions and transactions in different channels in parallel to improve the execution speed of the transaction. In the v0.6 version, it is impossible to execute in parallel. In 0.6, the sorting and packaging are unified, and then the transactions are executed in order, even if the transactions are irrelevant before and after. The following figure also exemplifies a network topology in Fabric v1.x.

The following figure is the architecture diagram of the Fabric v1.x version:

In the v1.x version, it is mainly divided into roles such as Fabric CA, Endorser, Committer, Orderer, and Application.

-Fabric CA: Responsible for maintaining certificates in the entire fabric, including issuing, revoking, and renewing visas.

-Endorser: Responsible for endorsing the transaction proposal sent by the client.

-Comitter: Responsible for verifying the validity of the block and writing the block to the ledger.

-Orderer: Responsible for globally unique sorting and packaging of all transactions.

-Application: Used to send a transaction proposal, collect the response, and send the package transaction to the Orderer sort service node.

In version 1.0 and later, the client application first applies to the Fabric CA for the access certificate in the fabric required by the user, for signing the proposal and the transaction, and then generating a proposal (Proposal) by the client (Application). The general application will be sent to the endorsement node for simulation execution and endorsement by means of a series of SDK generated Proposal provided by the current Fabric. The endorser Endorser will perform corresponding verification, and then submit the proposal to the corresponding chain code Chaincode for simulation execution. Then, the endorsement endorser endorses the execution result and returns the endorsement Response to the client program Application.

Then, after the client collects the Proposal Response that conforms to the endorsement strategy, it encapsulates it into a transaction Transaction, calls the Broadcast interface of the sort node Orderer, and sends the transaction to the Orderer, at v1.0-v1.4. In the version, the production environment only has a sorting and packaging method based on the distributed message queue Kafka. The producer as a producer uniformly sends the transaction to the Topic Partition corresponding to each channel Channel for global uniform ordering, and each sorting node is based on the same The dicing rule pushes the Deliver from Kafka to the Leader Peer connected to it (in the case of a good network environment, there is only one leader per organization). After receiving the block, the Leader Peer will pass the block. The Gossip protocol is broadcast to the rest of the nodes in the organization. Each Committer will check the block after receiving the block, including the signature, endorsement policy, and checksum of the read/write set. When the check is correct, the commit is submitted, submitted to the ledger, and the world status is updated at the same time. Applications that subscribe to the event receive a message notification from the Event Hub.

The following image is a simplified version of the transaction process for Fabric v1.x:

In addition, after v1.0, Fabric emphasized the concept of organization. At the level of the Peer node, each organization needs to configure one or more Anchor Peer nodes to represent the organization's starting point and network in the entire blockchain network. The organization exchanges node information so that each node can grasp the node information of the entire network.

At the same time, after v1.0, Fabric has joined the multi-channel technology (Muti-channel), enabling multiple books to run in a fabric network, and the logic isolation between each channel is not affected, as shown in the following figure. The color lines represent a logical channel. Each Peer node can be added to different channels. Each channel has an independent ledger, world status, chain code, and Topic in Kafka. The messages between channels are isolated and do not affect each other. of.

In Fabric v1.x, multi-channel technology is used to make a global channel at the business logic level, which is used to isolate channels of different services, so that transactions of different services are stored in nodes corresponding to different channels, and channel technology is implemented. Mainly implemented in the Orderer, the Orderer distinguishes the transactions from different channels, and in the Peer node, the MSP is used to check the messages of different channels to determine whether the message belongs to a certain channel, and is combined by the Orderer and the Peer. Form a logical channel technology.

In the endorsement and submission verification phase, Fabric proposed two system chain codes, ESCC and VSCC, where ESCC: used to endorse the results of chain code execution; VSCC: used to process transactions in the received block Test.

In terms of storage, v1.0 is also optimized. The storage design is divided into two parts. One part is the storage of the block. The File System is the traditional file system. The reason why the file storage is designed here is: Blocks in the blockchain are constantly added backwards, that is, they are constantly append, and there is no random write. If the Key-Value database is used, there may be data compression or related indexing algorithm consumption. In this scenario. File System will be better than KV database, so whether it is Orderer or Peer, for Block storage, File System is used for storage. For Block index, Level DB is used for storage maintenance, which will be based on BlockHash, BlockNumber, TxId, etc. Stored as a Key, and Value is the Segment number + offset (offset) where the block or transaction is located, used to quickly locate the required block or transaction based on the Key.

In addition, for the storage of the world state, here refers to State DB, after v1.0 can be stored with Level DB or Couch DB, according to the complexity of the stored data, and the business logic of the chain code can choose different databases, such as Indexing for Json data can be stored using Couch DB. If it is a normal Key-Value, it can be stored with Level DB.

The following figure shows the design of the storage after Fabric v1.0:

The fabric after Fabric v1.0, from Fabric v0.6 to v1.0, Fabric CA is derived from the Membership module, and undertakes the issuance, renewal and revocation of the entire digital certificate of the Fabric network as an independent service. presence. At the same time, Fabric CA supports multi-level CA to ensure the absolute security of the root CA. At the same time, the storage part is also pluggable. You can choose MySQL, LDAP, Postgres, etc. You can use HA Proxy for load balancing.

#Fabric v1.1

 

The main new features of Fabric v1.1 include:

– Fabric CA's CRL

– Block and transaction event push

– Added two-way TLS communication between all components

– Node.js Chaincode chain code support

– Chaincode API adds creator identity

– Performance has improved significantly relative to v1.0

#Fabric v1.2

Fabric v1.2 began to have a larger feature to appear:

Private Data Collections: This feature has to say that it solves the pain points of many projects in terms of privacy protection, and also reduces the complex design of many projects in the business layer for privacy protection.

Service Discovery: The service discovers this feature, which gives the client more flexibility and operability, and can dynamically sense changes in the entire fabric network.

Pluggable endorsement and validation: Pluggable endorsement and validation mechanisms, implemented using the Go Plugin mechanism, avoiding the need to recompile the source code before, increasing flexibility.

#Fabric v1.3

Fabric v1.3 also adds a very useful feature:

Identity Mixer-based MSP Implementation: An anonymous and non-linkable identity based on zero-knowledge proof. This feature replaces the T-cert in v0.6.

Key-level endorsement policies: A more granular endorsement strategy, refined to a specific key-value, more flexible, not limited to a chain code program for endorsement.

New Java Chaincode: At this point, v1.3 supports Go, Node.js, Java and other Chaincode, providing developers with more choices.

Peer channel-based event services: Channel-level event subscription mechanism, which has been released since v1.1, was officially released in v1.3. At this point, the old Event Hub was officially deprecated.

#Fabric v1.4

Fabric v1.4 is a milestone version and is the first LTS version (Long Term Support version):

Increased operability and maintainability: an interface with an open log level setting, an inspection interface for an open node health state, and a collection interface for open node data indicators.

Improved the programming model of the Node SDK, simplifying the developer's code complexity and making the SDK easier to use.

Enhancement of Private Data: There is no need to add chain code logic for subsequent access control that allows access nodes to obtain previous private data and add client-level private data.

For Fabric's architectural changes, there has been a relatively large change from v0.6 to v1.0, and v1.0—>v1.4 has also collected a lot of demand from the industry. Perfect, added a lot of useful features, the current small iterations of the v1.4 version will fix the existing bugs, and the new big feature will be released in the future v2.0 version, so stay tuned.

Author: Zhang Tong Xuan, fun chain technology platform Labs Innovation

We will continue to update Blocking; if you have any questions or suggestions, please contact us!