"Fabric trading Process" Transaction flow non-direct translation

Original link: https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html

"This article doesn't have to be literal. 】

Transaction Flow Trading Process

This document outlines the transactional mechanics, the place during a, standard asset exchange. The scenario includes the clients, A and B, who is buying and selling radishes. They each has a peer on the network through which they send their transactions and interact with the ledger.

This article describes the internal trading mechanism between nodes in the process of "standard asset trading". With A and B two people trading radish for example, each of the two of them has peer nodes in the network for bookkeeping in the blockchain ledger.

assumptions hypothesis

This flow assumes, a channel is set up and running. The application user has registered and enrolled with the organization's Certificate Authority (CA) and received back Nece Ssary cryptographic material, which is used-authenticate to the network.

Suppose the channel has been configured and is running. The peer node application for all users has been registered and has obtained a CA certificate for permission validation, along with the corresponding encrypted data (that is, a bunch of configuration files that do not have access to the network).

The Chaincode (containing a set of key value pairs representing the initial state of the radish market) are installed on th E peers and instantiated on the channel. The Chaincode contains logic defining a set of transaction instructions and the agreed upon price for a radish. An endorsement policy have also been set for this chaincode, stating that both Peera and Peerb must endorse any transaction .

The Chaincode chain code is installed on the peer node and instantiated on the channel (channel instances are established on the network where orders are formed), and the chain code contains "trade orders" and "commodity prices". Chain code also "endorsement guarantee rules", A and B peer node will be satisfied with the "endorsement guarantee rules" of the transaction, to guarantee.

Client A initiates a transaction customer A to initiate a deal

What ' s happening? -Client A is sending a request to purchase radishes. The request targets Peera and Peerb, who is respectively representative of client A and client B. The endorsement policy states that both peers must endorse any transaction, therefore the request goes to Peera and Peerb.

Customer a uses the app to initiate a purchase order for the radish, and this order request is sent to Node A and Node B. If the endorsement guarantee rule is set to be guaranteed for all transactions, then the request will be accepted by the peer node.

Next, the transaction proposal is constructed. An application leveraging a supported SDK (Node, Java, Python) utilizes one of the available API ' s which generates a trans Action proposal. The proposal is a request to invoke a Chaincode function so, data can be read and/or written to the ledger (i.e. write New key value pairs for the assets). The SDK serves as a shim to kit the transaction proposal into the properly architected format (protocol buffer over GR PC) and takes the user ' s cryptographic credentials to produce a unique signature for this transaction proposal.

The next step is to build a "deal proposal". The app that initiates the transaction generates a "trading proposal" with the API interface in the Fabric Client SDK. The content of this proposal is to request the Chaincode chain code to read or write to the ledger. (A shim is a library that introduces a new API into an old environment and is implemented only by means already available in the old environment) the SDK of the fabric client (in the form of a shim library) serializes the "transaction proposal" into a structured text format and uses the cryptographic credentials of the client user generate a signature for the "deal proposal". endorsing peers verify signature & Execute the transaction peer for secured transaction verification Signature & execution Transaction

