## 5 Experimental Results and Discussion
### Comparison with Competing Approaches
\begin{table}
\begin{tabular}{l c c c c c} \hline \hline
**Input** & **This** & **Query** & **Index** & **Full Indexing** & **Dual Scenario** \\  & **Study** & **Index** & **Everything** & **Full Indexing** \\ \hline deploy & 823,933 & 903,780 & 707,460 & 896,850 & 791,741 \\ \hline case1 & 160,706 & 345,226 & 79,394 & 238,526 & 339,863 \\ \hline case2 & 146,526 & 453,249 & 84,818 & 333,549 & 339,902 \\ \hline case3 & 146,490 & 401,949 & 50,618 & 238,646 & 339,902 \\ \hline case4 & 129,354 & 384,786 & 50,582 & 204,374 & 339,863 \\ \hline mean & 145,769 & 383,478 & 66,353 & 253,774 & 339,883 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison between our smart contract and competing solutions in terms of the gas consumed for the write operation. Figure 10: Comparison of gas consumption for different studies. existing entries are updated, which is why the gas consumption is the smallest among the four cases. The gas consumption for the index everything solution is much smaller than that for our solution. This is because the index everything solution is customized for the dataset used in the secure gene analysis competition where the gene names, variants, and drug names are encoded as 8-bit integers, and the gene-variant-drug combination is encoded as 24-bit integers. Five mappings are used to map each gene-variant-drug to the number of presence of each outcome/relation/side effect (using a 32-bit integer). As such, the mappings take little space. In all cases, the key of the mapping takes one 32-byte word, and the value of the mapping takes another 32-byte word. We note that while this solution works well for the secure gene analysis competition, it is not a good fit for general purpose data storage. The gas consumption for the full indexing solution is between 50% to 100% higher than that for our solution. This is due to the use of three mappings compared to a single mapping in ours. In case1, one new entry is created for each of the three mappings. In case2, one new entry is also created for each of the three mappings. The reason why the gas consumption for case2 is higher is because the gene name and the drug name are longer than those in case1. In case3, a new entry is created in the variant mapping and one entry from each of the gene and drug mappings is updated, and the same is true for case4. Updating an existing entry in a mapping costs less than creating a new entry. The gas consumption for the dual-scenario indexing is consistently high in all four cases due to the use of a large structure to store the observation (i.e., GeneDrugRelation). This solution uses two mappings. One mapping (GeneDrugRelationKeyMapping) is created and populated prior to any query can be accepted. The GeneDrugRelationKeyMapping maps all possible gene-variant-drug combinations with one or more wildcards to the list of full gene-variant-drug (without any wildcard) combinations. The other mapping (called geneData) is used to map full gene-variant-drug to the GeneDrugRelation record. The write function only updates the geneData. Hence, the reported gas consumption in Table 1 does not include the cost for populating the GeneDrugRelationKeyMapping. Due to the way the data are stored (i.e., using a struct instead of a string), this solution is not extensible for general purpose data storage.