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

     1  Ledger
     2  ======
     3  
     4  The ledger is the sequenced, tamper-resistant record of all state transitions. State
     5  transitions are a result of chaincode invocations ("transactions") submitted by participating
     6  parties.  Each transaction results in a set of asset key-value pairs that are committed to the
     7  ledger as creates, updates, or deletes.
     8  
     9  The ledger is comprised of a blockchain ('chain') to store the immutable, sequenced record in
    10  blocks, as well as a state database to maintain current state.  There is one ledger per
    11  channel. Each peer maintains a copy of the ledger for each channel of which they are a member.
    12  
    13  Chain
    14  -----
    15  
    16  The chain is a transaction log, structured as hash-linked blocks, where each block contains a
    17  sequence of N transactions. The block header includes a hash of the block's transactions, as
    18  well as a hash of the prior block's header. In this way, all transactions on the ledger are
    19  sequenced and cryptographically linked together. In other words, it is not possible to tamper with
    20  the ledger data, without breaking the hash links. The hash of the latest block represents every
    21  transaction that has come before, making it possible to ensure that all peers are in a consistent
    22  and trusted state.
    23  
    24  The chain is stored on the peer file system (either local or attached storage), efficiently
    25  supporting the append-only nature of the blockchain workload.
    26  
    27  State Database
    28  --------------
    29  
    30  The ledger's current state data represents the latest values for all keys ever included in the chain
    31  transaction log. Since current state represents all latest key values known to the channel, it is
    32  sometimes referred to as World State.
    33  
    34  Chaincode invocations execute transactions against the current state data. To make these
    35  chaincode interactions extremely efficient, the latest values of all keys are stored in a state
    36  database. The state database is simply an indexed view into the chain's transaction log, it can
    37  therefore be regenerated from the chain at any time. The state database will automatically get
    38  recovered (or generated if needed) upon peer startup, before transactions are accepted.
    39  
    40  State database options include LevelDB and CouchDB. LevelDB is the default state database
    41  embedded in the peer process and stores chaincode data as key-value pairs. CouchDB is an optional
    42  alternative external state database that provides addition query support when your chaincode data
    43  is modeled as JSON, permitting rich queries of the JSON content. See
    44  :doc:`couchdb_as_state_database` for more information on CouchDB.
    45  
    46  Transaction Flow
    47  ----------------
    48  
    49  At a high level, the transaction flow consists of a transaction proposal sent by an application
    50  client to specific endorsing peers.  The endorsing peers verify the client signature, and execute
    51  a chaincode function to simulate the transaction. The output is the chaincode results,
    52  a set of key-value versions that were read in the chaincode (read set), and the set of keys/values
    53  that were written in chaincode (write set). The proposal response gets sent back to the client
    54  along with an endorsement signature.
    55  
    56  The client assembles the endorsements into a transaction payload and broadcasts it to an ordering
    57  service. The ordering service delivers ordered transactions as blocks to all peers on a channel.
    58  
    59  Before committal, peers will validate the transactions. First, they will check the endorsement
    60  policy to ensure that the correct allotment of the specified peers have signed the results, and they
    61  will authenticate the signatures against the transaction payload.
    62  
    63  Secondly, peers will perform a versioning check against the transaction read set, to ensure
    64  data integrity and protect against threats such as double-spending. Hyperledger Fabric has concurrency
    65  control whereby transactions execute in parallel (by endorsers) to increase throughput, and upon
    66  commit (by all peers) each transaction is verified to ensure that no other transaction has modified
    67  data it has read. In other words, it ensures that the data that was read during chaincode execution
    68  has not changed since execution (endorsement) time, and therefore the execution results are still
    69  valid and can be committed to the ledger state database. If the data that was read has been changed
    70  by another transaction, then the transaction in the block is marked as invalid and is not applied to
    71  the ledger state database. The client application is alerted, and can handle the error or retry as
    72  appropriate.
    73  
    74  See the :doc:`txflow`, :doc:`readwrite`, and :doc:`couchdb_as_state_database` topics for a deeper
    75  dive on transaction structure, concurrency control, and the state DB.
    76  
    77  .. Licensed under Creative Commons Attribution 4.0 International License
    78     https://creativecommons.org/licenses/by/4.0/