# QiOi: Performance Isolation for Hyperledger Fabric
## 2 Background
### Hyperledger Fabric  
The operation of Fabric is divided into three phases - execute, order, and validate, with each phase conducted by different components such as clients (execute), peers (execute and validate), and ordering service nodes (order) as illustrated in Figure 1. The functionalities of each component are as follows.  
* **Clients** are the end-users of blockchain networks that submit transaction proposals to peers (1 in Figure 1). The transaction proposals are executed and endorsed by the peers. When clients collect enough endorsements on a transaction proposal from peers (2), they assemble a transaction and broadcast this to ordering service nodes (3).
* **Peers** execute transaction proposals and validate transactions. There are two types of peers--endorsing peers and committing peers. The endorsing peers receive the transaction proposal from clients, execute the operation on the specified chaincode, and run the endorsement system chaincode (ESCC) to verify the transaction proposal.  
Figure 1: The Fabric component and transaction flow.  
A chaincode is a program code that implements and executes the Fabric service logic. The chaincode is the key to Fabric service and runs as a Docker container, isolated from the peers. ESCC is one of the special chaincodes for managing the Fabric system and maintaining parameters. Then, if the verification results satisfy the endorsement policy, the endorsing peers return the transaction proposal to the client with a digital signature using the private key of the endorsing peers (2). The committing peers validate new blocks with the endorsing peers by executing the validation system chaincode (VSCC) before the actual commit of the new blocks to the distributed database, called a ledger. When validation is completed, a new block that contains the proposed transaction is stored in the ledger. Every peer maintains the ledger locally. Then, one of the peers informs the clients that the transaction has been registered successfully (5).
* **Ordering service nodes (i.e., orderers)** are the nodes that compose the ordering service. The ordering service determines the sequence of transactions into blocks using a consensus protocol. Fabric offers three consensus protocols--Solo, Raft, and Kafka. Solo is intended for testing only and consists of a single orderer. Raft and Kafka utilize a \"leader and follower\" model. In Raft, a leader of the orderers is elected and determines the sequence of transactions. Then, it distributes the replications of ordered transactions to the followers. The distribution of the replicated transactions enables the Raft-based ordering service to provide crash fault tolerance. Raft selects one of the followers as a leader and runs it in cases where the previous leader crashes. The Kafka-based ordering service consists of orderers, Kafka brokers, and ZooKeeper. The Kafka brokers are categorized into a leader and followers. ZooKeeper manages the Kafka brokers by selecting a leader out of the brokers and monitoring that the Kafka brokers are working properly. The [PERSON] leader determines the sequence of transactions. Kafka brokers that are not selected as a leader become followers. The leader of the Kafka brokers transfers ordered transactions to orderers. The orderers (i.e., both [PERSON] and [PERSON]) generate new blocks using the received transactions when one of the three conditions is satisfied: (1) the number of transactions in the block reaches the threshold, (2) the block size attains the maximum value in bytes, or (3) certain time has passed since the first transaction of the new block was received. When the block generation is finished, the orderers deliver the blocks to all peers (both endorsing and committing) for validation (4).