# MedChain: Efficient Healthcare Data Sharing via Blockchain
## 5 Evaluations
### Efficiency Analysis
#### 5.2.3 Performance Analysis through Experiments
Existing schemes store everything into blockchain, including the description of data, the description of sessions, and the actual data locations. On the other hand, the blockchain in MedChain only contains the fingerprints for the purpose of non-repudiation and integrity check. Other information is stored on the directory servers, which are mutable. The mutable part of session descriptions are only needed by the end of data sharing such as the URLs and the references (i.e., _BH_ and _EH_) to the blocks and events in the blockchain. These data can be removed from the directory servers when the session is revoked, while blockchain does not support the removal operation for tamper-proof purpose. Figure 10 shows the comparison of MedChain with existing schemes in storage overhead. The experiment is run in two settings, different number of data (Figure 10a, 10 sessions), and different number of sessions (Figure 10b, 10 medical records). In the first setting, each run includes the procedure of data generation, session creation, and session removal, which can simulate the scenario of sharing different data. In the second setting, data generation events (i.e., _Event\({}_{DG}\)_) are only created in the first run, simulating the scenario of sharing the same set of data to different requesters. In both settings, MedChain has less storage overhead than existing schemes  
Figure 8: Communication overhead in sharing data stream through record-based and stream-based digest generation, measured in (**a**) responsiveness and (**b**) bandwidth. because the mutability part of a session is removed when the sharing is over. Even if the session removal (SR) is not reported to the blockchain, existing approaches still consume more storage spaces. In the last experiment, the scalability of MedChain is studied. The system latency is mainly generated by the directory service, since the number of communication steps in a BFT-based consensus is fixed in a normal case [39]. Thus, only the number of directory nodes is increased to test the system scalability. Figure 11 shows the test result. It can be found that the trend of the system responsiveness increase along with the number of directory nodes, which is sub-linear. The result shows the high scalability of MedChain due to the underlying DHT network. The variation (indicated by the error bar in Figure 11) also grows with the number of the directory nodes because the indeterminism of the hop number in a P2P routing also increases. Figure 10: Study the communication overhead of MedChain by comparing the mutable information storage on blockchain with the storage on the directory in (**a**) different numbers of data generated per session and (**b**) different numbers of sessions with 10 medical records to share per session. Figure 9: Communication overhead in sharing both data stream and records through record-based and stream-based digest generation, measured in (**a**) responsiveness and (**b**) bandwidth. Communication overhead of MedChain in different fraction of data stream to record, measured in (**c**) responsiveness and (**d**) bandwidth. The scalability in terms of the transaction rate and the number of nodes is also tested. Different types of nodes are separately scaled since blockchain servers and directory servers are connected to different network topologies and they scale for different purposes. For the blockchain service, as it is implemented by the BFT-SMaRt [39] protocol, the number of blockchain nodes (\(N_{1}\)) is determined by the extent of fault-tolerance: \(N_{1}=3f+1\) where \(f\) represents the maximal number of faulty nodes. For the directory service, the number of directory nodes (\(N_{2}\)) scales to increase storage space. Thus, in the experiment, \(N_{1}=4\) (\(f=1\)), \(7\) (\(f=2\)), and \(10\) (\(f=3\)), while \(N_{2}=10\), \(20\),..., \(100\), which is consistent with the last experiment. Figure 12 shows the experimental result.