hyperledger-fabric documentation official documentation

• ##Introduction
  Hyperledger Fabric is a platform for distributed ledger solutions with a modular architecture that provides high security, resilience, flexibility and scalability. It is designed to support the pluggable implementation of different components and adapt to complex economic ecosystems.
  • ### Private and Permissioned
  • ###Channel
    Some participants may be competitors and do not want every transaction they make to be known by every participant, for example, a special price they offer only to some participants and others not. If two participants form a channel, only those two participants have a copy of the channel's ledger, and no other participants.
• ##blockchain
  • ### A distributed ledger
    • #### The blockchain ledger is often described as decentralized because it is replicated across many network participants, each of whom is collaborating to maintain the ledger.
    • #### can not be modified, can be used as a proof system
  • ###Smart contract: providing controlled access to the ledger
    Written in chain code, when the application needs to interact with the ledger, it is called by the application outside the blockchain. In most cases, chaincode only interacts with the ledger's database, world state (e.g., queries), not with the transaction log.
  • ###Consensus: the process of keeping the ledger in sync across the network
    • #### Transactions must be written to the ledger in the order they occurred, even though they may be in different sets of participants in the network. To do this, the order of transactions must be established, and there must be a way to reject illegal transactions that are incorrectly (or maliciously) inserted into the ledger. For example, PBFT (Practical Byzantine Fault Tolerance) can provide a mechanism for file copies to maintain consistency across copies, even in the event of corruption. Or, in Bitcoin, sorting through a process called mining, in which competing computers compete to solve a cryptographic puzzle that defines the order in which all processes are subsequently built.
    • #### Consensus is eventually reached when the order and outcome of transactions in a block meet explicit policy criteria checks. These checks and balances occur during the lifecycle of a transaction and include the use of endorsement policies to specify which specific members must endorse a transaction class and the system chaincode to ensure that these policies are enforced and maintained. Before committing, nodes will use these system chaincodes to ensure that sufficient endorsements exist and that they are from the appropriate entities. Additionally, before any blocks containing transactions are appended to the ledger, there will be a version control check during which the current state of the ledger is agreed. This final check prevents double-spending operations and other threats that could compromise data integrity, and allows functions to be executed against non-static variables.
    • #### In addition to the numerous endorsements, verifications, and version checks that take place, there is ongoing authentication happening in all directions of the transaction flow. Access control lists are implemented at the network level (ordering services to channels), and payloads are repeatedly signed, confirmed and verified as transaction proposals pass through different architectural components. In summary, consensus is not limited to an agreed-upon order for a batch of transactions; rather, it is an overarching feature that is a by-product of ongoing verification of transactions as they progress from proposal to endorsement.
  • ### Shared ledger
    • ####WorldState
      The worldstate component describes the state of the ledger at a given point in time. It is the database of the ledger
    • #### Transaction Log
      Records all transactions that produced the current value in the world state; this is the history of updates to the world state. The ledger then includes the world state database and transaction log history. Transaction logs do not need to be pluggable. It only records the values ​​before and after the ledger database used by the blockchain network.
    • ####Features Query
      and update ledgers using key-based lookups, range queries, and composite key queries - Read-only queries using Rich Query Language (if using CouchDB as the state database) - Read-only history queries (ledger queries for keys History) to support data provenance schemes - transactions containing the version of the key/value read by the chaincode (read set) and the key/value written by the chain code (write set) - containing the signature of each endorser, and Transactions submitted to the ordering service - Packaged into blocks in order and "distributed" from the ordering service to nodes on the channel - Nodes verify the transaction according to the endorsement policy and enforce the policy - Before appending the block, a version check is performed to ensure The state of the asset read after chaincode execution has not changed - Once the transaction is verified and committed, it cannot be changed - The ledger of the channel contains configuration blocks that define policies, access control lists and other relevant information - The channel contains the Membership Service Provider An example of a program that allows derivation of cryptographic material from different certificate authorities
  • ### Blockchain Network
  • A technical infrastructure that provides ledger and smart contract (chaincode) services for applications

    

    • R4 is assigned as the initiator of the network, which has the authority to set the initial version of the network. R4 will not conduct any business transactions in the network. **R1 and R2 have a need for private communication throughout the network, as do R2 and R3.
    • Organization R1 has a client application that can conduct business transactions in channel C1. **Organization R2 has a client application that does similar work in channels C1 and C2. Organization R3 can do this in channel C2.
    • Node P1 maintains a copy of C1's ledger L1. Node P2 maintains a copy of C1's ledger L1 and C2's ledger L2. Node P3 maintains a copy of C2's ledger L2.
    • This network is managed according to the rules specified in network configuration NC4, and the entire network is managed by organizations R1 and R4. Channel C1 is managed according to the rules specified in channel configuration CC1, which is managed by organizations R1 and R2. Channel C2 is managed according to the rules specified in channel configuration CC2, this channel is managed by organizations R2 and R3
    • There is an ordering service O4 acting as a network administrator node for this network N and using system channels. The ordering service also supports application channels C1 and C2 to order transactions, add them to blocks and distribute them. Every organization has a preferred CA.
  • ### Create Network

    • 

      
      In our example network N, the ordering service O4 consists of a single node configured according to a network configuration NC4. At the network level, the certificate authority CA4 is used to assign identity information to administrators and network nodes of the organization R4. *
      Certificate Authority: CA4, it will be used to issue certificates to managers and network nodes
      CA4 plays an important role in our network, because it will distribute X.509 certificates, which can be used to identify the organization R4 s component. The certificate issued by the CA can also be used to provide a signature for the transaction to indicate that an organization endorses the result of the transaction. Endorsement is a prerequisite for a transaction to be accepted and recorded in the ledger.
      ​
    • Network administrators can be added

      

      
      Although orderer O4 runs on R4's infrastructure, it can share administrative privileges if R1 can access it. That is to say, R1 or R4 can update the network configuration NC4 to allow R2 to perform some functions in network maintenance. In this way, although R4 runs the ordering service, R1 also has full administrator rights in it, and R2 has limited rights to create new federations. Ordering services are usually multi-node, and can also be configured on different nodes in different organizations. For example, we might run O4 in R4 and connect to O2, which is another orderer in organization R1. In this way, we have a multi-node, multi-organization management structure.
    • define coalition

      

      
      The network administrator defines a federation X1 with two members, consisting of organizations R1 and R2. The definition of this federation is stored in the network configuration NC4 and will be used in the subsequent development of the network. CA1 and CA2 are the corresponding certificate authorities for these two organizations. *
      Due to the way NC4 is configured, only R1 and R4 are able to create new federations. This icon shows a new federation X1, which defines R1 and R2 as its federated organizations. We also see that CA2 is also added to identify users from R2. Note that a federation can contain any number of organizations, here we only include two organizations as the simplest configuration.
      We can see that a federation defines a subset of organizations in a network that share a need to be able to transact with each other, in this case R1 and R2 to be able to transact. This makes sense for a group of organizations that share a common goal.
    • Create channel for federation

      

      • Use channel C1 created by confederation X1 for R1 and R2. This channel is managed through the channel configuration CC1 and is completely independent of the network configuration. CC1 is managed by R1 and R2, who have equal rights on C1. R4 does not have any rights in CC1.
      • Although C1 is part of network N, it is very different from this network. Also note that organizations R3 and R4 are not in this channel, since this channel is only for processing transactions between R1 and R2. In the previous step, we saw how R4 was able to assign permissions to R1 to create new federations. R4 also allows R1 to create channels. In this figure, organizations R1 and R4 create channel C1. Again, a channel can contain any number of orgs, but we've only included two so far, which is the simplest configuration.
      • cc1 is a channel rule, only users added to cc1 can interact with the c1 channel
      • Once a channel is created, only the organization specified in the channel configuration can control it. Any changes to NC4 will not affect CC1. For example, if consortium definition X1 is changed, it will not affect members of channel C1
    • Nodes and Ledgers

      

      
      A Peer node P1 joins the channel C1. Physically, P1 will store a copy of ledger L1. P1 and O4 can use channel C1 for communication. ​
      • A peer node is a network component that stores a copy of the blockchain ledger.
        A key part of the configuration of P1 is an X.509 identity information issued by CA1, which associates P1 with organization R1. When P1 starts up, it can join channel C1 using sequence O4. When O4 receives this join request, it uses channel configuration CC1 to determine P1's permissions in this channel. For example, CC1 decides whether P1 can read or write information to ledger L1.
    • Application and Smart Contract Chaincode

      

      
      Smart contract S5 is installed on P1. Client application A1 in organization R1 can use S5 to access the ledger through Peer node P1. A1, P1, and O4 are all joined to channel C1, and they can all use the communication facilities provided by this channel.
      • In our example, client application A1 is associated with organization R1, and although it is outside the Fabric blockchain network, it can be connected to the network through channel C1.
      • The client application A1 needs to obtain the ledger L1 through the smart contract S5.
      • Think of smart contracts as managing transactions, and chaincode manages how smart contracts should be packaged and deployed
      • Define the chain code
        The chain code will be installed on the Peer node of the organization. An organization must approve a chain code definition before it can use the installed smart contract to query the ledger and endorse the transaction.
      • Endorsement Policy
      • call smart contract
    • complete network

      

      
      This network was made larger by adding the infrastructure of the new organization R2. Specifically, R2 adds Peer node P2, which will store a copy of ledger L1, and chaincode S5. R2 approved the same chaincode definition as R1. P2 also joins channel C1, which also has a client application A2. A2 and P2 use a certificate issued by CA2 to identify A2 and P2. All these show that A1 and A2 can use Peer node P1 or P2 to call S5 on C1
    • peer node type
      • type
        • *commit node*. Each Peer node in the channel is a submitting node. They will receive the generated blocks, and after these blocks are verified, they will be additionally submitted to the Peer node's copy of the ledger.
        • *endorsement node*. Every Peer node with a smart contract installed *can* act as an endorsement node. However, to *become* a true endorsing node, the smart contract on the node must be used by the client application to generate a signed transaction response.
      • Role
        • Master node: When the organization has multiple Peer nodes in the channel, there will be a master node, which is responsible for distributing transactions from the sorting node to other withdrawal nodes in the organization
          • Statically selected master nodes: 0 or more nodes can be configured as master nodes
          • Dynamically elected master node: a node will be elected as the master node. If a master node fails, the remaining nodes will re-elect a master node.
        • Anchor Nodes: Cross-Organizational Communication
      • There is only one channel, and there is only one logical ledger that interacts with this channel component. Peer nodes P1 and P2 have the same copy of ledger L1
    • Sorting Service
      A component that collects endorsed transactions from applications, then it sorts these transactions into blocks, and these blocks are distributed to each Peer node in the channel. At each such commit node, the transaction is recorded whether it is valid or invalid, and their local copy of the ledger is updated.
    • Decentralized transaction distribution: multiple ordering points
    • modify policy
    • network fully formed

      

      
      In this figure, we see that the Fabric blockchain network includes two application channels and one sorting channel. Organizations R1 and R4 are responsible for the sequencing lane, R1 and R2 are responsible for the blue application lane, and R2 and R3 are responsible for the red application lane. Client application A1 is an element of organization R1, and CA1 is its certificate authority. Note that node P2 of organization R2 can use the communication facility in blue and the application channel in red. Each application channel has its own channel configuration, here CC1 and CC2. The channel configuration of system channels is part of the network configuration NC4.
  • Identity: Every participant (an active element that can use services inside or outside the network) has a digital identity encapsulated in an X.509 digital certificate* that determines the exact authority to the resource and the participant's ownership in the blockchain network access to information.
    • main body
    • Identity can be verified, it must come from a trusted authority. Membership Service Provider (Membership Service Provider, MSP) is a trusted authority in Fabric. An MSP is the component that defines the rules governing the effective identity of the organization. The default MSP implementation in Fabric uses X.509 certificates as identities, using a traditional Public Key Infrastructure (PKI) layered model (more on PKI later)
  • PKI and MSP work together in the same way, PKI provides a list of identities and MSP says which are members of a given organization participating in the network
    • PKI is like a card provider that assigns many different types of verifiable identities, and is a set of Internet technologies that provide secure communication within a network

      

      
      Elements of a public key infrastructure (PKI). A PKI consists of certificate authorities that issue digital certificates to various parties (eg, users of a service, service providers), and then use them to authenticate themselves in messages exchanged with their environment. A CA's Certificate Revocation List (CRL) constitutes a reference to certificates that are no longer valid. Revocation of certificates can happen for a number of reasons. For example, a certificate may be revoked because cryptographically private material associated with the certificate has been made public.
      • Digital certificates, such as X.509
      • public key and private key
        • Traditional authentication mechanisms rely on digital signatures
        • Technically, a digital signature mechanism requires each party to hold two keys to an encrypted connection: a widely available public key and a private key that acts as an anchor for authorization, and a private key that is used to produce a digital signature on a message. The recipient of a digitally signed message can verify the origin and integrity of the received message by checking that the additional signature is valid under the intended sender's public key.
      • Certificate Authority CA
        • Root CA, Intermediate CA and Trust Chain
          CA There are two forms: root CA and intermediate CA. Because root CAs (Symantec, Geotrust, etc.) have to securely issue hundreds of millions of certificates to Internet users, it's useful to decentralize this process into so-called intermediate CAs. These intermediate CAs have certificates issued by the root CA or other intermediate CAs, allowing a "chain of trust" to be established for any certificate issued by any CA in the chain. The ability to trace back to the root CA not only allows the capabilities of the CA to be extended while still providing security (allowing certificate-using organizations to use intermediate CAs with confidence), it also limits the exposure of the root CA, which, if compromised, would The entire chain of trust is compromised. On the other hand, if the intermediate CA is compromised, the exposure will be much smaller.
        • Fabric CA: Fabric provides a built-in CA component that allows the creation of CAs in your blockchain network
      • Certificate Revocation List
        Uses a CRL to check whether a certificate is still valid. If an impersonator tries to pass an invalid digital certificate to a verifier, it can first check the CRL of the issuing CA to ensure it is not listed as invalid
    • The MSP is similar to the list of card providers accepted by the store, determining which identities are trusted members (participants) of the store's payment network. MSPs turn verifiable identities into members of blockchain networks.

      

      
      An identity is like your credit card, used to prove you can pay. MSP is similar to a list of accepted credit cards.
    • MSP domain
      • locally at the participant node (local MSP)
        • Defined for clients and nodes that let users verify themselves in their transactions as a member of a channel (such as in a chaincode transaction), or as the owner of a specific role in the system (such as an organization administrator in a configuration transaction).
        • Every node must define a local MSP, as it defines who has administrative or participation rights at that level, the organization, the organization's admins, the node's admins, and the node itself should all have the same root of trust
        • There are also sorting nodes, which are used to verify participants, nodes
      • In the channel configuration (channel MSP): define management and participation rights at the channel level

        

        
        A fragment of a channel configuration. json file, which includes two organizational MSPs.
        • Channel MSPs determine who has authority at the channel level. The channel MSP defines the channel members, and the channel MSP is also instantiated on the file system of each node in the channel, and is kept in sync by consensus
        • Local MSPs are defined only on the filesystem of the node or user they are applied to
        • Each node has a copy of each channel MSP on its local file system, how local MSPs and channel MSPs coexist in the network:
        • The OU field in the certificate specifies the business unit to which the identity belongs.
          • How roles and ou are represented in certificates:
          • node ou
            In the above example, MSP has 4 possible node OU roles:: Client, Peer, Admin, Issuing Applicant
          • Note: For channel MSPs, just because a participant has an administrator role, it doesn't mean they can manage a specific resource. The actual ability of a given identity to manage the system is determined by the policy for managing the system's resources
          • Different organizations in a consortium can use ou to distinguish each other. But in this case, different organizations must use the same root CA and intermediate CA for their chain of trust, and assign the OU field to identify the members of each organization. This makes the system more centralized than intended when every organization has the same CA or chain of trust
        • The local MSP folder contains the following subfolders:
          • config.yaml: Configure identity classification features in Fabric by activating the "Node OUs" node and defining acceptable roles
          • cacerts: This folder contains a list of self-signed X.509 certificates for root cas trusted by the organization represented by this MSP. There must be at least one root CA certificate in this MSP folder. This is the most important folder as it identifies the CAs from which all other certificates must be derived to be considered members of the respective organization to form a chain of trust.
          • intermediatecerts: This folder contains a list of X.509 certificates for intermediate CAs trusted by this organization. Each certificate must be signed by one of the root CAs in the MSP or any intermediate CAs that issue a chain of CAs that eventually lead back to trusted root CAs. Intermediate CAs can be used to represent subdivisions of an organization
            • Note that it is possible to have a functioning network without an intermediate CA, in which case this folder will be empty.
            • Like the root CA folder, this folder defines the CA from which the certificate must be issued in order to be considered a member of the organization
          • admincerts (Deprecated from Fabric v1.4.3 and higher): This folder contains a list of identities that define participants with the admin role for this organization. Generally, there should be one or more X.509 certificates. It is recommended to use the admin role to specify the node administrator when the user registers with the CA. This identity is then identified as admin by the Node OU role value in its signcert. As a reminder, in order to take advantage of administrative roles, the "identity classification" feature must be enabled in the configuration. By setting "node ou" to Enable: true
          • keystore: (private Key): This folder is defined for the peer or order node's local MSP (or in the client's local MSP) and contains the node's private key. This key is used to sign data
            • The channel MSP configuration does not include this folder, because the channel MSP is only intended to provide authentication functions, not signing functions
            • If you use HSM (Hardware Security Module) for key management, this folder is empty because the private key is generated by HSM and stored in HSM
          • signcert: Contains a certificate issued by the node's CA, which can be used to generate a signature that is verified by anyone who has a copy of this certificate. This folder is required for local MSPs and must contain a public key.
            • Access to this folder must be restricted to users with administrative responsibility for the peer.
            • The configuration of the channel MSP does not include this folder, because the channel MSP is only intended to provide authentication functions, not signing functions
          • tlscacerts: This folder contains a list of self-signed X.509 certificates of root CAs trusted by the organization for secure communication between nodes using TLS. MSP TLS messages involve nodes inside the network
          • tlsintermediatecacerts: This folder contains a list of intermediate CA certificates trusted by the organization represented by the MSP for secure communication between nodes using TLS.
          • operationscerts: This folder contains the certificates required to communicate with the Fabric Operations Service API
        • Channel MSP additionally includes:
          • Revoked Certificates: If the perpetrator's identity has been revoked, identifying information about that identity - but not the identity itself - is kept in this folder. For x.509-based identities, these identifiers are a pair of strings called a Subject Key Identifier (SKI) and an Authority Access Identifier (AKI) that are checked whenever a certificate is used to Make sure the certificate is not revoked
  • Strategy:

    

    • System channel configuration: Every network starts with an ordering service system channel. There must be at least one ordering system channel of the ordering service in the network, which is the first channel to be created. The channel also contains who is a member of the ordering service (ordering service organization) and transacting in the network (confederation organization). The policies in the ordering system channel configuration block govern the consensus used by the ordering service and define how new blocks are created. System channels also govern which members of the consortium can create new channels.
    • Application channel configuration: Application channels are used to provide a private communication mechanism between organizations in the federation. Policies in application channels govern the ability to add and remove members from the channel. Application channels also govern which organizational consent is required before chaincodes are defined and committed to the channel using the Fabric chaincode lifecycle. When the system channel is initially created, it inherits all ordering service parameters of the ordering system channel by default. At the same time, these parameters (including the policies governing them) can be customized per channel.
    • Access Control List (ACL)
    • policy scope
    • Smart Contract Endorsement Policy
    • update strategy
    • How to write policies in the fabric
      • Signature strategy: support sorting and multiple logical relationships
      • ImplicitMeta policy: effective in the channel configuration based on the hierarchically constructed policy tree
        • The implicit meta-policy aggregates the results of the deep configuration tree ultimately defined by the signature policy. They are hidden because they are built implicitly based on the current organization in the channel configuration, and they are meta-information because their evaluation does not depend on a specific MSP specification, but on their other sub-policies in the configuration tree.
        • Comply with the principle of opening and closing
        • NodeOUs for further granularity and control
      • Signature Policy Usage Example
      • Examples of implimeta use
      • life cycle
  • Node: maintain ledger and chain code

    

    
    Redundancy is intentionally provided in fabric networks because it avoids single points of failure
    • 
      The blockchain network is composed of Peer nodes, and each node keeps a copy of the ledger and smart contract. In this example, network N is composed of nodes P1, P2 and P3, each of which maintains their own distributed ledger L1. P1, P2, and P3 use the same chaincode S1 to access their copies of the distributed ledger. Multiple ledgers and chaincodes can be maintained
    • Applications and Peer nodes: When applications need to access ledgers and chain codes, they always need to connect to Peer nodes. By connecting to Peer nodes, applications can execute chain codes to query or update ledgers. The result of querying the ledger will immediately return
      the Peer node and sorting node, ensuring that the ledger has the latest ledger on each Peer node. In this example, application A connects to P1 and invokes chaincode S1 to query or update ledger L1. P1 invokes chaincode S1 to generate a proposal response, which contains query results or proposals for ledger updates. Application A receives the response to the proposal, and for queries, the flow ends here. For updates, application A creates a transaction from all the responses, which it sends to orderer O1 for ordering. O1 will collect transactions in the network and package them into blocks, and then distribute these blocks to all Peer nodes, including P1. P1 validates the transaction before committing it to ledger L1. When L1 is updated, P1 will generate an event, which will be received by A to mark the end of the process.
      • An independent Peer node is currently unable to update the ledger, because other Peer nodes must first agree to the change (that is, reach a consensus), and the Peer node will return a proposed update to the application, and the Peer node will be based on other Node's previous protocol to apply this update
    • Peer nodes and channels
      Channels allow specific peer nodes and applications in the blockchain network to interact with each other. In this example, application A can communicate directly with peer nodes P1 and P2 using channel C. You can think of a channel as a path for communication between some application and a peer node. (The orderer is not shown in this diagram, but it must exist in a working network.)
    • Peer nodes and organizations: There are no centralized resources here. If these organizations do not contribute their nodes, the network N will not exist. Unless and until organizations contribute their resources, such a network will not be formed. Otherwise, this network will not The meaning of existence
    • Peer node and identity: Each Peer node in the network will be assigned a digital certificate by the administrator of the organization it belongs to.
      When a Peer node connects to a channel, its digital certificate will identify its organization through the channel MSP. In this example, P1 and P2 have identities issued by CA1. Channel C determines through policies in its channel configuration that identities from CA1 should be associated to Org1 using ORG1.MSP. Similarly, P3 and P4 are recognized by ORG2.MSP as part of Org2.
    • Peers and Orderers: Applications that update ledgers are introduced into a three-stage process
      • In the first phase, the application works with a subset of endorsing nodes, each of which endorses the proposed ledger update to the application, but does not apply the proposed update to their copy of the ledger.
      • In the second phase, these scattered endorsements will be collected together and packaged into blocks as transactions.
      • In the final stage, these blocks are distributed back to each peer node, where each transaction is verified before being applied to the peer node's copy of the ledger.
      • Phase 1: Proposal: The application generates a proposal for a transaction, which it sends to a series of required nodes for endorsement. Each of the endorsement nodes will then independently use the transaction proposal to execute the chain code to generate a response to the transaction proposal, and the response result will be returned to the application. The transaction proposal will be independently executed by the peer node, and the peer node will return
        the Proposal response for endorsement. In this example, application A1 generates transaction T1 and proposal P, and the application will send the transaction and proposal to Peer node P1 and Peer node P2 on channel C. P1 executes chaincode S1 with transaction T1 and proposal P, which generates a response R1 to transaction T1, which provides an endorsement E1. P2 executes chaincode S1 with transaction T1 proposal P, which generates a response R2 to transaction T1, which provides an endorsement E2. Application A1 receives two endorsement responses, called E1 and E2, for transaction T1.
        • The application selects the peer node to update according to the endorsement policy. The peer node provides endorsement by adding its own digital signature to the response of the proposal, and uses its private key to provide a signature for the entire load. This endorsement is then used to prove that the organization's peer generated a particular response
        • An application can request an updated proposal response. Unlikely but very serious, the difference in results could be because the chaincode is non-deterministic and an individual peer cannot know that the outcome of their transactions is non-deterministic - until the non-deterministic problem is discovered, Transaction responses must be collected together for comparison
      • Phase 2: Sorting and packaging transactions into blocks
      • The third stage: verification and submission
        The second role of the ordering node is to distribute the block to the Peer node. In this example, ordering node O1 distributed block B2 to Peer node P1 and Peer node P2. Peer P1 processes block B2, producing a new block that will be added to P1's ledger L1. Meanwhile, peer P2 processes block B2, producing a new block that will be added to P2's ledger L1. When this process is complete, the ledger L1 will be consistently updated to Peer nodes P1 and P2, and they may also notify connected applications that the transaction has been processed.
        ​
        • Chaincode is only executed in the first phase - secrecy is guaranteed, but output is shared with all nodes
      • Ordering Nodes and Consensus: The entire transaction processing process is called consensus
  • Ledger: Stores important factual information about business objects, including both the current values ​​of object properties and the history of the transactions that produced those current values
    • Ledger, Facts and State:
      • Ledger:
        • The world state is a database that stores the current value of a set of ledger states. Through the world state, the program can directly access the current value of a ledger state without traversing the entire transaction log to calculate the current value. By default, the ledger state is represented by key-value pairs, which can be created, updated, and deleted, so the state of the world can change frequently.
        • A blockchain is a transaction log that records all the changes that contributed to the current state of the world. The history that helps us understand all the changes that contributed to the current state of the world cannot be tampered with.

          

          
          Ledger L consists of blockchain B and world state W, where world state W is determined by blockchain B. We can also say that the world state W is derived from blockchain B.
      • World state: Only those transactions signed by relevant endorsement organizations will update the world state, real-time changeability.

        

        
        A ledger world state consists of two states. The first state is: key=CAR1 and value=Audi. In the second state there is a more complex value: key=CAR2 and value={model:BMW, color=red, owner=Jane}. Both state versions are 0.
      • Blockchain: A serialized log of a collection of linked blocks, where each block contains a series of transactions, each transaction representing a query or update operation on the state of the world. Each block's header contains a hash of the block's transactions, as well as the hash of the previous block's header. All transactions on the notebook are sequenced and cryptographically linked together. This hashing and linking makes ledger data very secure.

        

        
        Blockchain B includes four blocks B0, B1, B2, and B3. B0 is the first block of the blockchain, also called the genesis block.
        In the above figure, we can see that block B2 has a block data D2, which contains all transactions of B2: T5, T6, T7.
      • block
        • block header

          

          
          Block header details: The block header H2 of block B2 includes block number 2, the hash value CH2 of the current block data D2, and the hash value of the previous block header H1.
        • Block number: The number starts from 0 (initial block), and every time a new block is added to the blockchain, the number of the number will increase by 1.
        • Hash of the current block: the hash of all transactions contained in the current block.
        • Hash of previous block header: The hash of the previous block header in the blockchain.
        • The block data section contains an ordered list of transactions. Block data is written when the ordering service creates blocks.
        • The block metadata section contains the time when the block was written, as well as the block writer's certificate, public key, and signature. The submitter of the block then also adds a valid or invalid flag to each transaction, but since this information is generated at the same time as the block, it is not included in the hash.
      • Transaction: The transaction records the update of the world state and is stored in the block data in the block

        

        
        Transaction T4 is located in the block data D1 of block B1. T4 includes the following contents: transaction header H4, a transaction signature S4, a transaction proposal P4, a transaction response R4 and a series of endorsements E4.
        • The header is denoted by H4, which records some important metadata about the transaction, such as the name and version of the relevant chaincode.
        • The signature section, denoted S4, contains a cryptographic signature created by the client application. This field is used to check that the transaction details have not been tampered with, since the generation of the transaction signature requires the application's private key.
        • The proposal part, denoted by P4, is responsible for encoding the input parameters that the application supplies to the smart contract, which then generates proposal ledger updates. When the smart contract is running, this proposal provides a set of input parameters that together with the current world state determine the new ledger world state.
        • The part of the response is denoted by R4, which records the values ​​before and after the world state in the form of a read-write set (RW-set). The transaction response is the output of the smart contract. If the transaction verification is successful, the transaction will be applied to the ledger, thereby updating the state of the world.
        • As shown in endorsement E4, it refers to a set of signed transaction responses, these signatures are from the relevant organizations specified in the endorsement policy, and the number of these organizations must meet the requirements of the endorsement policy
      • World state database options: including LevelDB and CouchDB - pluggable
        • LevelDB is the default option for the world state database, and it is very appropriate to use LevelDB when the ledger state is a simple key-value pair. The LevelDB database is co-located with the peer node, and it is embedded in the same operating system process as the peer node.
        • CouchDB: The ledger state structure is a JSON document, and the data types involved in business transactions are usually very rich, and CouchDB can support various forms of query and update for these data types. In terms of implementation, CouchDB runs in a separate operating system process, but there is still a 1:1 relationship between nodes and CouchDB instances. Smart contracts cannot see any of the above.
      • Example ledger fabcar

        

        
        Ledger L contains a world state W and a blockchain B. Among them, W contains four states, and the keys of each state are: CAR0, CAR1, CAR2 and CAR3. And B contains two blocks 0 and 1. Block 1 contains four transactions: T1, T2, T3, T4.
      • Namespaces
        • Each chaincode has its own world state that is separate from the world state of all other chaincodes. The world state resides in a namespace, so only smart contracts that reside in the same chaincode can access a given namespace.
      • Channels: Each channel has a completely independent ledger
  • sorting service
    • Orderer and channel configuration: Orderers also maintain a list of organizations that are allowed to create channels - federations. The table itself is kept in the configuration of the "orderer system channel" (also known as the "orderer system channel"), this list and the channel it resides in can only be edited by the orderer administrator
    • Ordering node and identity (MSP): The ordering node belongs to the organization and uses a separate certificate authority (CA) for each organization. As for which CA is self-defined
    • Ordering Nodes and Transaction Flow
      • Phase 1: Proposal
      • Phase 2: Order and pack transactions into blocks

        

        
        The first role of an orderer is to package the ledger updates for proposals. In this example, application A1 sends transaction T1 to orderer O1, endorsed by E1 and E2. At the same time, application A2 sends transaction T2 endorsed by E1 to orderer O1. O1 packs transaction T1 from application A1 and transaction T2 from application A2, as well as transactions from other applications in the network, into block B2. We can see that in B2, the order of transactions is T1, T2, T3, T4, T6, T5, but this may not be the order in which these transactions arrived at the orderer! (This example shows a very simple ordering service configuration with only one orderer.)
        • The number of transactions in a block depends on the desired size of the block and the channel configuration parameters related to the maximum interval time (to be exact, the BatchSize and BatchTimeout parameters)
        • Blocks generated by the ordering service are final, and the finality of Hyperledger Fabric means that there are no ledger forks, that is, verified transactions are never rewritten or deleted.
        • The ordering node only sorts, no transactions occur
      • Phase 3: Verification and Submission: Not every Peer node needs to be connected to an ordering node, Peer nodes can use the gossip protocol to associate blocks to other nodes

        

        
        The second role of ordering nodes is to distribute blocks to peer nodes. In this example, orderer O1 distributes block B2 to nodes P1 and P2. Node P1 processes block B2, adding a new block to ledger L1 on P1. At the same time, node P2 processes block B2, thereby adding a new block to ledger L1 on P2. Once this process is complete, ledger L1 on nodes P1 and P2 is consistently updated, and each node can notify connected applications that a transaction has been processed.
        • The node's endorsement matches the endorsement policy and is not invalidated by other recently committed transactions that may be running when the transaction was originally endorsed. Invalid transactions still remain in the blocks created by the orderer, but the node marks them as invalid and does not update the state of the ledger.
      • Sorting service implementation
        • Raft (recommended): As a new feature of v1.4.1, Raft is a Crash Fault Tolerant (CFT) sorting service based on the Raft protocol in [etcd](https://coreos.com/etcd/) . Raft follows a "leader-follower" model, in which a leader node is elected on each channel, whose decisions are replicated by followers. The Raft ordering service will be easier to set up and manage than the Kafka-based ordering service, and its design allows different organizations to contribute nodes to the distributed ordering service.
          • Crash tolerance: the system can tolerate the loss of nodes, including the leader node, provided that there is a large number of orderers remaining (called a "quorum")
          • Raft is easier to set up, natively supported, and with Raft, everything is embedded in your orderer.
          • Kafka and Zookeeper are not designed to run on a large network, you need to obtain the required mirroring yourself, Kafka uses a server pool
          • Raft concept
            • Log entry: The primary unit of work in a Raft ordering service is a "log entry", and the complete sequence of entries is called a "log". If a majority of members (in other words a quorum) agree on the entry and its order, then we consider the entry to be consistent and replicate the log to different orderers
            • Consenter set: Orderers that actively participate in the consensus mechanism for a given channel and receive a copy of the channel's log.
            • Finite-State Machine (FSM). Each orderer in Raft has a FSM which together ensures that the sequence of logs in each orderer is deterministic (written in the same order).
            • Quorum. Describes the minimum number of agreeers that need to confirm a proposal.
            • Leader
            • Follower
          • Raft in transaction flow: Channel creators (and channel managers) are able to select a subset of available orderers and add or remove orderers as needed (as long as only one node is added or removed at a time). Neither eer nodes nor applications need to know who is the leader node at any given time. Only the orderer needs to know.
          • How Raft elects a leader: A node is always in one of three states: follower, candidate, or leader. All nodes initially start as followers. In this state, they can accept log entries from the leader (if one has already been elected), or vote for the leader. If no log entries or heartbeats are received for a certain period of time (e.g., 5 seconds), the node promotes itself to the candidate state. In the candidate state, nodes request votes from other nodes. If a candidate receives a quorum of votes, then he is promoted to leader. The leader must accept new log entries and replicate them to followers.
          • Snapshots: Raft uses a process called "snapshots" where the user defines how many bytes of data to keep in the log. This amount of data will determine the number of blocks (this depends on the amount of data in the block. Note that only complete blocks are stored in the snapshot).
            Suppose lagged replica R1 has just reconnected to the network. Its latest block is 100. Leader L is at block 196 and is configured to snapshot 20 blocks. R1 will thus receive block 180 from L, and then dispatch requests for blocks 101 to 180. Then blocks 180 to 196 will be replicated to R1 via the normal Raft protocol.
        • Kafka (deprecated in v2.0): Similar to Raft-based sorting, Apache Kafka is a CFT implementation that uses a "leader and follower" node configuration. Kafka utilizes a ZooKeeper for management. Kafka-based ordering services have been available since Fabric v1.0, but many users may find the additional administrative overhead of managing a Kafka cluster daunting or undesirable.
        • Solo (deprecated in v2.0): The Solo implementation of the ordering service is for testing only, and only contains a single orderer. It is deprecated and may be completely removed in a future release. Existing Solo users should migrate to a single-node Raft network to gain the same functionality.
  • Smart contracts and chaincode
    • smart contract

      

      
      Smart contracts define rules between different organizations with executable code. Applications invoke smart contracts to generate transactions that are recorded on the ledger.
    • The smart contract defines the transaction logic that controls the life cycle of business objects in the world state, and then the transaction logic is packaged into the chain code, and then the chain code will be deployed to the blockchain network. Smart contracts can be thought of as transaction managers, and chaincode manages how smart contracts are packaged for deployment

      

      
      A smart contract is defined in a chaincode. And multiple smart contracts can also be defined in the same chaincode. When a chaincode is deployed, all smart contracts in that chaincode are available to applications.
    • Ledger: Smart contracts mainly write (put), read (get) and delete (delete) the state in the world state, and can also query the immutable blockchain transaction records.
      • blockchain
      • state of the world
      • async createCar(ctx, carNumber, make, model, color, owner) { const car = { color, docType: 'car', make, model, owner, }; await ctx.stub.putState(carNumber, Buffer.from(JSON.stringify(car)));}
    • Endorsement: Indicates which organizations in the blockchain network must sign the transaction generated by a given smart contract to declare that the transaction is valid

      

      
      Every smart contract has an endorsement policy associated with it. This endorsement policy defines which organizations must agree to a transaction generated by a smart contract before it can be certified as valid.
      • Three of the four organizations participating in the blockchain network must sign the transaction before it is considered valid. All transactions, whether valid or invalid, are added to the ledger, but only valid transactions update the world state.
    • valid transaction
      • Smart contracts extract a set of input parameters called transaction proposals and use them in conjunction with program logic to read and write the ledger. Changes to the state of the world are captured as transaction proposal responses (or simply transaction responses), which contain a read Write set, which contains both the read state and the new state that has not been written (if the transaction is valid)
      • The world state is not updated while executing the smart contract

        

        
        All transactions have an identifier, a proposal, and a response signed by a group of organizations. All transactions, valid or not, are recorded on the blockchain, but only valid transactions update the world state.
      • A transaction is distributed to all nodes in the network, and each node validates it through two phases.
        • First, the transaction is checked against the endorsement policy to ensure that the transaction has been signed by sufficient organizations.
        • Second, continue to check the transaction to ensure that its transaction readset matches the current value of the world state when the transaction is signed by the endorsing node, and that it has not been updated in the middle. If a transaction passes both tests, it is marked as valid.
    • aisle

      

      
      Channels provide a completely independent communication mechanism between a group of organizations. When a chaincode definition is submitted to a channel, all applications on the channel can use the smart contracts in this chaincode.
      • The smart contract code is installed in the chain code package of the organization node, but only after the chain code is defined on the channel, the members on the channel can execute the smart contract
    • Intercommunication: A smart contract can call other smart contracts on the same channel as well as smart contracts on other channels. This allows smart contracts to read and write world state data that would otherwise be inaccessible due to smart contract namespaces
    • system chaincode
      • Lifecycle System Chaincode (LSCC)
      • Configure System Chaincode (CSCC)
      • Query System Chaincode (QSCC)
      • Endorsement System Chaincode (ESCC)
      • Verification System Chaincode (VSCC)
    • Chaincode life cycle - definition on the channel
      • Channel members agree on the following steps, which not every organization in the channel needs to complete:
        • Packaging chaincode
        • Install chaincode on peers
        • Approve a chaincode definition in the organization
        • Apply chaincode to channel
      • Phase 1: Packaging smart contracts

        

        
        The chaincode needs to be packaged in a tar file, ending with a .tar.gz file extension.
        • The tar file needs to contain two files (no directories): the metadata file "metadata". Json" and another tar "code.tar.gz" contains the chaincode file.
        Metadata. Contains a json specifying the chaincode language, code path, and package label. You can see an example of a metadata file below:
        The chaincode is created by Org1 and Org2 are packaged separately. Both orgs use MYCC_1 as their package label to identify packages using name and version. It is not necessary for the orgs to use the same package label
      • Phase 2: Install chaincode on peers

        

        
        The peer administrators from Org1 and Org2 install the chaincode package MYCC_1 onto the peers connected to the channel.
        Installing the chaincode package will build chaincode and create a MYCC_1:hash of the package identifier.
      • Phase 3: Approve the chaincode definition in the organization
        • The organization approval process is equivalent to acceptance voting. Channel members can use it after allowing it to be used. It involves the following parameters (Package Identifier) ​​that need to be consistent between organizations.
          • name
          • version
          • sequence
          • endorsement policy
          • collection configuration
          • ESCC/VSCC plugins
          • Initialization: If you use the low-level API provided by the Fabric Chaincode Shim API, then your Chaincode needs to include the Init function for initializing the Chaincode

        • 

          
          Org admins from Org1 and Org2 approve the chaincode definition for their organization MYCC.
          A chaincode definition includes fields such as chaincode name, version, and endorsement policy. Since both organizations will be using chaincodes to support transactions, the approval definitions for both organizations need to include packageID.
          ​
      • The fourth stage: when a sufficient number of channel members approve the chaincode definition, the chaincode definition can be submitted to the channel, first sent to the channel member peers, peers verify the approved chaincode definition, endorse it, submit it to the sorting service, and then return to channel

        

        
        An org admin from Org1 or Org2 commits the chaincode definition to the channel. The definition on the channel does not include the packageID.
        • Organizations can approve chaincode definitions without installing chaincode packages
        • Once MYCC is defined on the channel, Org1 and Org2 can start using the chaincode. The first invocation of the chaincode starts the chaincode container on each peer.
    • Update the chain code: the chain code can update the endorsement form, and it will take effect immediately after submitting it to the channel, no need to call it specially
      • Repack chaincode
      • Install the new chaincode package on the node
      • Approve a new chaincode definition
      • commit the definition to the channel
  • private data
    • Private data collection:

      

      • Actual private data: the gossip protocol is sent point-to-point to organizations that can see it, and others cannot see it
      • Hash value of the data: the public part, written into the ledger after endorsement sorting
    • Regarding whether to use a separate channel or a private data collection within an existing channel:
      • Channel: The entire ledger needs to be kept secret
      • collection: part

        

        
        Taking Figure as an example, different confidentiality requirements between different organizations
    • Transaction flow using private data
      • A client application submits a request for proposal to have endorsers belonging to an authorized set execute a chaincode function (read or write private data). Private data, or data used to generate private data in chaincode, is sent in the proposal's transient field.
      • The endorsement node simulates the transaction and stores the private data in the transient data store (the node's local temporary storage). They distribute private data to authorized Peer nodes through [gossip]() according to the policy of the organization collection.
      • Endorsing peers send proposal responses back to the client. Proposal responses contain the endorsed read-write set, which contains the public data, and any private data key and value hashes. Private data will not be sent back to the client. More about endorsements with private data
      • Client applications submit transactions (including proposal responses with private data hashes) to the ordering service. Transactions with private data hashes are also included in blocks. Blocks with private data hashes are distributed to all nodes. In this way, all nodes in the channel can verify transactions with private data hash values ​​in the same way without knowing the real private data.
      • At the time of block submission, authorized nodes will determine whether they have access to private data according to the collective policy. If nodes have access, they first check their local transient data store to see if they have received private data at the time of chaincode endorsement. If not, they try to pull the private data from other authorized nodes, then verify the private data against the hash on the public block and submit the transaction and block.
      • When verification or submission is complete, private data is moved to these nodes' private databases and copies of private read-write storage. These private data stored in the transient data store are then deleted.
    • share private data
      • Use the corresponding public key to track the public state, and the same for private
      • Control whether the client can access private data through the chain code (whether it is in the certificate or whether the password is consistent)
      • out of band sharing: verification hash
      • Share private data with other collections: the chaincode GetPrivateDataHash() verifies whether there is private data in the collection, deletes the data in your collection after the verification is successful, and generates the key in the collection of other organizations, which may require additional endorsement
      • Use private data for transaction approval: To obtain the other party's approval before the transaction is completed, the chain code allows them to have a pre-consent or sign a private key on his/your private data set, and then use GetPrivateDataHash() to check
      • Keeping Traders Private: Using a Hash of Private Data