The endorsing peers verify (1) that the transaction proposal was well formed, (2) It had not been submitted already in the Past (Replay-attack Protection), (3) The signature is valid (using MSP), and (4) that the submitter (Client A, in the exam PLE) is a properly authorized to perform the proposed operation on this channel (namely, each endorsing peer ensures that th E submitter satisfies the channel ' s writers policy). The endorsing peers take the transaction proposal inputs as arguments to the invoked Chaincode ' s function. The Chaincode is then executed against, the current state, database to produce transaction results including a response valu E, read set, and write set. No updates is made to the ledger at this point. The set of these values, along with the endorsing peer ' s signature are passed back as a "proposal response" to the SDK whic H parses the payload for the application to consume.

The terms of the secured peer node need to be verified are:

(1) The format of the transaction proposal is correct

(2) Whether it has been submitted (to prevent replay attacks)

(3) Whether the signature is valid (signature is issued by CA)

(4) Whether the submitted client app (customer a) is authorized to execute the "initiating transaction" operation instruction on the channel.

The secured peer node will pass the "deal proposal" as a parameter when invoking the Chaincode chain code function. The chain code will process the transaction result according to the data of the current ledger database, the transaction result includes: Return code, read data collection, write data collection (this write operation is not executed to the database temporarily). The ledger will not be updated at this time. then these chaincode processed "trading results" with the peer's signature returned to the client's SDK program, the client's SDK will parse the data, provided to the app to do the next process.

{The MSP is a peer component this allows them to verify transaction requests arriving from clients and to sign transaction Results (endorsements). The Writing policy is defined at channel creation time, and determines which user are entitled to submit a transaction to T Hat Channel.}

The {MSP (issued by the CA for each peer node) is a peer component that can be used to authenticate transactions from the client and to sign transaction results after Chaincode processing. The Writing policy "write rule" is defined when the channel is created, and he declares which client users have the right to launch "channel channels" to which "trading proposals" are to be made. }
proposal responses is inspected

The application verifies the endorsing peer signatures and compares the proposal responses to determine if the Proposa L responses is the same. If the Chaincode only queried the ledger, the application would inspect the query response and would typically not submit The transaction to ordering Service. If the client application intends to submit the transaction-ordering Service to update the ledger, the application dete Rmines if the specified endorsement policy has been fulfilled before submitting (i.e. did Peera and Peerb both endorse). The architecture is such that even if a application chooses not to inspect responses or otherwise forwards an unendorsed Transaction, the endorsement policy would still is enforced by peers and upheld at the commit validation phase.

This application verifies that the secured peer node is signed correctly and compares the  proposal responses "proposal response". if Chaincode only queries the ledger, then the client app will only check for proposal responses The correctness of the "proposal response" and no longer submits "transaction" to   ordering Service. if the client's app attempts to submit a "transaction" to the ordering Service to update the bill, it is necessary to ensure that all peer's secured signatures are fully collected (for example, in this case, the proposal of the peer a node and peer B nodes need to be collected) Signed in responses). It is also stated in this architecture that if the client app chooses not to check the correctness of the proposal responses "proposal response", or to forward an unsecured transaction, the "guarantee rule" will still cause the transaction to be referred to in the "Submit verification phase" The peer node enforces the "guarantee procedure" with determination. client assembles endorsements into a transaction  customer to assemble a secured endorsement into a transaction

The application "broadcasts" the transaction proposal and response within a "transaction message" to the ordering Service. The transaction would contain the Read/write sets, the endorsing peers signatures and the Channel ID. The ordering Service does not need-inspect the entire content of a transaction in order-perform its operation, it si Mply receives transactions from all channels on the network, orders them chronologically by channel, and creates blocks of Transactions per channel.

The application broadcasts "transaction information" to the ordering Service, which contains transaction proposal "transaction proposal" and proposal responses "proposal response". This "transaction information" includes the "read and write data collection of the Ledger" (which is actually a bunch of instruction sets), as well as the signature information of the secured node peer, and the channel ID. The ordering service does not need to check the contents of the "Transaction information" in order to perform the operation , he simply accepts the information from the Channel network. The transactions for each channel are sorted by time and the transaction is packaged into chunks according to different channel channels. Transaction is validated and committed transaction verified and submitted

The blocks of transactions is "delivered" to all peers on the channel. The transactions within the block was validated to ensure endorsement policy was fulfilled and to ensure that there has been En no changes to ledger state for read set variables since the read set is generated by the transaction execution. Transactions in the block is tagged as being valid or invalid.

All the chunks that are packaged for trading are passed to the peer node within the channel corresponding to all the blocks. The transactions of these blocks are verified to ensure that the transaction has received a guaranteed endorsement from all peer nodes, and that the data in the Read collection in the transaction has not been tampered with since the last time the ledger was read . The records that are verified to pass are marked as valid verified, and the failed validation transactions are marked as invalid not validated. Ledger updated ledger update

Each peer appends the block to the channel's chain, and for each valid transaction the write sets is committed to current State database. An event was emitted, to notify the client application that the transaction (invocation) have been immutably appended to the Chain, as well as notification of whether the transaction were validated or invalidated.

Each peer node appends the chunk to the link of the corresponding channel, and the "Write data set" is submitted to the database for each transaction that is marked as authenticated. at the same time, an event is triggered to notify the client app that the transaction he submitted has been written to the blockchain (and cannot be modified), and the client app will be notified if the transaction is invalid.

Note: See the Swimlane diagram to better understand the server side flow and the protobuffers.