Are blocks mined in HyperLedger Fabric?

Hyperledger is an umbrella of blockchain technologies. Hyperledger Fabric, mentioned above, is one of them. Hyperledger Sawtooth also does not use mining and adds these consensus algorithms:

• PoET Proof of Elapsed Time (optional Nakamoto-style consensus algorithm used for Sawtooth). PoET with SGX has BFT. PoET Simulator has CFT. Not CPU-intensive as with PoW-style algorithms, although it still can fork and have stale blocks . See PoET specification at https://sawtooth.hyperledger.org/docs/core/release s/latest/architecture/poet.html
• RAFT Consensus algorithm that elects a leader for a term of arbitrary time. Leader replaced if it times-out. Raft is faster than PoET, but is not BFT (Raft is CFT). Also Raft does not fork.
• With unpluggable consensus, another consensus algorithm can be changed without reinitializing the blockchain or even restarting the software.

For completeness, the original consensus algorithm with bitcoin (and does use mining) is:

• PoW Proof of Work. Completing work (CPU-intensive Nakamoto-style consensus algorithm). Usually used in permissionless blockchains

Hyperledger Validating Peers (VPs) do not mine blocks and do not share the blocks between them. Here is how it works:

1. A transaction is send to one trusted VP.
2. The VP broadcasts the transaction to all other VPs.
3. All VPs reach consensus (using PBFT algorithm) on the order to follow to execute the transactions.
4. All VPs execute the transactions "on their own" following the total order and build a block (calculating hashes mainly) with the executed transactions.

All the blocks will be the same because: the transaction execution is deterministic (should be) and the number of tx in a block is fixed.

According to Hyperledger Fabric 1.X

1. User through Client SDK send the transaction proposal to Endorsing Peers.
2. Endorsing Peer check the transaction and make endorsement proposal of transaction(with read/write set (previous value/Changed value)) and send to again client SDK.
3. Client SDK wait for all endorsement, once it get all endorsement proposal it make one invocation request and send to Orderer.
4. Orderer verify invocation request rent by client SDK by checking Policies defined(Consensus), verify the transaction and add to the block.
5. According to configuration defined for block, after specified time or number of transaction it form a Hash of block by using transaction hash, metadata and previous block hash.
6. The blocks of transactions are “delivered” to all peers on the channel by the Orderer.
7. All committing peers verify the endorsing policy and ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. After this all the transactions in the block and update the ledger with new block and current state of asset.

Ledger Contains

• 1) Current state Database(Level BD or Couch DB)
• 2) Blockchain(Files)(Linked blocks)

Read the transaction flow of hyperledger fabric

Check image for reference