Fabric Learning (2)----Network Structure and Transaction Process

Fabric official documentation: https://hyperledger-fabric.readthedocs.io/en/release-2.2/

0.Preface

The previous article mainly introduced the installation of fabric, but some key concepts and underlying architecture of fabric are not well understood. This article mainly explains some key concepts of fabric, network structure and transaction process.

1. Some advantages of Fabric

1.1 Alliance chain

In traditional permissionless public blockchains (Bitcoin, Ethereum, etc.), almost everyone can participate, and each participant is anonymous. In order to ensure security, the use of POW, POS and other resources consumes a huge amount of money. consensus agreement. Fabric is a consortium chain system . It is a permissioned blockchain where participants know each other and are not anonymous. Permissioned blockchains operate blockchains among a known, identified, and often vetted set of participants who operate under a governance model that engenders a level of trust. Permissioned blockchains provide a way to secure interactions between a group of entities that share a common goal but may not fully trust each other. By relying on the identities of participants, permissioned blockchains can use more traditional Crash Fault Tolerant (CFT) or Byzantine Fault Tolerant (BFT) consensus protocols, which do not require expensive mining.

1.2 New trading structure

Most existing smart contract blockchain platforms follow an order execution architecture where the consensus protocol:

• Verify and order transactions and then propagate them to all peer nodes,

• Each peer then executes the transaction in turn.

Since all transactions are executed sequentially by all nodes, performance and scale are limited. The fact that smart contract code is executed on every node in the system requires sophisticated measures to protect the entire system from potentially malicious contracts to ensure the resilience of the entire system.

Fabric introduces a new transaction architecture we call execute-order-validate . It addresses the resiliency, flexibility, scalability, performance and confidentiality challenges of order execution models by breaking transaction flow into three steps:

• execute transactions and check their correctness, thereby endorsing them,
• Ordering transactions via a (pluggable) consensus protocol
• Validate transactions against application-specific endorsement policies before committing them to the ledger

1.3 Privacy and Confidentiality

In a public, permissionless blockchain network, which utilizes PoW as its consensus model, transactions are executed on every node. This means that neither the contract itself nor the transaction data it processes can be kept secret . Every transaction and the code that implements it are visible to every node in the network. In this case, we replace the confidentiality of contracts and data with the Byzantine fault-tolerant consensus provided by PoW.

Hyperledger Fabric is a permissioned platform that enables confidentiality through its channel architecture and private data capabilities . In a channel, participants on the Fabric network establish a subnetwork where each member can see a specific set of transactions. Therefore, only nodes participating in the channel can access the data of the smart contract (chaincode) and transactions, thus protecting the privacy and confidentiality of both. Private data allows collection between members on a channel, achieving the same protection as a channel without the maintenance overhead of creating and maintaining separate channels.

2.Fabric network structure and introduction

2.1 Network structure

The following shows a typical Fabric network structure on the fabric official website:

You will be very confused when you first see this network architecture because there are too many components. Next, we will introduce the components one by one.

• R1R2R3R4 represents each organization

• O4 represents the sorting node

• P1P2P3 stands for Peer-to-Peer (PEER)

• CA stands for Certificate Authority

• S5 S6 represents the chaincode installed on the peer

• L1 L2 represents the ledger

• CC1 CC2 represents the endorsement policy

• NC4 stands for Network Configuration

**In the above figure, we consider that there are now four organizations R1, R2, R3 and R4 working together to develop a consortium chain. They will build and develop the Hyperledger Fabric network. **R4 has been designated as the network initiator - it has been granted the authority to set the initial version of the network. R4 does not intend to conduct commercial transactions on the Internet. R1 and R2 require dedicated communication throughout the network, as do R2 and R3. Organization R1 has a client application that performs business transactions within channel C1. Organization R2 has a client application that performs similar work in channels C1 and C2. Organization R3 has a client application that can perform this operation on channel C2. Peer node P1 maintains a copy of the ledger L1 associated with C1. Peer node P2 maintains a copy of the ledger L1 associated with C1 and a copy of the ledger L2 associated with C2. Peer node P3 maintains a copy of the ledger L2 associated with C2. The network is managed according to the policy rules specified in the network configuration NC4, and the network is controlled by organizations R1 and R4. Channel C1 is managed according to the policy rules specified in channel configuration CC1; the channel is controlled by organizations R1 and R2. Channel C2 is managed according to the policy rules specified in channel configuration CC2; the channel is controlled by organizations R2 and R3. There is an ordering service O4, which serves as the network management point for N and uses the system channel. The ordering service also supports application channels C1 and C2, which are used to sort transactions into blocks for distribution. Each of these four organizations has a preferred certificate authority.

2.2 Sorting nodes

In the Fabric network, the startup of an ordering service means that the network is formed. In the figure above, O4 represents the ordering node , which was created by organization R4. In the figure above, it was created by R4 through the network configuration policy. It is used to sort all transactions in channels C1 and C2 and maintain consensus. one of the important nodes.

• Transaction data needs to be packaged first and then written into the block (similar to the work of miners in the blockchain)
• Why sort?
  • Solve the double-spending problem.
  • Every transaction initiated will be sorted by the orderer, and a special algorithm will be used to solve the double-spending problem.

In addition to their ranking role, sequencers maintain a list of organizations that are allowed to create channels. This list of organizations is called a "confederation", and the list itself is kept in the configuration of the "orderer system channel" (also called the "ordering system channel"). By default, this list and the channel it resides in can only be edited by subscriber administrators. Note that an ordering service may hold multiple such lists, making federation the vehicle for Fabric multi-tenancy.

2.3 CA

