Shulou(Shulou.com)06/02 Report--

In a production environment, a minimum Fabric federation chain network consists of four nodes, as shown in the following figure:

In order to avoid single point of failure and carry out structural redundancy, the roles of each node are arranged as follows:

192.168.1.120 peer1, orderer1, zookeeper0, kafka0, ca1

192.168.1.121 peer2, orderer2, zookeeper1, kafka1 ca2

192.168.1.122 peer3, zookeeper2, kafka2, ca3

192.168.1.122 peer4, kafka3 ca4, fabric browser

In Fabric, the process handled by one node is logically broken down into different roles, each with different functions. Peer is divided into endorsement node (Endorser peer) and submission node (Committer peer). In order to achieve the order of processing, sort (Orderer) role is extracted. Kafka is responsible for sharing mechanism in the alliance chain, zookeeper is a distributed application coordinator, responsible for point-to-point data transmission, and CA is responsible for certificate issuance. Fabric is a scenario applied to the alliance chain. When dealing with each transaction, the transaction information needs to be verified on each link.

The Fabric transaction flowchart is as follows:

Detailed process of the transaction process:

1) the application client invokes the Certificate Service (CA) service through SDK, registers and registers, and obtains × × books.

2) the application client initiates a transaction proposal (Proposal) to the blockchain network through SDK, and the transaction proposal sends information such as contract identification, contract method and parameter information, and client signature to the Endorser node.

3) after receiving the transaction proposal (Proposal), the Endorser node verifies the signature and determines whether the submitter has the right to perform the operation, simulates the execution of the intelligent contract according to the endorsement policy, and returns the result and its respective CA certificate signature to the application client.

4) after receiving the information returned by the Endorser node, the application client determines whether the result of the proposal is consistent and whether it is executed with reference to the specified endorsement policy, and aborts the processing if there is not enough endorsement; otherwise, the application client packages the data together to form a transaction, signs it, and sends it to Orderers.

5) Orderers sorts the received transactions by consensus, then packages a batch of transactions together according to the block generation strategy, generates a new block, and sends it to the Committer node

6) after the Committer node receives the block, it verifies each transaction in the block, checks whether the input and output that the transaction depends on are in line with the status of the current block chain, appends the block to the local block chain, and modifies the world status.

There is also a note about the understanding of Fabric alliance chain transactions:

This example includes customers An and B, who are buying and selling turnips. They each have a network node through which they send transactions and interact with the ledger.

First, assume the necessary conditions:

The process assumes that the channel is established and functioning properly. The user has registered and registered using the Organization Authentication Authorization (CA), while obtaining the necessary encryption materials for network authentication.

The chain code (containing a set of key-value pairs representing the initial state of the radish market) is installed on the node and instantiated on the channel. The chain code contains the logic that defines the set of trading orders and the agreed price of the radish. Set an endorsement policy for chain codes, indicating that nodes An and B must endorse any transaction.

1. Customer An initiates a deal

Customer A sends out a radish purchase request. Request target nodes An and B, representing customers An and B, respectively. The endorsement policy indicates that two nodes must endorse any transaction, so the request is sent to nodes An and B.

Next, build a deal proposal. An application supported by available SDK (node, java, python) uses effective API to generate transaction proposals. This proposal is used as a request to invoke the chain code function to complete the reading and / or writing of data to the account book (that is, writing new key-value pairs for the asset). SDK has two functions: to package the transaction proposal into a library with the appropriate architectural format (gRPC-based protocol buffer); and to use the user's encryption certificate to create a unique signature for the deal proposal.

two。 Endorsement node verifies signature & executes transaction

The endorsement node uses MSP to verify the signature and determine whether the requester is reasonably authorized to operate on the proposal (using channel ACL). The endorsement node takes the transaction proposal voucher as input and generates the transaction result based on the database execution of the current state, and the output includes feedback value, read set and write set. So far, the ledger has not been updated. The collection of these values, the signature of the endorsement node, and the yes / no endorsement declaration are transmitted back to SDK,SDK as "proposal feedback" to parse the load consumed by the application.

3. Review proposal feedback

The endorsement node signature is verified by the application, and the proposal feedback (linked to the term terms containing the payload agent) is compared to determine whether the specified endorsement policy is implemented (that is, nodes An and B are endorsed). This architecture ensures that even if an application chooses not to review feedback or forwards transactions without endorsement, the endorsement strategy will still be implemented by the node and maintained during the verification submission phase.

4. Endorsement of customer portfolio transaction

The application broadcasts the transaction proposal and provides feedback to the ordering service with "transaction information". Transactions include read / write sets, endorsement node signatures and channel ID. The ordering service does not read the transaction details, but receives the transaction from all channels in the network, and creates a transaction block for each channel according to the chronological order of each channel.

5. Deal validation and submission

The transaction block is published to all nodes in the channel. The transaction in the block is validated to ensure that the endorsement strategy is executed and that the read set variable of the account book does not change, because the read set is generated by executing the transaction. The transaction in the block is marked as valid or invalid.

6. Ledger update

Each node appends a block to the chain of the channel, and for each valid transaction, writes the collection to the database in the current state. The transaction notifies the client application that the transaction (call) is permanently appended to the chain and that the transaction is valid or invalid.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.