## 5 Experimental Results and Discussion
### Comparison with Competing Approaches  
To compare with existing smart contract solutions for secure data storage as reported in [36; 37], we intentionally removed user access control from our smart contract so that the comparison would be fair because the smart contracts introduced in [36; 37] have no user access control. Removing user access control eliminates possible complexity introduced by user access control during the data storage and query operations. In the comparison, we use four observations from the secure genome analysis competition dataset as the inputs for the tests. The input consists of six components: gene name, variant, drug name, outcome (improved, unchanged, or deteriorated), possible relation (yes or no), side effect (yes or no):  
* case1: (\"HLA-B\", \"57\", \"abacavir\", \"improved\", yes, no);
* case2: (\"CYP3A5\", \"52\", \"pegloticase\", \"unchanged\", yes, yes);
* case3: \"CYP3A5\", \"53\", \"pegloticase\", \"unchanged\", yes, yes);
* case4: \"CYP3A5\", \"53\", \"abacavir\", \"unchanged\", yes, yes). We compare our solution with the four smart contract solutions designed for secure gene analysis, in the order of the ranking from the first place winner to the honorable mention during the 2019 competition [36; 37]: query index [36], index everything [36], full index [37], and dual-scenario indexing [36] for the four cases. The results are summarized in Table 1. The mean gas consumption for different studies is illustrated in Figure 10.  
Prior to testing the gas consumption of the write operation, the smart contract for the respective solutions is first deployed. The deployment cost of the smart contract is shown in the first data row of Table 1. While the deployment cost is high in all solutions, they differ very little. We note that the four cases are used as the input to the write function of the smart contract in order (i.e., case1 is followed by case2, case3, and case4), and the order matters for the competing solutions as explained below. In our smart contract, the write functions take two arguments--a tag and the data entry, both in the string format. For the four cases, we concatenate the first three components in the form of \"c1/c2/c3\" as the tag and concatenate all six components in the form of \"c1/c2/c3/c4/c5/c6\" as the data entry. As the first three parameters' (gene-variant-drug) combinations are all different in the four cases, the tags are all different, which means that in each case, the mapping would create a new entry and the gas consumption would be determined by the tag and data entry length. It is not surprising that the gas consumption for the query index solution is much higher than ours (more than twice of ours). Although the query index solution also uses a single mapping and a single string array to store the data, multiple entries are created in the mapping in each of the cases. In our solution, only a single entry is created in the mapping. More specifically, in case1, the query index solution creates a total of eight entries in the mapping when storing the observation (one entry with a unique gene-variant-drug combination and seven entries with one or more wildcards). In case2, the query index creates a total of seven entries in the mapping because the case of \"**/**\" has already been created during case1 and this existing entry is updated. The higher gas consumption for case2 is due to the longer drug name and longer outcome strings. In case3, five entries are added into the mapping due to the variant change between case2 and case3 and three existing entries are updated. As a result, the gas consumption is about 50,000 gas less in case3 than in case2. In case4, only a single entry is created in the mapping and seven