github.com/osdi23p228/fabric@v0.0.0-20221218062954-77808885f5db/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  * `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  * `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  * `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  * `Privacy`_ --- Channels and private data collections enable private and
    17    confidential multi-lateral transactions that are usually required by
    18    competing businesses and regulated industries that exchange assets on a common
    19    network.
    20  * `Security & Membership Services`_ --- Permissioned membership provides a
    21    trusted blockchain network, where participants know that all transactions can
    22    be detected and traced by authorized regulators and auditors.
    23  * `Consensus`_ --- A unique approach to consensus enables the
    24    flexibility and scalability needed for the enterprise.
    25  
    26  
    27  Assets
    28  ------
    29  
    30  Assets can range from the tangible (real estate and hardware) to the intangible
    31  (contracts and intellectual property).  Hyperledger Fabric provides the
    32  ability to modify assets using chaincode transactions.
    33  
    34  Assets are represented in Hyperledger Fabric as a collection of
    35  key-value pairs, with state changes recorded as transactions on a :ref:`Channel`
    36  ledger.  Assets can be represented in binary and/or JSON form.
    37  
    38  
    39  Chaincode
    40  ---------
    41  
    42  Chaincode is software defining an asset or assets, and the transaction instructions for
    43  modifying the asset(s); in other words, it's the business logic.  Chaincode enforces the rules for reading
    44  or altering key-value pairs or other state database information. Chaincode functions execute against
    45  the ledger's current state database and are initiated through a transaction proposal. Chaincode execution
    46  results in a set of key-value writes (write set) that can be submitted to the network and applied to
    47  the ledger on all peers.
    48  
    49  
    50  Ledger Features
    51  ---------------
    52  
    53  The ledger is the sequenced, tamper-resistant record of all state transitions in the fabric.  State
    54  transitions are a result of chaincode invocations ('transactions') submitted by participating
    55  parties.  Each transaction results in a set of asset key-value pairs that are committed to the
    56  ledger as creates, updates, or deletes.
    57  
    58  The ledger is comprised of a blockchain ('chain') to store the immutable, sequenced record in
    59  blocks, as well as a state database to maintain current fabric state.  There is one ledger per
    60  channel. Each peer maintains a copy of the ledger for each channel of which they are a member.
    61  
    62  Some features of a Fabric ledger:
    63  
    64  - Query and update ledger using key-based lookups, range queries, and composite key queries
    65  - Read-only queries using a rich query language (if using CouchDB as state database)
    66  - Read-only history queries --- Query ledger history for a key, enabling data provenance scenarios
    67  - 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)
    68  - Transactions contain signatures of every endorsing peer and are submitted to ordering service
    69  - Transactions are ordered into blocks and are "delivered" from an ordering service to peers on a channel
    70  - Peers validate transactions against endorsement policies and enforce the policies
    71  - 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
    72  - There is immutability once a transaction is validated and committed
    73  - A channel's ledger contains a configuration block defining policies, access control lists, and other pertinent information
    74  - Channels contain :ref:`MSP` instances allowing for crypto materials to be derived from different certificate authorities
    75  
    76  See the :doc:`ledger` topic for a deeper dive on the databases, storage structure, and "query-ability."
    77  
    78  
    79  Privacy
    80  -------
    81  
    82  Hyperledger Fabric employs an immutable ledger on a per-channel basis, as well as
    83  chaincode that can manipulate and modify the current state of assets (i.e. update
    84  key-value pairs).  A ledger exists in the scope of a channel --- it can be shared
    85  across the entire network (assuming every participant is operating on one common
    86  channel) --- or it can be privatized to include only a specific set of participants.
    87  
    88  In the latter scenario, these participants would create a separate channel and
    89  thereby isolate/segregate their transactions and ledger.  In order to solve
    90  scenarios that want to bridge the gap between total transparency and privacy,
    91  chaincode can be installed only on peers that need to access the asset states
    92  to perform reads and writes (in other words, if a chaincode is not installed on
    93  a peer, it will not be able to properly interface with the ledger).
    94  
    95  When a subset of organizations on that channel need to keep their transaction
    96  data confidential, a private data collection (collection) is used to segregate
    97  this data in a private database, logically separate from the channel ledger,
    98  accessible only to the authorized subset of organizations.
    99  
   100  Thus, channels keep transactions private from the broader network whereas
   101  collections keep data private between subsets of organizations on the channel.
   102  
   103  To further obfuscate the data, values within chaincode can be encrypted
   104  (in part or in total) using common cryptographic algorithms such as AES before
   105  sending transactions to the ordering service and appending blocks to the ledger.
   106  Once encrypted data has been written to the ledger, it can be decrypted only by
   107  a user in possession of the corresponding key that was used to generate the cipher
   108  text.
   109  
   110  See the :doc:`private-data-arch` topic for more details on how to achieve
   111  privacy on your blockchain network.
   112  
   113  
   114  Security & Membership Services
   115  ------------------------------
   116  
   117  Hyperledger Fabric underpins a transactional network where all participants have
   118  known identities.  Public Key Infrastructure is used to generate cryptographic
   119  certificates which are tied to organizations, network components, and end users
   120  or client applications.  As a result, data access control can be manipulated and
   121  governed on the broader network and on channel levels.  This "permissioned" notion
   122  of Hyperledger Fabric, coupled with the existence and capabilities of channels,
   123  helps address scenarios where privacy and confidentiality are paramount concerns.
   124  
   125  See the :doc:`msp` topic to better understand cryptographic
   126  implementations, and the sign, verify, authenticate approach used in
   127  Hyperledger Fabric.
   128  
   129  
   130  Consensus
   131  ---------
   132  
   133  In distributed ledger technology, consensus has recently become synonymous with
   134  a specific algorithm, within a single function. However, consensus encompasses more
   135  than simply agreeing upon the order of transactions, and this differentiation is
   136  highlighted in Hyperledger Fabric through its fundamental role in the entire
   137  transaction flow, from proposal and endorsement, to ordering, validation and commitment.
   138  In a nutshell, consensus is defined as the full-circle verification of the correctness of
   139  a set of transactions comprising a block.
   140  
   141  Consensus is achieved ultimately when the order and results of a block's
   142  transactions have met the explicit policy criteria checks. These checks and balances
   143  take place during the lifecycle of a transaction, and include the usage of
   144  endorsement policies to dictate which specific members must endorse a certain
   145  transaction class, as well as system chaincodes to ensure that these policies
   146  are enforced and upheld.  Prior to commitment, the peers will employ these
   147  system chaincodes to make sure that enough endorsements are present, and that
   148  they were derived from the appropriate entities.  Moreover, a versioning check
   149  will take place during which the current state of the ledger is agreed or
   150  consented upon, before any blocks containing transactions are appended to the ledger.
   151  This final check provides protection against double spend operations and other
   152  threats that might compromise data integrity, and allows for functions to be
   153  executed against non-static variables.
   154  
   155  In addition to the multitude of endorsement, validity and versioning checks that
   156  take place, there are also ongoing identity verifications happening in all
   157  directions of the transaction flow.  Access control lists are implemented on
   158  hierarchical layers of the network (ordering service down to channels), and
   159  payloads are repeatedly signed, verified and authenticated as a transaction proposal passes
   160  through the different architectural components.  To conclude, consensus is not
   161  merely limited to the agreed upon order of a batch of transactions; rather,
   162  it is an overarching characterization that is achieved as a byproduct of the ongoing
   163  verifications that take place during a transaction's journey from proposal to
   164  commitment.
   165  
   166  Check out the :doc:`txflow` diagram for a visual representation
   167  of consensus.
   168  
   169  .. Licensed under Creative Commons Attribution 4.0 International License
   170     https://creativecommons.org/licenses/by/4.0/