Hyperledger Fabric Trading Process

Transaction Flow
This document outlines the trading mechanisms that occur during the exchange of standard assets. The program includes two Clienta and B, they buy and sell radishes. They have a peer on the web, sending their deals through peer and interacting with the ledger.

Assume
This process assumes that the channel is set up and running. The application user Registe and enroll the organization's certification authority (CA) and reclaims the necessary encryption material for authentication to the network.

Chaincode (contains a set of key value pairs that indicate the initial state of the radish market) is installed on the peer and instantiated on the channel. Chaincode contains the logic to define a set of trading instructions and an agreed radish price. The endorsement strategy is also defined as Chaincode, stating that Peera and peer Peerb must support any transaction.

Transaction Flow
Client a Initializes a transaction
Endorsing peers verify signature and execute transaction
Proposal response was checked
The client assembles the endorsement into the transaction.
The transaction is validated and submitted
Ledger update
1. Client a Initializes a transaction

What happened. -Client A sends a request for a carrot purchase. Request target Peera and peerb who represent Clienta and CLIENTB respectively. The endorsement policy stipulates that two peer must sign any transaction, so the request is forwarded to Peera and Peerb.

Next, build the trading proposal. Use an SDK (Node,java,python)-enabled application to generate trading recommendations using one of the available APIs. The proposal is a request to invoke the Chaincode function so that the data can be read and/or written to the ledger (that is, a new key value pair is written for the asset). The SDK is used as a middleware (shim) to package the transaction proposal into the appropriate schema format (through the GRPC protocol buffer) and to use the user's encryption credentials to generate a unique signature for the transaction proposal.

2. Endorsing peers verify signature and execute transaction

Endorser Validation 1) Trading proposal the right organization, 2 the transaction was not submitted before (re-visit attack protection), 3 the validity of the signature (using MSP), 4) The submitter (client A in the example) is properly authorized to perform the recommended action on the channel (that is, Each endorser ensures that the submitter satisfies the channel writer policy). Endorser the transaction proposal as a parameter to the function of the input invoked Chaincode, and executes them against the current state database to produce transaction results including response values, read sets, and write sets. The ledger is not updated at this time. A collection of these values, along with signatures and yes/no endorsement statements that support peer, are passed back to the SDK as "recommended responses," which resolves the payload used to apply consumption.

{MSP is a local process running on peer that allows them to validate transaction requests that arrive from the client and sign the transaction result (endorsement). ACLs (access control lists) are defined when the channel is created and determine which peers and end users are allowed to perform certain actions. }

3. Proposal response was checked

The application validates the endorser signature and compares the proposal response (which is linked to the glossary term containing the payload representation) to determine whether the proposal response is the same and whether the specified endorsement policy has been met (that is, Whether Peera and Peerb both endorse). The schema allows the application to be implemented by peer and maintained during the commit verification phase, even if it chooses not to check the response or otherwise forward an endorsed transaction.

4. Client assembles the endorsement into the transaction

The application proposal and responds to "broadcast" transactions in transaction messages to the sorting service. The transaction will contain a read/write collection, a recognized peer signature and a channel ID. The ordering service does not read transaction details, it simply receives transactions from all channels in the network, sorts them according to channel chronological order, and creates transaction blocks for each channel.

5. Transactions are verified and submitted

The transaction block is "passed" to all peer on the channel. The transactions within the block are validated to ensure that the endorsement policy is met and that the read set variable state of the ledger is not changed because the read set is generated by the transaction execution. The transactions in the block are marked as valid or invalid.

6. Ledger update
Each peer attaches a block to the channel chain, and for each valid transaction, the write set is committed to the current state database. Issue an event to notify the client that the application transaction (invocation) has been immutable attached to the chain and notifies the transaction whether it is validated or invalid.