# Network Components (Private Blockchain)

Different components of Hyperledger Fabric:&#x20;

**ORDERERS** - Under a domain, there are orderers (can be multiple instances) responsible for ensuring that all the peers in the network have committed a transaction. When a peer proposes and executes a transaction, the orderer is informed about the new transaction, and it forwards and commits this block to all adjacent peers.

**Note:** Orderers are not dependent on one organization. However, it is suggested to have multiple orderers to reduce failure rates.

**Organizations:** Organizations are the containers for the peers and respective certificate authorities (CA). Each organization has its own CA and a list of peers. Usually, organizations are used for physical separation of the blockchain network, where each organization that uses your product can set up their physical machines and join your network.

**CERTIFICATE AUTHORITIES(CA)-** The certificate authority is responsible for creating users' certificates. It is used for verifying ownership in the network. Each certificate authority is tied to an organization.

**PEERS:** The peers are nodes that are connected to clients and are responsible for committing transactions to the world state. Each peer has its copy of transactions in a CouchDB database. An organization can have more than one peer. Though having multiple peers to avoid data loss is advised, having more than 3 or 4 peers might result in higher latency rates.

**ENDORSER PEERS:** The peers can be marked as Endorser peers (i.e. Endorsing peers). Upon receiving the "transaction invocation request" from the Client application, the Endorser peerValidates the transaction. i.e., Check certificate details and roles of the requester. Executes the Chaincode(i.e. Smart Contract) and simulates the transaction's outcome. But it does not update the ledger. At the end of the two tasks, the Endorser may approve or disapprove of the transaction. Only the Endorser node executes the Chaincode (Smart Contract), so there is no necessity to install Chaincode in every node of the network, which increases the scalability of the network.

**ANCHOR PEERS:** The anchor peer or cluster of Anchor peers is configured at the time of Channel configuration. In Hyperledger Fabric, you can configure secret channels among your peers, and transactions among the peers of that channel are visible only to them. Anchor peer receives updates and broadcasts the updates to the other peers in the organization. Anchor peers are discoverable. So any peer marked as an Anchor peer can be discovered by the Orderer peer or any other peer.

**ORDERER PEERS:** The ordered peers are considered the central communication channel for the Hyperledger Fabric network. Orderer peer/node is responsible for consistent Ledger state across the network. Orderer peer creates the block and delivers that to all the peers. Orderer is built on a message-oriented architecture like solo, Kafka, or Raft. In Hyperledger Fabric terms, a chaincode is a piece of code (written in Go, node.js, or Java) enforcing contract processing between parties. Chaincode is a packaged smart contract code prepared for installation. Essentially, a smart contract lies within a chaincode package. In general, the smart contract is where automation of processes between organizations comes into place. Smart contracts work with data on the blockchain to typically automate business and workflows.

**CONSENSUS:** A consensus is an agreement about the order of transactions between individual ordering service nodes. Hyperledger Fabric currently supports three different mechanisms or implementations of consensus — SOLO, Kafka, and Raft. And for production networks, SOLO and Kafka are not recommended. SOLO provides neither high availability (HA) nor decentralization. Kafka does provide HA but not decentralization, while Raft offers both. Click here to understand how Raft provides consensus.

**CHANNELS:** The channels are ledgers, ways to organize and secure data. Organizations join channels and thus get access to specific ledgers. Hence the flow of assets can only occur between two organizations.

**MEMBERSHIP SERVICE PROVIDER (MSP)** In Fabric, an organization is identified by its MSP. In Hyperledger Fabric Network, each organization is identified by its Membership Service Provider identification (MSP ID). To be accurate, an organization can consist of one or multiple MSPs, but in most cases, you will probably use a single MSP to represent an organization.

**CHAINCODE:** *A smart contract defines the rules between different organizations in executable code. Applications invoke a smart contract to generate recorded transactions on the ledger.*

**LEDGER**&#x20;

A ledger consists of two distinct, though related, parts – a "blockchain" and the "state database", also known as the "world state". Unlike other ledgers, blockchains are **immutable** – that is, once a block has been added to the chain, it cannot be changed. In contrast, the "world state" is a database containing the current value of the set of key-value pairs added, modified, or deleted by the group of validated and committed transactions in the blockchain.

It's helpful to think of one **logical** ledger for each channel in the network. In reality, each peer in a channel maintains its copy of the ledger, which is consistent with every other peer's copy through a consensus process. **Distributed Ledger Technology**(**DLT**) is often associated with this kind of ledger – one that is logically singular but has many identical copies distributed across a set of network nodes (peers and the ordering service).

![Hyperledger Network Architecture](https://1257329328-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkK9YItDy7glXHNQBo61L%2Fuploads%2FMvEj2VM7qb62tSfR7J7N%2FFrame%201\(3\).jpg?alt=media\&token=1ec86c68-1b88-4698-9145-3fd10ddd4a80)
