Few Concepts In Hyperledger Fabric

Nodes:

In Hyperledger Fabric entities which interact with communication procedure in the network are called nodes.

Node Types in Hyperledger Fabric:

Mainly there are three types of nodes in Hyperledger

1. Client
2. Peer
3. Orderer

Client- Who submits the transaction proposal to endorsing peer nodes and broadcast transaction-proposal to ordering nodes.

Peer-Nodes that commit transactions and maintain the ledger state. Peers can Have another two roles such as Endorsing peer(Chaincode installed) Anchor peer(Chaincode installed or not)

Orderer- communication service that implements a delivery guarantee, such as atomic or total order broadcast

Channel:

The subnet of the main blockchain is referred to as Channel. You can have 1 to any number of channels in on Hyperledger fabric blockchain network. But At the configuration level number of channels in your network should be Finalized. Any peer or node can be a part of many channels. Transaction details in one channel are only visible to the entities in that channel. Each channel should have its own chain code and policies.

Popular Programming languages with Hyperledger Fabric:

1. Go
2. JAVA
3. Node

The special thing is Hyperledger Fabric itself is written in the Go language.

Certificate Authority:

Fabric CA takes care of registration, issuance of e-certificates, role assignment, renewals and revocation to the various nodes before they can start communicating in the network.

Consensus Algorithm:

Hyperledger fabric follows a modular architecture so different consensus mechanisms are pluggable as the requirements. Now Hyperledger fabric is used Solo and Kafka to reach consensus.

Properties which are achieved by consensus as follows:

1. Safety — Each node is guaranteed the same sequence of inputs and results in the same output on each node. When the nodes receive an identical series of transactions, the same state changes will occur on each node.
2. Liveliness — Each non-faulty node will eventually receive every submitted transaction.

• Solo — It is a Hyperledger Fabric ordering mechanism most typically used by developers experimenting with Hyperledger Fabric networks. SOLO involves a single ordering node. It is not used in the production environment.
• Kafka — In Kafka, only the leader does the ordering and only the in-sync replicas can be voted as the leader. This provides crash fault-tolerance and finality happens in a matter of seconds. While Kafka is a crash fault-tolerant, it is not Byzantine fault-tolerant, which prevents the system from reaching an agreement in the case of malicious or faulty nodes.

Distributed Ledger — Data and Database:

• Hyperledger Fabric allows ledger data to be stored in multiple different formats.
• Hyperledger Fabric distributed ledger is a combination of world state database and transaction logs.
• Hyperledger Fabric allows ledger data to be stored in the following subsystems:
• The key-value database such as LevelDB/CouchDB for storing the state of the ledger. This is also called a world state. CouchDB is storing data in JSON format and It supports
• Logs storing transaction logs having transaction details.