# Efficient and Secure Management of Medical Data Sharing Based on Blockchain Technology
## 5 Experiments
### Experimental Results and Analysis
#### 5.3.2 Data Provenance Experiments  
In this paper, we propose two different data provenance methods. To test the performance of the two provenance methods, we conducted experiments based on the five sets of data listed in Table 5. We first uploaded the medical and operational behaviors data to the blockchain through the platform interface, and then used the interfaces and testing tools to conduct performance testing.  
First, we tested the average provenance performance of the proposed method on the platform. In this experiment, we used the first set of data listed in Table 5, which includes 200,000 medical data and 76,853 operational behaviors data for testing. During the testing process, due to the low efficiency of the naive method's forward tracking and the absence of smart contracts in DAG-based methods, caliper tools cannot be used for testing. Therefore, we used Jmeter tool for performance testing. We used time cost, transfer rate, time per request, and throughput metrics to measure performance. In the naive method's forward tracking test, we only sent 1000 requests, while the rest were sent with 100,000 requests and the number of concurrent requests was set to 10. The experimental results are shown in Table 6.  
From the experimental results in Table 6, we can see that the TPS of the DAG-based method is far superior to the naive method, especially in the naive method where the TPS of forward tracking is only 0.54, which cannot meet the performance requirements of data provenance. In the naive-forward method, the TPS of backward tracing is approximately 718 times that of forward tracking, which is due to the fact that each time forward tracking is executed, it takes a significant amount of time to obtain all operational behaviors data, while backward tracing does not take a lot of time. The TPS of the DAG-based method is approximately 26 times that of naive-backward because in naive-backward, each query needs to query the blockchain ledger, while the DAG-based method only needs to perform breadth-first search on a pre-constructed DAG to obtain all paths. Considering the low TPS of naive-forward, we did not test it in subsequent experiments.  
\begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Method** & **Succ** & **Fail** & **Time Cost (s)** & **Time per Request (ms)** & **Throughput** \\ \hline naive-forward & 1000 & 0 & 1837.85 & 1837.85 & 0.54 \\ naive-backward & 100,000 & 0 & 258.02 & 2.58 & 387.56 \\ DAG-forward & 100,000 & 0 & 9.80 & 0.098 & 10,204.08 \\ DAG-backward & 100,000 & 0 & 9.72 & 0.097 & 10,288.06 \\ \hline \hline \end{tabular}
\end{table}
Table 6: Experimental results of data provenance.  
Figure 8: Throughput changes with the number of organizations.  
In the next experiment, we tested the impact of data scale and path length on the TPS of the naive-backward, DAG-forward, and DAG-backward methods. We uploaded the data of different sizes in Table 5 to the blockchain and then conducted throughput tests based on path lengths of 1, 2, 3, 4, 5, 6, and \(\geq\)7. The test results are shown in Table 7.  
From Table 7, we can find that as the path length increases, the TPS values of all methods show a downward trend. The TPS of naive-backward method at path 1 is about 10 times that at paths with length \(\geq\) 7, and the TPS of DAG-forward and DAG-backward are about 20 times, indicating that the TPS of tracing is greatly affected by path length. Under different data scales, the TPS of all methods at the same path length are relatively close, indicating that the TPS of tracing is less affected by data scale. We speculate that this is because both data on blockchain and in DAG are stored in the form of key-values, and changing the data scale has little impact on the speed of data reading. The TPS values of DAG-forward and DAG-backward methods are very close under different data scales and path lengths. In theory, the TPS values of DAG-forward and DAG-backward should be the same, but due to the impact of network environment, the TPS values fluctuated.