# An Efficient Blockchain Transaction Retrieval System
## 3 System Implementation
### Retrieval Structure Generation and Analysis
#### 3.3.2 Performance Optimization Analysis of BB+ Tree
#### 4.2.2 Concurrent Retrieval Performance

This experiment mainly focuses on the performance of the retrieval structure in different concurrent retrieval scales. 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 conduct the blockchain concurrent retrieval experiments. The retrieval target is shown in Table 5. The retrieval structure contains the target, and the number of target key-value pairs is fixed. We select the block sizes of 500, 1500, 3000, and 5000, and the number of concurrent retrievals is 2, 4, 6, 8, 10, and 20. Finally, we analyze the comparison results of the retrieval time increase. We introduce a comparison parameter \(B_{i}\)[22], where \(i\) is the number of retrieval participants in concurrent retrieval and \(t_{2}\) is the retrieval time when the number of retrieval participants is 2. This parameter is used to compare the performance changes of different retrieval structures when the size of the retrieval requests increases:

\[B_{i}=\frac{t_{i}}{t_{2}}(i=4,6,8,10,20) \tag{12}\]

Figure 11: Query response time in different block sizes. \begin{table}
\begin{tabular}{c c c} \hline \hline
**Type** & **Description** & **Example** \\ \hline Concurrent retrieval & Account address retrieval & address = “111113 cvaEeMfzNNASCkn49 qddBTdX1y4” \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Concurrent retrieval example. As is shown in Figure 12, the abscissa is the retrieval requests number, and the ordinate is the comparison parameter \(B_{i}\). When the number of blocks is 500, the retrieval time of BRBR is longer than BB+. As the number of concurrent retrievals increases, the increase in \(B_{i}\) is relatively tiny. It shows that BB+ tree has a shorter retrieval time in a small-scale block retrieval scenario, and has weaker stability than that of BRBR in the face of the increase in the number of concurrent retrievals. As the block size increases, especially in blocks of 1500 and 3000, the BB+ tree has good performance. Compared with BRBR, the retrieval time is less, and the increase in the BB+ \(B_{i}\) is also more minor. With the rise in the number of concurrent searches, the retrieval performance of the BB+ tree-based retrieval structure is excellent and stable. When the number of blocks is 5000, we can see that the two are close to each other in terms of stability, but the overall retrieval time based on BB+ tree is better. Overall, including different concurrent retrieval scales and block sizes, it is similar to the situation in the first experiment. First, in terms of retrieval time, BB+ (N = 4) and BB+ (N = 6) have identical performance and stability, indicating that the increase in Bloom filters does not bring more significant performance improvement to BB+ tree. In some cases with block sizes of 500, 1500, and 3000, BB+ (N = 4) is even better than BB+ (N = 6). The main reason is that the addition of the Bloom filter increases the computational complexity of the retrieval algorithm. There is a balance between the increase in the Bloom filter's bit array and the reduction in the retrieval time. #### 4.2.3 Multi-Feature Retrieval

This experiment mainly considers that the retrieval system introduces time retrieval parameters and evaluates performance in multiple features retrieval. Firstly, the blockchain retrieval system extracts the account address and time in the Bitcoin data provided by xblock. It inserts the account retrieval item to the BB+ tree and BRBR. It inserts the time retrieval item to the I2B+ tree. Then we conduct the blockchain multi-feature retrieval experiments. The retrieval target is shown in Table 6. The retrieval structure contains the target, and the number of targets is fixed. Random retrieval experiments are conducted 30 times under the scale of 1500 blocks.