github.com/tenywen/fabric@v1.0.0-beta.0.20170620030522-a5b1ed380643/docs/source/fabric_model.rst (about)

     1  Hyperledger Fabric Model
     2  ========================
     3  
     4  This section outlines the key design features woven into Hyperledger Fabric that
     5  fulfill its promise of a comprehensive, yet customizable, enterprise blockchain solution:
     6  
     7  * :ref:`Assets` - Asset definitions enable the exchange of almost anything with
     8    monetary value over the network, from whole foods to antique cars to currency
     9    futures.
    10  * :ref:`Chaincode` - Chaincode execution is partitioned from transaction ordering,
    11    limiting the required levels of trust and verification across node types, and
    12    optimizing network scalability and performance.
    13  * :ref:`Ledger-Features` - The immutable, shared ledger encodes the entire
    14    transaction history for each channel, and includes SQL-like query capability
    15    for efficient auditing and dispute resolution.
    16  * :ref:`Privacy-through-Channels` - Channels enable multi-lateral transactions
    17    with the high degrees of privacy and confidentiality required by competing
    18    businesses and regulated industries that exchange assets on a common network.
    19  * :ref:`Security-Membership-Services` - Permissioned membership provides a
    20    trusted blockchain network, where participants know that all transactions can
    21    be detected and traced by authorized regulators and auditors.
    22  * :ref:`Consensus` - Fabric's unique approach to consensus enables the
    23    flexibility and scalability needed for the enterprise.
    24  
    25  .. _Assets:
    26  
    27  Assets
    28  ------
    29  
    30  Assets can range from the tangible (real estate and hardware) to the intangible
    31  (contracts and intellectual property).  You can easily define Assets in client-side
    32  javascript and use them in your Fabric application using the included
    33  `Fabric Composer <https://github.com/fabric-composer/fabric-composer>`__ tool.
    34  
    35  Fabric supports the ability to exchange assets using unspent transaction outputs
    36  as the inputs for subsequent transactions.  Assets (and asset registries) live
    37  in Fabric as a collection of key-value pairs, with state changes recorded as transactions
    38  on a :ref:`Channel` ledger.  Fabric allows for any asset
    39  to be represented in binary or JSON format.
    40  
    41  .. _Chaincode:
    42  
    43  Chaincode
    44  ---------
    45  
    46  Chaincode is software defining an asset or assets, and the transaction instructions for
    47  modifying the asset(s).  In other words, it's the business logic.  Chaincode enforces the rules for reading
    48  or altering key value pairs or other state database information. Chaincode functions execute against
    49  the ledger current state database and are initiated through a transaction proposal. Chaincode execution
    50  results in a set of key value writes (write set) that can be submitted to the network and applied to
    51  the ledger on all peers.
    52  
    53  .. _Ledger-Features:
    54  
    55  Ledger Features
    56  ---------------
    57  
    58  The ledger is the sequenced, tamper-resistant record of all state transitions in the fabric.  State
    59  transitions are a result of chaincode invocations ('transactions') submitted by participating
    60  parties.  Each transaction results in a set of asset key-value pairs that are committed to the
    61  ledger as creates, updates, or deletes.
    62  
    63  The ledger is comprised of a blockchain ('chain') to store the immutable, sequenced record in
    64  blocks, as well as a state database to maintain current fabric state.  There is one ledger per
    65  channel. Each peer maintains a copy of the ledger for each channel of which they are a member.
    66  
    67  - Query and update ledger using key-based lookups, range queries, and composite key queries
    68  - Read-only queries using a rich query language (if using CouchDB as state database)
    69  - Read-only history queries - Query ledger history for a key, enabling data provenance scenarios
    70  - Transactions consist of the versions of keys/values that were read in chaincode (read set) and keys/values that were written in chaincode (write set)
    71  - Transactions contain signatures of every endorsing peer and are submitted to ordering service
    72  - Transactions are ordered into blocks and are "delivered" from an ordering service to peers on a channel
    73  - Peers validate transactions against endorsement policies and enforce the policies
    74  - Prior to appending a block, a versioning check is performed to ensure that states for assets that were read have not changed since chaincode execution time
    75  - There is immutability once a transaction is validated and committed
    76  - A channel's ledger contains a configuration block defining policies, access control lists, and other pertinent information
    77  - Channel's contain :ref:`MSP` instances allowing for crypto materials to be derived from different certificate authorities
    78  
    79  See the :doc:`ledger` topic for a deeper dive on the databases, storage structure, and "query-ability."
    80  
    81  .. _Privacy-through-Channels:
    82  
    83  Privacy through Channels
    84  ------------------------
    85  
    86  Fabric employs an immutable ledger on a per-channel basis, as well as
    87  chaincodes that can manipulate and modify the current state of assets (i.e. update
    88  key value pairs).  A ledger exists in the scope of a channel - it can be shared
    89  across the entire network (assuming every participant is operating on one common
    90  channel) - or it can be privatized to only include a specific set of participants.
    91  
    92  In the latter scenario, these participants would create a separate channel and
    93  thereby isolate/segregate their transactions and ledger.  Fabric even solves
    94  scenarios that want to bridge the gap between total transparency and privacy.
    95  Chaincode gets installed only on peers that need to access the asset states
    96  to perform reads and writes (in other words, if a chaincode is not installed on
    97  a peer, it will not be able to properly interface with the ledger).  To further
    98  obfuscate the data, values within chaincode can be encrypted (in part or in total) using common
    99  cryptographic algorithms such as SHA-256 before appending to the ledger.
   100  
   101  .. _Security-Membership-Services:
   102  
   103  Security & Membership Services
   104  ------------------------------
   105  
   106  Hyperledger Fabric underpins a transactional network where all participants have
   107  known identities.  Public Key Infrastructure is used to generate cryptographic
   108  certificates which are tied to organizations, network components, and end users
   109  or client applications.  As a result, data access control can be manipulated and
   110  governed on the broader network and on channel levels.  This "permissioned" notion
   111  of Fabric, coupled with the existence and capabilities of channels, helps address
   112  scenarios where privacy and confidentiality are paramount concerns.
   113  
   114  See the :doc:`Fabric CA <Setup/ca-setup>` section to better understand cryptographic
   115  implementations, and the sign, verify, authenticate approach used in Fabric.
   116  
   117  .. _Consensus:
   118  
   119  Consensus
   120  ---------
   121  
   122  In distributed ledger technology, consensus has recently become synonymous with
   123  a specific algorithm, within a single function. However, consensus encompasses more
   124  than simply agreeing upon the order of transactions, and this differentiation is
   125  highlighted in Hyperledger Fabric through its fundamental role in the entire
   126  transaction flow, from proposal and endorsement, to ordering, validation and commitment.
   127  In a nutshell, consensus is defined as the full-circle verification of the correctness of
   128  a set of transactions comprising a block.
   129  
   130  Consensus is ultimately achieved when the order and results of a block's
   131  transactions have met the explicit policy criteria checks. These checks and balances
   132  take place during the lifecycle of a transaction, and include the usage of
   133  endorsement policies to dictate which specific members must endorse a certain
   134  transaction class, as well as system chaincodes to ensure that these policies
   135  are enforced and upheld.  Prior to commitment, the peers will employ these
   136  system chaincodes to make sure that enough endorsements are present, and that
   137  they were derived from the appropriate entities.  Moreover, a versioning check
   138  will take place during which the current state of the ledger is agreed or
   139  consented upon, before any blocks containing transactions are appended to the ledger.
   140  This final check provides protection against double spend operations and other
   141  threats that might compromise data integrity, and allows for functions to be
   142  executed against non-static variables.
   143  
   144  In addition to the multitude of endorsement, validity and versioning checks that
   145  take place, there are also ongoing identity verifications happening in all
   146  directions of the transaction flow.  Access control lists are implemented on
   147  hierarchal layers of the network (ordering service down to channels), and
   148  payloads are repeatedly signed, verified and authenticated as a transaction proposal passes
   149  through the different architectural components.  To conclude, consensus is not
   150  merely limited to the agreed upon order of a batch of transactions, but rather,
   151  it is an overarching characterization that is achieved as a byproduct of the ongoing
   152  verifications that take place during a transaction's journey from proposal to
   153  commitment.
   154  
   155  Check out the :doc:`txflow` diagram for a visual representation
   156  of consensus.
   157  
   158  .. Licensed under Creative Commons Attribution 4.0 International License
   159     https://creativecommons.org/licenses/by/4.0/