Introduction to Hyperledger Terminology _hyperledger

Anchor Peer-Anchor node is a peer-to-peer node in the channel that can be detected by all peer nodes and can communicate with it. Each member of the channel has one (or more, in case of a single point of failure) Anchor node that allows nodes belonging to different memberships to discover other nodes that exist in the channel.

Block-Blocks on a channel, (Block is) a set of ordered transactions. Blocks are often connected to leading blocks by means of cryptography (Hash values).
Chain-Chain Chain is the transaction log with hash connection between blocks. Peer receives the transaction block from the order service, and then appends the block to the hash chain in the peer file system, based on the endorsement policy and the transactions on the block that the concurrency conflict marks.
Chaincode-Chain Code chain code is a running on the ledger software, it can encode assets, where the transaction instruction (or business logic) can also be used to modify the asset.
The Channel-channel channel is a private block chain built on the "Fabric" network, which realizes the isolation and secrecy of the data. The channel-specific ledger is shared with all peer nodes in the channel, and the trader must pass the correct validation of the channel to interact with the ledger. The channel is defined by a "configuration block".

Commitment-Submitting each peer node in a channel verifies the ordered chunks of the transaction, and then submits (writes or appends) the chunks to each copy of the ledger on the channel. Peer nodes also mark the status of each transaction in each block as valid or invalid.

concurrency control version Check-concurrency controlled versioning (CCVC) CCVC is a way to maintain state synchronization between peer nodes in the channel. The peer node performs transactions in parallel, and before the transaction is submitted to the ledger, the peer checks whether the data read by the transaction during execution is modified. If the read data is changed between execution and commit, a CCVC conflict is raised, the transaction is marked as invalid in the ledger, and the value is not updated to the state database.

Configuration block-configuration blocks contain configuration data that defines members and policies for the system chain (sort service) or channel. Configuration modifications to a channel or the entire network (for example, members leaving or joining) will result in a new configuration block being generated and appended to the appropriate chain. This configuration block will contain the contents of the original block plus the increment.

Consensus-consensus is a broad term that runs through the entire transaction process, and is used to generate an agreement for ordering and to confirm the correctness of the set of transactions that comprise the block.

Present state-The current states of the ledger status represents the latest values for all keys in their chain transaction log. Peer will submit the modified value corresponding to each transaction in the handled block to the ledger's current state, because the present state represents all the latest k-v known to channel, so State is also called the world State. Chaincode execution transaction proposal is the current state.

Dynamic Membership-Dynamic member fabric supports dynamically adding-removing members, peers, and ordering service nodes without affecting the entire network's operability. Dynamic membership is critical when a business relationship is adjusted or additional-remove entities are required for a variety of reasons.

Endorsement-Endorsement endorsement refers to the process by which a peer performs a transaction and returns Yes-no to a client app that generates a transaction proposal. The Chaincode has the corresponding endorsement policies, which specifies the endorsing peer.
Endorsement policy-Endorsement strategy endorsement Policy defines the necessary combination conditions for peer and response (endorsements) on channel that depend on a specific Chaincode execution transaction (that is, a condition that returns Yes or no). Endorsement policy may specify the minimum endorsement node number or the minimum endorsement node percentage for a chaincode to be endorsed for the transaction. The endorsement strategy is organized and managed by the endorsement node based on the application and the level of expectation against bad behavior. You need to specify an endorsement policy when install and instantiate Chaincode (deploy TX).

Fabric-ca FABRIC-CA is the default certificate management component that issues PKI-based certificates to network members and their users. The CA issues a root certificate (Rootcert) for each member, a registration certificate (ECERT) for each authorized user, and a large number of transaction certificates (Tcerts) for each enrollment certificate.

Genesis block-initial chunk Genesis blocks are configuration blocks that initialize the block chain network or channel, and are the first block on the chain.
Fabric-ca FABRIC-CA is the default certificate management component that issues PKI-based certificates to network members and their users. The CA issues a root certificate (Rootcert) for each member, a registration certificate (ECERT) for each authorized user, and a large number of transaction certificates for each certificate of registration (Tcerts)
Gossip PROTOCOL-GOSSIP Protocol Gossip data Transfer Protocol has three functions: 1 manage peer discovery and channel member; 2 channel broadcast ledger data 3) Synchronize the ledger data between all the peer on the channel.
Invoke-invokes the function that is used to invoke the Chaincode. Chaincode Invoke is a trading proposal, and then performs a modular process (endorsement, consensus, validation, submission). The structure of Invoke is a function and an array of parameters.

Leading Peer-the dominant node each member can have multiple Peer on the channel of its subscription, and one Peer communicates with the channel service as leading Peer ordering. The ordering service passes the block to leading peer, which is then distributed to other peer under the same member.

Ledger-Ledger ledger is a channel chain and the world state maintained by each channel in peer.
Member-Members have legitimate independent entities of the network's unique root certificate. Network components such as peer node and app client are linked to a member.

Membership Service Provider-msp MSP is a System abstraction component that provides certificates to client and peer. The client authenticates their transaction with a certificate, peer the endorsement of the transaction with a certificate. This interface is closely related to the transaction processing component of the system and is designed to allow the defined Membership service component to be inserted smoothly in this way without modifying the core of the system's transaction processing component.

Membership Services-Member Services Members service authenticates, authorizes, and manages identities on a licensed block chain network. The code for member services running in peer and order will authenticate and authorize block chain operations. It is based on the MSP implementation of PKI. The Fabric-ca component implements Member services to manage identities. In particular, it deals with the issuance and revocation of Ecert and Tcert. Ecert is a long-term credential; Tcert is a short-term credential, anonymous and not linked.

Ordering Service-Sort service or consensus services a collection of transactions sorted into a node of the block. The ordering service is independent of the peer process and deals with all channel on the network on a first-come-first-served basis. The ordering service supports pluggable implementations, and currently implements solo and Kafka by default. The ordering service is a public binding of the entire network, containing the encryption material associated with each member.

Peer-Node A network entity that maintains ledger and runs the Chaincode container to perform read-write operations on ledger. Peer is owned and maintained by member.

Policy-Strategy has endorsement strategy, validation strategy, block submission strategy, Chaincode management strategy and network-channel management strategy.

Proposal-Proposal an endorsement request for a peer in the channel. Each proposal is either Chaincode instantiate or Chaincode invoke.

Query-queries the query for value of a key in the current state.

The Software Development KIT-SDK SDK provides developers with a structured library environment for writing and testing chain code applications. The SDK is fully configurable and extensible through standard interfaces, and components such as signature encryption algorithms, log frames, and state stores can be easily replaced. The SDK API uses GRPC for transaction processing, Member Services, node traversal, and event handling to communicate with the fabric accordingly. The SDK currently supports Node.js, Java, and Python.

State database-statedb in order to efficiently read and write from the Chaincode, the current state data is stored in Statedb, including Leveldb and COUCHDB.

System Chain-Systems chain contains configuration blocks that define the network at the system level. The system chain exists in the ordering service, similar to the channel, with an initial configuration containing the following information: MSP information, Policy, and information configuration. Any changes to the entire network (for example, new org joins or adds new ordering nodes) will result in new configuration blocks being added to the system chain. A system chain can be viewed as a channel or a set of channel public binding. For example, a collection of financial institutions can form a consortium (expressed in system chain) and then create channel based on its same or different business.

Transaction-Transaction Chaincode invoke or instantiate operation. Invoke is requesting read-write from Ledger set;instantiate is requesting the Chaincode container to be started on peer