github.com/kaituanwang/hyperledger@v2.0.1+incompatible/docs/source/txflow.rst (about)

     1  Transaction Flow
     2  ================
     3  
     4  This document outlines the transactional mechanics that take place during a
     5  standard asset exchange. The scenario includes two clients, A and B, who are
     6  buying and selling radishes. They each have a peer on the network through which
     7  they send their 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 has
    14  registered and enrolled with the organization’s Certificate Authority (CA) and
    15  received back necessary cryptographic material, which is used to authenticate to
    16  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 deployed to the
    20  channel. The chaincode contains logic defining a set of transaction instructions
    21  and the agreed upon price for a radish. An endorsement policy has also been set
    22  for this chaincode, stating that both ``peerA`` and ``peerB`` must endorse any
    23  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. This
    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
    32  endorse any transaction, therefore the request goes to ``peerA`` and ``peerB``.
    33  
    34  Next, the transaction proposal is constructed. An application leveraging a
    35  supported SDK (Node, Java, Python) utilizes one of the available API's
    36  to generate a transaction proposal. The proposal is a request to invoke a
    37  chaincode function with certain input parameters, with the intent of reading
    38  and/or updating the ledger.
    39  
    40  The SDK serves as a shim to package the transaction proposal into the properly
    41  architected format (protocol buffer over gRPC) and takes the user’s
    42  cryptographic credentials to produce a unique signature for this transaction
    43  proposal.
    44  
    45  .. image:: images/step2.png
    46  
    47  2. **Endorsing peers verify signature & execute the transaction**
    48  
    49  The endorsing peers verify (1) that the transaction proposal is well formed, (2)
    50  it has not been submitted already in the past (replay-attack protection), (3)
    51  the signature is valid (using the MSP), and (4) that the submitter (Client A, in the
    52  example) is properly authorized to perform the proposed operation on that
    53  channel (namely, each endorsing peer ensures that the submitter satisfies the
    54  channel's *Writers* policy). The endorsing peers take the transaction proposal
    55  inputs as arguments to the invoked chaincode's function. The chaincode is then
    56  executed against the current state database to produce transaction results
    57  including a response value, read set, and write set (i.e. key/value pairs
    58  representing an asset to create or update). No updates are made to the
    59  ledger at this point. The set of these values, along with the endorsing peer’s
    60  signature is passed back as a “proposal response” to the SDK which parses the
    61  payload for the application to consume.
    62  
    63  .. note:: The MSP is a peer component that allows peers to verify transaction
    64            requests arriving from clients and to sign transaction results
    65            (endorsements). The writing policy is defined at channel creation time
    66            and determines which users are entitled to submit a transaction to
    67            that channel. For more information about membership, check out our
    68            :doc:`membership/membership` documentation.
    69  
    70  .. image:: images/step3.png
    71  
    72  3. **Proposal responses are inspected**
    73  
    74  The application verifies the endorsing peer signatures and compares the proposal
    75  responses to determine if the proposal responses are the same. If the chaincode
    76  is only querying the ledger, the application would only inspect the query response and
    77  would typically not submit the transaction to the ordering service. If the client
    78  application intends to submit the transaction to the ordering service to update the
    79  ledger, the application determines if the specified endorsement policy has been
    80  fulfilled before submitting (i.e. did peerA and peerB both endorse). The
    81  architecture is such that even if an application chooses not to inspect
    82  responses or otherwise forwards an unendorsed transaction, the endorsement
    83  policy will still be enforced by peers and upheld at the commit validation
    84  phase.
    85  
    86  .. image:: images/step4.png
    87  
    88  4. **Client assembles endorsements into a transaction**
    89  
    90  The application “broadcasts” the transaction proposal and response within a
    91  “transaction message” to the ordering service. The transaction will contain the
    92  read/write sets, the endorsing peers signatures and the Channel ID. The
    93  ordering service does not need to inspect the entire content of a transaction in
    94  order to perform its operation, it simply receives transactions from all
    95  channels in the network, orders them chronologically by channel, and creates
    96  blocks of transactions per channel.
    97  
    98  .. image:: images/step5.png
    99  
   100  5. **Transaction is validated and committed**
   101  
   102  The blocks of transactions are “delivered” to all peers on the channel.  The
   103  transactions within the block are validated to ensure endorsement policy is
   104  fulfilled and to ensure that there have been no changes to ledger state for read
   105  set variables since the read set was generated by the transaction execution.
   106  Transactions in the block are tagged as being valid or invalid.
   107  
   108  .. image:: images/step6.png
   109  
   110  6. **Ledger updated**
   111  
   112  Each peer appends the block to the channel’s chain, and for each valid
   113  transaction the write sets are committed to current state database. An event is
   114  emitted by each peer to notify the client application that the transaction (invocation)
   115  has been immutably appended to the chain, as well as notification of whether the
   116  transaction was validated or invalidated.
   117  
   118  .. note:: Applications should listen for the transaction event after submitting
   119            a transaction, for example by using the ``submitTransaction``
   120            API, which automatically listen for transaction events. Without
   121            listening for transaction events, you will not know
   122            whether your transaction has actually been ordered, validated, and
   123            committed to the ledger.
   124  
   125  See the :ref:`sequence diagram <swimlane>` to better understand the
   126  transaction flow.
   127  
   128  .. Licensed under Creative Commons Attribution 4.0 International License
   129  https://creativecommons.org/licenses/by/4.0/