# An Efficient Blockchain Transaction Retrieval System
## 3 System Implementation
### Retrieval Structure Generation and Analysis
#### 3.3.2 Performance Optimization Analysis of BB+ Tree
The first experiment part analyzes the time and space consumption of the BB+ tree proposed in this paper. The content of the investigation is the construction time and the amount of space occupied by the retrieval structure based on the BB+ tree under different block sizes. The second part analyzes the retrieval efficiency of the BB+ tree single feature in different scenarios and the retrieval efficiency of mixed multi-feature retrieval. ### Time and Space Consumption for BB+ Tree

The experiment mainly evaluates the time and space consumption of the BB+ tree in different block sizes. Firstly, the blockchain retrieval system extracts the account address and block hash in the Bitcoin data provided by xblock and inserts the key-value pairs to BB+ tree and BRBR. Then, we analyze the comparison results of the establishment time and the retrieval file size when the block sizes are 1000, 3000, and 5000. As can be seen from Figure 10a, we obtain the comparison results including BRBR, BB+ tree (N = 2), BB+ tree (N = 4), and BB+ tree (N = 6) to establish the retrieval structure in different block sizes. When the block sizes are 1000, 3000, and 5000, the time consumption of BRBR is 11.82, 40.26, and 71.52 s, respectively. The time consumption of the BB+ tree (N = 2) is 11.55, 37.02, and 60.74 s. We can see that the time consumption results of BB+ are better than BRBR in different situations. This is because the BB+ tree reduces the retrieval space of each subB+ tree by splitting the retrieval space so that it can be faster when inserting, updating, and deleting the retrieval items. When the Bloom filter's bits number N is different, the retrieval structure establishment's time is also different. When the block size is small, the performance of the BB+ tree is not outstanding after introducing the Bloom filter. However, as the block size increases, its advantages gradually manifest. As can be seen from Figure 10a, the larger the N in the BB+ tree, the shorter the establishment time of the retrieval structure. The reason is that the number of bits N of the Bloom filter increases so that the search items can be maintained in more subB+ trees. The subB+ tree has fewer items, which makes inserting, updating, and other maintenance efficient. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**BlockID** & **BlockHash** & **Btime** & **Txs** \\ \hline
327872 & 000000000000001 BECC903 BF44978 DEDEDE7C0429B0 & 1414771239 & 288 \\ \hline
327873 & 00000000000000008F1C9 DC87C18D50D6 AAC82923 & 1414771715 & 256 \\ \hline
327874 & 0000000000000001A80 CF302D79 ED1322 AFB14 Fsq1 & 1414771623 & 176 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Block data. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Transaction Hash** & **Sender Address** & **Receiver Address** & **Time** \\ \hline
18755B2319 DA1E1A & 11111111111111111111 & 11114 bV279 cgCnj & \\
7F4432 AF8C50D881 & 1111B2 bvirl2 xc & 8 EffSHZtvp66 at9 yv & 1414771239 \\ \hline
9 ADE39C5D8 CB3 ED1 & 11111p3u5w5w3s2 DM & 1114 UGwDgKvF5 dT & \\ B91D702 FF57A0 FD9w & P3 LMRhoqcmVFte & eBzHBN6 iN5B5a01 JB & 1414771239 \\ \hline
12 AD0808D7 ECA878 & 11117 APqhd39 TNQL & 111 dTWEm8 zcGJNT & \\ CCTFBAAFAB9B2F5B2 & PVQnStLBXo3 vA8 Kcb & M5 XBPLKjfyRqxLWAv & 1414771239 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Transaction data in block 327872. As can be seen from Figure 10b, we obtain the space consumption comparison results of BRBR, BB+ tree (N = 2), BB+ tree (N = 4), and BB+ tree (N = 6) under the block sizes of 1000, 3000, and 5000, and the space consumption of BRBR is 78.15, 235.01 and 380.88 KB. The space consumption of the BB+ tree (N = 2) is 78.82, 242.59, and 404.76 KB. It can be seen that in terms of space consumption, BRBR is slightly better than BB+. The reason is that the BB+ tree introduces the Bloom filter, which will cause extra bitmap and other space occupation compared to BRBR.