# BloodChain: A Blood Donation Network Managed by Blockchain Technologies
## 5 Implementation
### Algorithms  
In the proposed system, we have several algorithms to operate the system. The proposed method in this paper uses Hyperledger Fabric to conduct transactions. BloodChain exploits JavaScript structure for the data structure and the blockchain network for the process structure since it is suitable for a private business environment. BloodChain consists of two main algorithms, including Algorithm 1 (to describe the mechanism to store volunteer blood samples) and Algorithm 2 (which summarizes delivering blood samples from the donation place to the medical center). ```
1:Input: Volunteer ID, name, age, date of birth, blood type, amount of blood unit
2:Output: data of Volunteer and their blood is stored into ledger
3:for unit of blood do
4: storing data of Volunteer and blood to ledger
5:endforAlgorithm 2 summarizes delivering blood samples from the donation place to the medical center; this process can be repeated based on the context. After storage, the blood samples will be transported to different medical facilities in the donation place. To this end, the shipper information will be stored in the ledger to determine which company transports the blood and how many units of blood have been transported, i.e., updates the metadata. The process's input is the data of the delivery unit, and the output of the algorithm is the data of delivery and the new medical center, which receives the blood from the volunteer. Its corresponding ID_Center further identifies each step. ```
1:Input: data of delivery unit
2:Output: data of delivery is stored to ledger, new medical center also updated
3:for delivery unit do
4:for blood samples do
5: storing ID of blood unit with correspondence ID of delivery unit
6:endfor
7:for blood samples do
8: update location of new medical center of blood samples
9:endfor
10:endfor
11:return Encrypted hash
```

**Algorithm 2** transportation of blood samples from donation places to medical center. Moreover, the authors provide the source code for the proof of concept and instruction of installation. Interested readers might refer to our GitHub repository : [[https://github.com/Masquerade0127/bloody-blockchain](https://github.com/Masquerade0127/bloody-blockchain)]([https://github.com/Masquerade0127/bloody-blockchain](https://github.com/Masquerade0127/bloody-blockchain)) (accessed on 1 December 2021). ## 6 Evaluation Scenarios

### Environment Setting

Our paradigm is deployed on the Hyperledger Fabric network maintained inside docker containers. The evaluated result is developed on a personal workstation equipped with 8 GB RAM and Intel Core i5 2.7 GHz x 4. To prove the effectiveness of BloodChain, we also define several experiments by exploiting the Hyperledger Caliper that is used to design the test scenarios and collect all the information regarding the BloodChain performance. ### First Scenario

In the first scenario, we measure the results of the requests sent to the create data function; with one worker being initialized in the network, the initial number of requests is 1000 per second. The number of requests is continuously sent to the system within 2 min and gradually increases to 10,000 requests per second. The measurement results are shown in Figure 4. We observe that the number of successfully executed requests is relatively high compared to the failed requests; most of the successful requests are above 12,000 requests per second, while the number of failed requests only ranges from 2-3 requests. Figure 4: The results of the create data functions. Figure 5 depicts the results and number of requests to query the data of blood records in the database. In this scenario, the number of workers increases to 10; each worker, in turn, sends 1000 requests to create 10,000 requests per second in the system. The system's data query results are still stable, in which the number of successful requests ranges from the lowest level of 37,204 to the highest 42,169 requests, while the number of failed data query requests is only from 0 to 1 request.