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