github.com/darrenli6/fabric-sdk-example@v0.0.0-20220109053535-94b13b56df8c/docs/source/txflow.rst (about)

     1  Transaction Flow
     2  ================
     3  
     4  This document outlines the transactional mechanics that take place during a standard asset
     5  exchange.  The scenario includes two clients, A and B, who are buying and selling
     6  radishes.  They each have a peer on the network through which they send their
     7  transactions and interact with the ledger.
     8  
     9  .. image:: images/step0.png
    10  
    11  **Assumptions**
    12  
    13  This flow assumes that a channel is set up and running.  The application user
    14  has registered and enrolled with the organization’s certificate authority (CA)
    15  and received back necessary cryptographic material, which is used to authenticate
    16  to the network.
    17  
    18  The chaincode (containing a set of key value pairs representing the initial
    19  state of the radish market) is installed on the peers and instantiated on the
    20  channel.  The chaincode contains logic defining a set of transaction
    21  instructions and the agreed upon price for a radish. An endorsement policy has
    22  also been set for this chaincode, stating that both ``peerA`` and ``peerB`` must endorse
    23  any transaction.
    24  
    25  .. image:: images/step1.png
    26  
    27  1. **Client A initiates a transaction**
    28  
    29  What's happening? - Client A is sending a request to purchase radishes.  The
    30  request targets ``peerA`` and ``peerB``, who are respectively representative of
    31  Client A and Client B. The endorsement policy states that both peers must endorse
    32  any transaction, therefore the request goes to ``peerA`` and ``peerB``.
    33  
    34  Next, the transaction proposal is constructed.  An application leveraging a supported
    35  SDK (Node, Java, Python) utilizes one of the available API's which generates a
    36  transaction proposal.  The proposal is a request to invoke a chaincode function
    37  so that data can be read and/or written to the ledger (i.e. write new key value
    38  pairs for the assets).  The SDK serves as a shim to package the transaction proposal
    39  into the properly architected format (protocol buffer over gRPC) and takes the user’s
    40  cryptographic credentials to produce a unique signature for this transaction proposal.
    41  
    42  .. image:: images/step2.png
    43  
    44  2. **Endorsing peers verify signature & execute the transaction**
    45  
    46  The endorsing peers verify (1) that the transaction proposal is well formed,
    47  (2) it has not been submitted already in the past (replay-attack protection),
    48  (3) the signature is valid (using MSP), and (4) that the
    49  submitter (Client A, in the example) is properly authorized to perform
    50  the proposed operation on that channel (namely, each endorsing peer ensures that
    51  the submitter satisfies the channel's *Writers* policy).
    52  The endorsing peers take the transaction proposal inputs as
    53  arguments to the invoked chaincode's function. The chaincode is then
    54  executed against the current state database to produce transaction
    55  results including a response value, read set, and write set.  No updates are
    56  made to the ledger at this point. The set of these values, along with the
    57  endorsing peer’s signature is passed back as a “proposal response” to the SDK
    58  which parses the payload for the application to consume.
    59  
    60  *{The MSP is a peer component that allows them to verify
    61  transaction requests arriving from clients and to sign transaction results(endorsements).
    62  The Writing policy is defined at channel creation time, and determines
    63  which user is entitled to submit a transaction to that channel.}*
    64  
    65  
    66  .. image:: images/step3.png
    67  
    68  3. **Proposal responses are inspected**
    69  
    70  The application verifies the endorsing peer signatures and compares the proposal
    71  responses to determine if the proposal responses are the same. If the chaincode only queried
    72  the ledger, the application would inspect the query response and would typically not
    73  submit the transaction to Ordering Service. If the client application intends to submit the
    74  transaction to Ordering Service to update the ledger, the application determines if the specified
    75  endorsement policy has been fulfilled before submitting (i.e. did peerA and peerB both endorse).
    76  The architecture is such that even if an application chooses not to inspect responses or otherwise
    77  forwards an unendorsed transaction, the endorsement policy will still be enforced by peers
    78  and upheld at the commit validation phase.
    79  
    80  .. image:: images/step4.png
    81  
    82  4. **Client assembles endorsements into a transaction**
    83  
    84  The application “broadcasts” the transaction proposal and response within a
    85  “transaction message” to the Ordering Service. The transaction will contain the
    86  read/write sets, the endorsing peers signatures and the Channel ID.  The
    87  Ordering Service does not need to inspect the entire content of a transaction in order to perform
    88  its operation, it simply receives
    89  transactions from all channels in the network, orders them chronologically by
    90  channel, and creates blocks of transactions per channel.
    91  
    92  .. image:: images/step5.png
    93  
    94  5. **Transaction is validated and committed**
    95  
    96  The blocks of transactions are “delivered” to all peers on the channel.  The
    97  transactions within the block are validated to ensure endorsement policy is
    98  fulfilled and to ensure that there have been no changes to ledger state for read
    99  set variables since the read set was generated by the transaction execution.
   100  Transactions in the block are tagged as being valid or invalid.
   101  
   102  .. image:: images/step6.png
   103  
   104  6. **Ledger updated**
   105  
   106  Each peer appends the block to the channel’s chain, and for each valid transaction
   107  the write sets are committed to current state database. An event is emitted, to
   108  notify the client application that the transaction (invocation) has been
   109  immutably appended to the chain, as well as notification of whether the
   110  transaction was validated or invalidated.
   111  
   112  **Note**: See the :ref:`swimlane` diagram to better understand the server side flow and the
   113  protobuffers.
   114  
   115  .. Licensed under Creative Commons Attribution 4.0 International License
   116     https://creativecommons.org/licenses/by/4.0/