github.com/kchristidis/fabric@v1.0.4-0.20171028114726-837acd08cde1/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` - a 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). 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 You can easily define and use assets in your Hyperledger Fabric applications 39 using the `Hyperledger Composer <https://github.com/hyperledger/composer>`__ tool. 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's 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 Hyperledger 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. In order to solve 94 scenarios that want to bridge the gap between total transparency and privacy, 95 chaincode can be 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 AES 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 Hyperledger Fabric, coupled with the existence and capabilities of channels, 112 helps address scenarios where privacy and confidentiality are paramount concerns. 113 114 See the :doc:`msp` topic to better understand cryptographic 115 implementations, and the sign, verify, authenticate approach used in 116 Hyperledger Fabric. 117 118 .. _Consensus: 119 120 Consensus 121 --------- 122 123 In distributed ledger technology, consensus has recently become synonymous with 124 a specific algorithm, within a single function. However, consensus encompasses more 125 than simply agreeing upon the order of transactions, and this differentiation is 126 highlighted in Hyperledger Fabric through its fundamental role in the entire 127 transaction flow, from proposal and endorsement, to ordering, validation and commitment. 128 In a nutshell, consensus is defined as the full-circle verification of the correctness of 129 a set of transactions comprising a block. 130 131 Consensus is ultimately achieved when the order and results of a block's 132 transactions have met the explicit policy criteria checks. These checks and balances 133 take place during the lifecycle of a transaction, and include the usage of 134 endorsement policies to dictate which specific members must endorse a certain 135 transaction class, as well as system chaincodes to ensure that these policies 136 are enforced and upheld. Prior to commitment, the peers will employ these 137 system chaincodes to make sure that enough endorsements are present, and that 138 they were derived from the appropriate entities. Moreover, a versioning check 139 will take place during which the current state of the ledger is agreed or 140 consented upon, before any blocks containing transactions are appended to the ledger. 141 This final check provides protection against double spend operations and other 142 threats that might compromise data integrity, and allows for functions to be 143 executed against non-static variables. 144 145 In addition to the multitude of endorsement, validity and versioning checks that 146 take place, there are also ongoing identity verifications happening in all 147 directions of the transaction flow. Access control lists are implemented on 148 hierarchal layers of the network (ordering service down to channels), and 149 payloads are repeatedly signed, verified and authenticated as a transaction proposal passes 150 through the different architectural components. To conclude, consensus is not 151 merely limited to the agreed upon order of a batch of transactions, but rather, 152 it is an overarching characterization that is achieved as a byproduct of the ongoing 153 verifications that take place during a transaction's journey from proposal to 154 commitment. 155 156 Check out the :doc:`txflow` diagram for a visual representation 157 of consensus. 158 159 .. Licensed under Creative Commons Attribution 4.0 International License 160 https://creativecommons.org/licenses/by/4.0/