CA is a certificate authority, which is used to issue certificates to administrators and network nodes. Fabric is a permissioned blockchain that requires exactly this kind of identity assurance. CA4 plays a key role in our network as it distributes X.509 certificates that can be used to identify components as belonging to organization R4. Certificates issued by a CA can also be used to sign transactions to show that the organization recognizes the outcome of the transaction - a prerequisite for its acceptance onto the ledger.

The mapping of certificates to member organizations is accomplished through a structure called a Membership Service Provider (MSP ). Network Configuration NC4 uses named MSPs to identify the properties of certificates distributed by CA4 that associate the certificate holder with organization R4. NC4 can then use this MSP name in a policy to grant participants from R4 specific permissions to network resources. An example of such a policy is identifying administrators in R4 who can add new member organizations to the network.

2.4 Peer node (peer)

In the figure above, P1P2P3 are peer nodes of organization R1R2R3, which are created by each organization to store and synchronize ledger data. Some special peers also have endorsement functions. The ledgers l and S are maintained on it. In the above figure, you can see that P1 has one ledger L1 and one chain code S1, while P2 has two ledgers and two chain codes. This is because the ledger and chain code are created based on channels. The concept of channels please look down.

• Users submit data through client tools, and the data is written to a peer node.
• The data synchronization between peer nodes is done by the Fabric framework and does not require us to implement it . The specific implementation mechanism will be mentioned later.

2.5 channel

Channels are the primary communication mechanism through which alliance members can communicate with each other. Channels are initially created by network configurators with permissions. There can be multiple channels in a network, and a peer can join multiple channels. In the figure above, P1 and P2 are in the same channel C1, and P2 and P3 are in another channel C2. The communication within the channel is agnostic to the outside, not even R4 as the network configurator. Effectively guaranteeing security, there is no limit to the number of peers in the same channel . All peers locally maintain a consistent ledger through consensus , and at the same time provide an interface for querying and modifying the ledger through chain code. . Among them, we can think of L1 as being physically hosted on P1, but logically hosted on channel C1.

2.6 Ledger

Each channel has a consistent ledger that is physically hosted on all peers in the channel. It consists of two parts. One part is the world state . The world state is physically implemented as a database to provide simple and efficient ledger state storage and retrieval. As we have seen, ledger states can have simple or compound values, and to accommodate this, the implementation of the world state database may vary, allowing these values ​​to be implemented efficiently. World state database options currently include LevelDB and CouchDB.

Another part of the blockchain , the world state contains a set of facts related to the current state of a set of business objects, while the blockchain is a historical record of facts about how those objects arrived at their current state. The blockchain records every previous version of every ledger state and how it changed. (Note that not all transactions are completed, and some transactions are marked as invalid. The reason depends on the transaction process).

However, presenting the ledger as a single world state and a single blockchain is a bit too simplistic. In effect, each chaincode has its own world state, separate from all other chaincodes. The world state is located in a namespace, so only smart contracts in the same chaincode can access a given namespace.

2.7 Chaincode and client

Chain code is very similar to Ethereum's smart contract, but Fabric's chain code can be written in languages ​​such as GO and JAVA, which is very convenient. Once the chaincode is written, like the consistent ledger, we can think of the chaincode as being physically hosted on the peer node, but logically deployed on the channel. The client can use fabric's SDK to call the chain code to query or update the consistent ledger on the channel.

In the above figure, A1A2A3 represents the customer. First of all, the customer also needs a reasonable identity , and its identity is maintained by the CA. After completing the identity authentication, A can use his own identity (different identities have different permissions) to call the chain code on the channel to query and update the ledger.

2.8 Developer Grouping

3.Fabric transaction process

Fabric's transaction process can be understood as a three-step process of execution, sorting, and verification.

First of all, there are a few points to clarify before trading:

• The user has been certified by the CA. Transactions include checking data or writing data. Different operations require different identity permissions.
• Transactions require an endorsement strategy. The endorsement strategy can be very simple or very complex. It is guaranteed when the chain code is installed. It is mainly to ensure that the transaction meets some specific conditions. A simplest endorsement strategy is as follows:
  • Members in organization A must agree
  • Members in organization B must also agree

3.1 Execution phase:

• The client sends a transaction proposal to the endorsing node (a type of peer node) (that is, sending a request to invoke the chaincode function)

• The endorsement node performs 4-point verification on the transaction proposal :

  • Is the format correct?

  • has not been submitted before;

  • Whether the (client's) signature is valid;

  • Whether the submitter/client is authorized to perform the operation of this proposal.

• If the above verifications are passed, the endorsement node will input the proposal as a parameter of the called chain code function and simulate the chain code execution on the current state database .

• After execution, the execution result (read-write set) signed by the endorsement node is returned to the client.

• The client then collects all endorsements until all endorsement policies are met.

• If the application's request is only to query the ledger, the application will check and extract the query response information. The query ends here, and the following stages are required to update the ledger.

3.2 Sorting stage:

• After the client satisfies the endorsement policy , it assembles the proposal, execution results and endorsement into a transaction and sends it to the sorting service .
• The sorting service does not check the specific information of the transaction , but simply sorts the received transactions by channel and in chronological order , and creates blocks for each channel (note: the order in which the transactions are received by the sorting service does not necessarily mean that the transactions are packaged and entered. The order of blocks. And when a block is created, a certain number of transactions are usually packaged together to ensure efficiency).
• The ordering node sends the block to all leader peers on the channel, and the leader peers distribute transactions to other peers.

3.3 Verification phase:

• When each peer receives a new block, it will verify the transactions contained in it to ensure that the endorsement policy is met and that the "read set" variable of the current state of the ledger has not changed (because the "read set" is determined by the current block) generated by transaction execution).
• Each peer then appends the block to its local copy of the blockchain and commits the "write set" to the current state database.