Introduction
Consensus in blockchain involves nodes agreeing on the same order of transactions. Ordering nodes send to Kafka transactions and receive from Kafka transactions in the same order since Kafka presents an abstraction of a shared queue.
All orderers create blocks when they read enough messages or enough data from kafka. Also - if a transaction was sent but no block was created, and enough time (timeout) passed - the Orderer node would send a special message to Kafka that would signal all ordering nodes to cut a block. This ensures that all orderers cut blocks based on timeout, but also that they cut the same blocks.
Each leader peer connects to a random Orderer and then sends a request, saying from what block index it wants to receive blocks. Then, the Orderer reads the blocks from its file system and sends them to the peer. When the peer receives the blocks, it also sends them to other peers via the gossip component inside the peer, which ensures peers stay in sync.
Clients
Clients are applications that act on behalf of a person to propose transactions on the network.
Peers
Peers maintain the state of the network and a copy of the ledger. There are two different types of peers: endorsing and committing peers. However, there is an overlap between endorsing and committing peers, in that endorsing peers is a special kind of committing peers. All peers commit blocks to the distributed ledger. Endorsers simulate and endorse transactions Committers verify endorsements and validate transaction results, before committing transactions to the blockchain.
Ordering Service
The ordering service accepts endorsed transactions, orders them into a block, and delivers the blocks to the committing peers.
Consensus
In a distributed ledger system, the consensus is the process of reaching an agreement on the next set of transactions to be added to the ledger. In Hyperledger Fabric, the consensus is made up of three distinct steps:
Transaction Flow (Step 1)
Within a Hyperledger Fabric network, transactions start with client applications sending transaction proposals, or, in other words, proposing a transaction to endorsing peers.
Client applications are commonly referred to as applications or clients, and allow people to communicate with the blockchain network. Application developers can leverage the Hyperledger Fabric network through the application SDK.
Transaction Flow (Step 2)
Each endorsing peer simulates the proposed transaction, without updating the ledger. The endorsing peers will capture the set of Read and Written data, called RW Sets. These RW sets capture what was read from the current world state while simulating the transaction, as well as what would have been written to the world state had the transaction been executed. These RW sets are then signed by the endorsing peer and returned to the client application to be used in future steps of the transaction flow.
Endorsing peers must hold smart contracts to simulate the transaction proposals.
Transaction Endorsement
A transaction endorsement is a signed response to the results of the simulated transaction. The method of transaction endorsements depends on the endorsement policy which is specified when the chaincode is deployed. An example of an endorsement policy would be “the majority of the endorsing peers must endorse the transaction”. Since an endorsement policy is specified for a specific chaincode, different channels can have different endorsement policies.
Transaction Flow (Step 3)
The application then submits the endorsed transaction and the RW sets to the ordering service. Ordering happens across the network, in parallel with endorsed transactions and RW sets submitted by other applications.
Transaction Flow (Step 4)
The ordering service takes the endorsed transactions and RW sets, orders this information into a block, and delivers the block to all committing peers.
The ordering service, which is made up of a cluster of orderers, does not process transactions, smart contracts, or maintain the shared ledger. The ordering service accepts the endorsed transactions and specifies the order in which those transactions will be committed to the ledger.
The Fabric v1.0 architecture has been designed such that the specific implementation of ‘ordering’ (Solo, Kafka, BFT) becomes a pluggable component. The default ordering service for Hyperledger Fabric is Kafka.
Ordering (Part 1)
Transactions within a timeframe are sorted into a block and are committed in sequential order.
In a blockchain network, transactions have to be written to the shared ledger in a consistent order. The order of transactions has to be established to ensure that the updates to the world state are valid when they are committed to the network. Unlike the Bitcoin blockchain, where ordering occurs through the solving of a cryptographic puzzle, or mining, Hyperledger Fabric allows the organizations running the network to choose the ordering mechanism that best suits that network. This modularity and flexibility make Hyperledger Fabric incredibly advantageous for enterprise applications.
Ordering (Part 2)
Hyperledger Fabric provides three ordering mechanisms: SOLO, Kafka, and Simplified Byzantine Fault Tolerance (SBFT)
SOLO is the Hyperledger Fabric ordering mechanism most typically used by developers experimenting with Hyperledger Fabric networks. SOLO involves a single ordering node.
Kafka is the Hyperledger Fabric ordering mechanism that is recommended for production use. This ordering mechanism utilizes Apache Kafka, an open-source stream processing platform that provides a unified, high-throughput, low-latency platform for handling real-time data feeds. In this case, the data consists of endorsed transactions and RW sets. The Kafka mechanism provides a crash fault-tolerant solution to ordering.
SBFT stands for Simplified Byzantine Fault Tolerance. This ordering mechanism is both crash fault-tolerant and byzantine fault-tolerant, meaning that it can reach an agreement even in the presence of malicious or faulty nodes. The Hyperledger Fabric community has not yet implemented this mechanism, but it is on their roadmap.
Transaction Flow (Step 5)
The committing peer validates the transaction by checking to make sure that the RW sets still match the current world state. Specifically, the Read data that existed when the endorsers simulated the transaction is identical to the current world state. When the committing peer validates the transaction, the transaction is written to the ledger, and the world state is updated with the Write data from the RW Set.
If the transaction fails, that is, if the committing peer finds that the RW set does not match the current world state, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the world state will not be updated.
Committing peers are responsible for adding blocks of transactions to the shared ledger and updating the world state. They may hold smart contracts, but it is not a requirement.
Transaction Flow (Step 6)
Lastly, the committing peers asynchronously notify the client application of the success or failure of the transaction. Applications will be notified by each committing peer.
In addition to the multitude of endorsement, validity, and versioning checks that take place, there is also ongoing identity verification happening during each step of the transaction flow.
Access control lists are implemented on the hierarchical layers of the network (from the ordering service down to channels), and payloads are repeatedly signed, verified, and authenticated as a transaction proposal passes through the different architectural components.
