## 4 Case Study Implementation Using Hyperledger Fabric
When the client authenticates to the REST Server, the explorer redirects the request to the Github authentication provider. Afterward, the authentication provider redirects back to the REST Server and shows the access token at the top of the page. The access token can be passed into the REST request to authenticate the client. Figure 14: Composer web playground main interface. Figure 15: Composer REST Server explorer main interface. Once a client has authenticated to the REST API, that client can add identities to a wallet. The wallet is private to that client and is not accessible to other clients. When a client requests the REST Server, an identity in the client's wallet is used to sign all transactions made by that client digitally. To add an identity card to the wallet, we should navigate to the wallet APIs by expanding the wallet category, as shown in Figure 16a. The identity card can be imported into the wallet by calling the POST /wallet/import operation, as shown in Figure 16b. We can check that the participant does connect to the business network by calling the following API. As shown in Figure 17, the current participant is connected to the business network as it returns the information of the participant and related identity in the response body. Figure 16: Snapshot of the wallet API. (**a**) Wallet API specifications; (**b**) add a business network card to the wallet. Figure 17: Transaction test in the Composer REST Server. The snapshots in Figure 18 show some of the case study operations results. Figure 18a is a snapshot of the provider profile that is defined in the smart contract. Similarly, the consumer profile is presented in Figure 18b. The specifications of the SLA generated by the provider is illustrated in Figure 18c. Figure 9.0 Snapshot of the case study operation results. (**a**) Provider profile; (**b**) consumer profile; (**c**) SLA specification. Figure 19 represents the snapshot of the transaction history in the Composer playground, including the date, entry type, and participant. \"Date\" is an unalterable blockchain ledger record time indicating when the transaction is executed. \"Entry Type\" presents the transaction type and \"Participant\" represents the current participant that submits the transaction. The dashboard also provides an entry that shows the detail of a transaction. ## 6 Performance Evaluation of the Case Study

This section offers a comprehensive evaluation to demonstrate the performance of the proposed system in various performance metrics, along with a formula where appropriate. The prototype blockchain network in the experiment consists of four peers and one orderer. The term transactions per second (tps) refers to the number of transactions performed by the blockchain network per second, also called throughput. For this analysis, we used the Hyperledger Caliper [46] as the benchmark simulation tool. We modified the configuration script to simulate the behavior of the case study for the performance evaluation. For the first study, we evaluated the throughput of the proposed system by varying the send rate from 200 tps to 1300 tps. The throughput can be classified into two categories, the read throughput and transaction throughput. The read throughput measures the number of read operations that are completed in a defined period. The transaction throughput measures the number of valid transactions that are committed by the blockchain within the allotted time. Formulas for these two metrics are presented in Equations (1) and (2), respectively. Note that the total number of invalid transactions should be eliminated from the total transactions to yield the total valid transactions. The average read throughput of the proposed system was evaluated by varying the send rate from 500 tps to 3000 tps at a randomly selected system utilization level, and the experimental results are shown in Figure 9.1 The read throughput grows until it reaches a peak of 2346 tps at the send rate of 2500 tps.