# Blockchain-Assisted Verifiable and Multi-User Fuzzy Search Encryption Scheme
## 7 Efficiency Analysis
### Experimental Performance  
In this section, simulation experiments are conducted. The performance of the scheme is evaluated using Java language in the Windows 10 Home Chinese version. The hardware system is a 64-bit Windows operating system Intel(R) Core (TM) i7-8750H CPU @2.20 GHz with 16 GB of RAM and the experimental dataset is RFC (Request For Comments). Smart contracts are deployed through the solidity language, running in an Ethereum virtual machine. The blockchain implementation is based on the official Ethereum test network Rinkeby and the Ethereum wallet MetaMask is used to function as an account. The numbers of LSH are chosen as k = 30, the constructed index and trapdoor vector is l = 8000, the file is encrypted by AES-256, and the number of keywords in a file is 80-113.  
The scheme excludes keywords with little semantic distinction such as the, where, and a. Simulation experiments and comparisons of our scheme with scheme [15], scheme [28], and scheme [29] are conducted in terms of file index generation, search matching time, and search accuracy.  
* **Individual File Index Generation and Encryption.** In Figure 5a, the cost of generating a plaintext index vector for a single file index is gradually increasing with the number of file keywords. Meanwhile, the encryption time of the plaintext index vector is constant, which fluctuates slightly at 40 ms.  
Figure 5: **(a)** Index generation time. **(b)** The search matching time when search keyword number is 3. **(c)** The search matching time when the file number is 2000. **(d)** The fuzzy search accuracy. [PERSON], [PERSON] et al (2020) refers to the scheme in ref. [15], [PERSON] et al (2022) refers to the scheme in ref. [21], [PERSON] et al (2022) refers to the scheme in ref. [28] and [PERSON], [PERSON] et al (2021) refers to the scheme in ref. [29].  
* **Search Match.** In Figure 5b, as the number of files gradually increases, all 4 schemes basically show an increasing trend. When the number of files is no more than 1000, all the schemes increase at a relatively small level. The time cost and growth rate required for searching in the proposed scheme are lower than those of the schemes in [25; 29], and as the number of files increases, the scheme follows up with a slight increase compared to the beginning. Although the search time of the scheme in [21] also consistently increases at a lower level, the search time of our scheme is still superior to it. When the number of files is 2000, the search times of the schemes in [28; 29] are 7.42 s and 4.42 s, respectively, while the time cost of our scheme is only 2.21 s. In Figure 5c, the search matching costs of the schemes in [21; 28; 29] tend to stabilize, while the time cost in our scheme shows a small linear increase. When the number of search keywords is 9, the time costs of the scheme in [28; 29], and [21] are 7.42 s, 4.51 s, and 2.65 s, respectively, while the time cost of our scheme is only about 1.85 s.
* **Fuzzy Search Accuracy.** Since our scheme and the scheme in [15] have similarities in index construction which uses \(unigram\) to transform keywords, the scheme in [15] is chosen to compare fuzzy search accuracy. The fuzzy keywords are constructed by replacing one letter in the keyword with another letter randomly, and the check accuracy is used to test the search results. The accuracy test method \(\Delta P=p^{\prime}/p\) from the scheme in [32] is used in our scheme, where \(p\) indicates the number of search files returned and \(p^{\prime}\) indicates the number of real files returned.  
As seen in Figure 5d, the search accuracy increases gradually with the increase in the number of search keywords, which makes the scheme more capable of distinguishing the files that satisfy the user's search conditions. The search accuracy of the scheme in [15] is around 85%, while the search accuracy of our scheme can reach 91% with the increase in valid search keywords.