An Improved Retrieval Method for Multi-Transaction Mode Consortium Blockchain

: The traditional method of blockchain retrieval is to search the “Block File” in sequence from the "tail" to the "head" of the blockchain, which always takes a lot of time. How to reduce the retrieval time has been a hot issue in blockchain research. This paper proposes a fast retrieval method for the Multi-Transaction Mode Consortium Blockchain (MTMCB). Firstly, we create a “User Set” and “Block Name Set” cached in Redis. Then, according to the transaction participants and “Block Name Set”, we can get the relevant "Block Name List", and quickly obtain the corresponding block files. On this basis, in order to meet the needs of rapid retrieval in large-scale systems, an improved retrieval algorithm based on a B+-tree data structure is proposed. Firstly, the block file information is put into different ordered sets according to the transaction participants, and the B+-tree index is established to quickly get the information of relevant block files by participants. Experimental results show that the improved method of Redis cache retrieval in this paper can greatly increase the efficiency of blockchain retrieval, and can settle some crucial problem in the blockchain application and popularization.


Introduction
The consortium blockchain is one of the three forms of blockchain, which is characterized by a weak centralized network. It has been widely used in many fields, such as asset, credit, time proof of key events, existence proof, and trading market [1][2][3]. The Multi-Transaction Mode Consortium Blockchain [4] was developed on the basis of retaining some original characteristics of the blockchain, realizing transaction type diversification, virtual nodes, and block cloud storage, allowing attached transaction data, etc., which makes the application of blockchain technology more flexible.
In the blockchain that supports "Bitcoin" transactions, the retrieval algorithm uses sequential searches from the "tail" to the "head" of the blockchain. When the number of blocks reaches a certain size, it takes a long time to retrieve an early block (close to the chain head). Block retrieval is the basis of blockchain-related services, and the existing sequential retrieval methods are inefficient, which seriously affects the performance of its application business system.
In recent years, researchers have proposed some techniques to improve the performance of blockchain retrieval. Google [5] has added Bitcoin, Ethereum blockchain data, and Ethereum classic ETC network plug-ins to BigQuery, and has employed artificial intelligence to make the blockchain searchable. Wang [6] proposed to establish a simple database index directory for medical records in medical blockchain applications, including the hash value information of the relevant blocks of the department and patient medical records. Ren [7] proposed a method, DCOMB (dual combination Bloom filter), combining the data stream of the IoT (Internet of Things) with the timestamp of the blockchain, to improve the versatility of the IoT database system. Shibata [8] proposed a retrieval scheme, where a client provides a computer program called a searcher that implements a randomized search algorithm such as a genetic algorithm. Lv [9] proposed a retrieval model based on the combination of chain and chain: the method builds an inverted index for the log data, and expands the block chain header node to store the inverted index in it. The subsequent log retrieval achieves the purpose of rapid positioning by sequential retrieval of the inverted index. Zhou [10] proposed a ledger data query platform called Ledgerdata Refiner. With ledger data analysis middleware, the platform provides sufficient interfaces for users to retrieve block or transaction efficiently. Do [11] proposed a private keyword search component designed for searching in the encrypted dataset. However, these studies generally either complicate the hierarchical structure of the blockchain itself by introducing third-party support, or the search performance improvement effect is limited.
Many experts have put forward patent applications for invention in the field of blockchain retrieval since 2015. The method for distributing and retrieving data on a blockchain network with peer nodes developed in [12] forms a blockchain network by forming peers, sharing and distributing private files, and sending messages to complete the request and private retrieval. The search method and system for business information of blockchain given in [13] improves the retrieval efficiency of blockchain business information by establishing a business-related index database through the unified use of personnel names, and does not need to rearrange the block content. The personalized privacy information retrieval method based on the blockchain as discussed in [14], encrypts the data through the encryption algorithm of the buyer and seller on the data trading platform, and decrypts the ciphertext with their own public key encryption algorithm to obtain the retrieval results and achieve content retrieval and intention privacy protection. These studies need to use relational databases or encryption algorithms, and database maintenance needs to monitor the block modification repeatedly. Although the efficiency has been improved, the block file still cannot meet the real-time requirements of the business system when it is large, and needs large system consumption.
In this paper, a fast blockchain retrieval method for the Multi-Transaction Mode Consortium Blockchain is proposed, which mainly includes the following: 1. A "Block Name File" is defined, which establishes an "index mechanism" with user files and block files, so as to improve the retrieval efficiency without affecting the security of user information. 2. According to the problem that the retrieval efficiency will decline with the increase of "Block Name File", combined with the excellent read-write performance of the Redis memory database, a fast retrieval method of "block name collection" under Redis cache is proposed. 3. In order to mitigate the problem that the retrieval efficiency of the "Block Name Set" will decline under the large block size and large user scale, a new "User Block Set" is designed to replace "Block Name Set" to participate in the retrieval, and a B+-tree index is introduced to improve the retrieval process.
Our experiments show that the algorithms proposed in this paper can significantly improve the retrieval efficiency, and the improved algorithm improves the retrieval efficiency even further and has better stability.

Multi-Transaction Mode Consortium Blockchain (MTMCB)
Multi-Transaction Mode Consortium Blockchain (MTMCB) inherits several features from the existing Blockchain technologies, such as relative decentralization, distributed storage, point-to-point communication, and secure encryption. On this basis, MTMCB generalizes "electronic currency transaction" in blockchain technology into "process and result of event processing", and redesigns "transaction verification mechanism" and "block distribution storage mechanism". As shown in Figure 1, MTMCB includes the Regulatory Node System (RNS) and the Transaction Node System (TNS). The RNS is deployed on the server, performing initialization, transaction processing, and audit services. The initialization operation only needs to be performed once. Transaction nodes can be PCs, mobile devices, or even automatic teller machines (ATMs), etc.  After authorization, different user types write their initialization information into the "User File". For example, the storage structure is shown in Figure 2.  In the MTMCB, the Regulatory Node is responsible for managing the "User File", which is used to record the correspondence between the user name and its address, where "Address" is 10 characters and records the user's transaction address. In the subsequent transaction records and retrieval process of the user, only the "Address" of the transaction participant is used instead of the "User Name", which effectively protects the privacy of the transaction participant.
The block includes a block header and a block body, as shown in Figure 3. The block body includes the transaction information and its SHA256 [15] value.  The first block in the blockchain is the genesis block. Its block number is distinguished by a specific hash value. Each block (except the genesis block) stores the hash value of the previous block. In this way, the blockchain is formed between the blocks, and the information of the chain tail block is stored and updated by the chain tail file (system file, which is used to store the file name of the chain tail block of the blockchain and the hash value of the bank). Using the hash value of the previous block, we can retrieve from "tail" to "head".

Redis Cache Technology
For the retrieval of block files stored on disk, a corresponding index needs to be established in memory to reduce the number of disk reads and writes and speed up the retrieval speed. Currently, Redis cache technology is usually used to achieve fast indexing of block files. Redis [16,17] is a highperformance memory-based Key-Value database, which mainly solves the problem of timeliness of data processing in the case of high concurrency in relational databases. Because of its pure in-memory operation, Redis has excellent read and write performance. Throughputs of more than 100,000 read and write operations per second have been recorded [18]. Redis provides rich data types, including linked lists (List), strings (String), sets (Set) and ordered sets (Zset). All Redis operations are atomic, and Redis also supports the atomic execution of several operations. It also supports the calculation of unions, intersections and complements of sets in the service front-end, and supports a variety of sorting. At the same time, it provides APIs for Java, python, ruby, PHP, Erlang and other clients, which is suitable for various implementation occasions. Additionally, Redis also provides publish /subscribe, notification, key expiration, and other features.
One of the most important application scenarios of Redis is as business cache, which is used to keep some hot data that are not frequently changed but frequently accessed in memory [19], effectively reducing the number of database reads, reducing database pressure, improving response time, and enhancing throughput. Redis also provides the compressed lists as a data structure to store a series of data and its encoding information in a continuous memory area. The purpose is to reduce unnecessary memory overhead as much as possible under certain controllable time and complex reading conditions. [20] is a high balance tree, which has the advantages of high self-balance, low update cost and high query efficiency. An m-order B+-tree is either an empty tree or satisfies the following characteristics [21]:

B+-Tree Index
• Each node in the tree has, at most, M subtrees.

•
If the root node is not a leaf node, there are at least two subtrees.

•
If the Non-terminal nodes is not the root, there are at least one subtree.

•
Non-leaf nodes with K subtrees contain exactly k−1 keywords.

•
The keywords of all nodes in the subtree indicated by the pointer Pi-1 are less than Ki.

•
The keywords of all nodes in the subtree indicated by Pn are greater than Kn. • All leaf nodes are in the same layer of the tree structure, and contain the actual information.
When querying the B+-tree [22] with the goal to find all records whose key is K, one first needs find the minimum key Ki greater than K in the root node and then follows the pointer Pi-1 on the left of Ki to the node of layer 2. If K is greater than all of the key words in the root node, then follow the pointer Pn to the node of layer 2. In layer 2, the same method is applied to find the pointer to the node in layer 3, and so on, until, finally, a record pointing to the data file is found in the leaf node.
As a kind of balanced multi-fork tree, the B+-tree only has leaf nodes to store data, and the inner nodes are only used for indexing. It has significant advantages in searching external data (that is, disk data). Due to the long seek time and rotation delay time of traditional disks when reading and writing, it is necessary to reduce the disk IO times as much as possible when searching. The best case is to find the target index quickly, and then read the data from the disk. Using B+-trees can achieve this and has become the main search optimization technology of the mainstream database.

Application of Redis in Block Retrieval Algorithm
From the structure of the blockchain, each block stores the hash value (block file name) of its previous block. The blockchain is connected by one block hash value, but this connection is unidirectional, and the previous block can only be found by the latter block, otherwise it is not possible. Therefore, the traditional retrieval method obtains the hash value of the end-of-chain block from the end-of-chain file, and then finds the previous block through this hash value, and so on. Its sequential search time complexity is O(N). As the blockchain system is put into use, new blocks will continuously be generated and added to the chain. As time goes by, the number of blocks will become, larger and larger. The efficiency of this sequential retrieval method will decline rapidly. In serious cases, it may cause long-term operation, affecting the performance of the system.
Based on the characteristics of the weakly centralized network in the MTMCB, we introduce a "Block Name Set" by using the MTMCB Regulatory Node System (RNS). An index between user files and blocks is established and held in a Redis cache, so as to achieve the purpose of fast block name search and fast block content location.

Definition and Construction of "Block Name Set"
The "Block Name File" is a specific format of the consortium blockchain system file, which is managed by the regulatory node. When the blockchain system is storing blocks, the block name of the block and the corresponding addresses of all transaction participants of the block are simultaneously stored in the "Block Name File". The logical structure of "Block Name File" storage is shown in Figure 4.
The SHA256 value of this record # Figure 4. The logical structure of "Block Name File".
Among them, • "Block name" is a 32 byte hexadecimal number representing the block name of a block; • ";" is the separator; • "User Address" is a hexadecimal number of 20 bytes, representing the address of the transaction participants of this block; • "The SHA256 value of this record" is a 32 byte hexadecimal number, which is used to verify whether the data in this record have been tampered with; • "#" is the end character, indicating the end of this record.
Considering the high retrieval frequency of the "Block Name File" and "User File", the read performance of disk storage cannot meet the demand of fast retrieval. When the system is started, the two files are read and parsed, and stored in the Redis cache database in the form of "Block Name Set" and "User Set".
Redis is a NoSQL database technology based on the memory key-value structure [23]. By building a Redis database cluster, data are cached in memory and master-slave replication is realized, so that the high-frequency accessed data can be read directly from memory, effectively reducing the corresponding time of data query. The traditional relational database maps the logical model to a series of tables. Redis needs to map the logical relationship to one or multiple key value pairs. Therefore, the choice of the key structure is important. A reasonable design can effectively improve the query efficiency and save memory overhead.
In this retrieval process, the "Block Name Set" and "User Set" information are cached and stored, and their logical structure is shown in Figure 5. The traditional blockchain system only stores the block information after consensus verification, and the blockchain storage extension processing is to store the block name of the block and the corresponding addresses of all transaction participants of the block into the "Block Name File" and cache while realizing the blockchain system's block storage. The specific methods are as follows: Step 1: When the block is stored, a block file will be generated, which records the contents of the current block. For convenience, the file is named after the hash value of the block.
Step 2: Obtain the block file name of the block file at the same time of the block storage, extract the "User address" of one or more participants in the current block, and write the "Block Name File" in the block name file storage structure.
Step 3: Record the SHA256 value of the new block name file record memory for anti-tamper requirements.
Step 4: Update the "Block Name Set" in the Redis cache.

Block Retrieval Algorithm through Redis Cache "Block Name Set"
When retrieving data, first use the "User Set" in the Redis cache to determine the address of the user (participant), and then search in the "Block Name Set" according to this address to obtain the name of the block to be retrieved. The specific methods are as follows: Step 1: Obtain the names of one or more participants to be retrieved. Search the user set to find the user address from the user name. The user name here must be information that can identify the unique user to prevent users with the same name from affecting the search results. The system uses an ID number as the user name.
Step 2: In the "Block Name Set", match the line by line by "User address" to find the block file name containing this user.
Step 3: Find the block from the block folder, parse the data and return it as query result.
The specific process is shown in Figure 6.  Through the above process, the block name file is searched in the Redis cache to obtain the file name list of all the blocks in which the queried user participates, and finally, the block files in the file name list are processed one-by-one in the disk file.
The differences between the application of Redis in block retrieval method and the traditional retrieval method are show in Figure 7.

Application of B+-Tree and Redis Cache in the Improved Block Retrieval Algorithm
The method of building the "Block Name Set" in the Redis cache can eliminate the inefficiency of traditional block chain search methods, which is from the end of the chain to the beginning of the chain one-by-one. However, as the system is put into operation for a longer and longer time, the number of users becomes larger and larger, resulting in a sharp increase in the number of transactions and blocks. According to Algorithm 1, each retrieval needs to traverse all the "Block Name Set". When the number of users participating in the transaction increases, the computational complexity will increase fast. To solve the above problems, this paper uses a B+-tree to reconstruct the user and block name storage structure in the Redis cache, and proposes an improved retrieval algorithm.

Improved Redis Cache Storage Model
The starting point of the retrieval method in the original MTMCB is "user name", and the search object is block files related to the "user name" of the transaction party. In order to achieve this function, the "User Name" substitute value "User Address" is used as the Key, and the combination of block file names is used as the Value that data type is "Set". The storage structure model is shown in Figure 8.

UserAddress BlockName；BlockName；……
Key Value User Block Set Figure 8. The Data storage structure of "user block collection" in Redis cache.
In order to be different from the "Block Name Set" in the original retrieval algorithm, this data file is named "User Block Set", which is used to store the block file name information of each user transaction and replace the "Block Name Set" in the Redis cache in the original retrieval algorithm. In this improved method, only "User Set" and "User Block Set" are stored in the Redis cache.
Although the reading of the Redis cache is relatively fast, the average time complexity of adding compressed lists is O(N). As N increases, the time consumption will also increase. Due to the large number of users participating in the transactions in the MTMCB, the number of users and files in the Redis cache is large, and the response time to retrieve multiple "User Addresses" still cannot meet the needs of the business system. In order to improve the retrieval efficiency, we use a B+-tree index to improve the retrieval efficiency of the "User Address". The logical structure of this metadata index is shown in Figure 9.

Initialization of Redis Cache Storage
1. When the system starts, read and analyze the "Block Name File", and initialize the "User Block Set" Redis database according to the "User address" and "Block Name" content in the block name file. 2. According to the Algorithm 2 in Listing 2, the B+-tree index of "User Block Set" is generated, and the corresponding relationship between the index and "User Block Set" is established. Set L and L2 link pointers; return newchildentry 3. Considering that the "User Set" also has many transaction users and low efficiency of sequential retrieval, another B+-tree index is established for "User Files" in a similar fashion, with the user name as keyword.

"User Block Set" Construction Algorithm
According to the storage expansion processing in the original MTMCB system, after the "Block Name File" is expanded, the block name information is stored in the "User Block Set" according to the transaction participant information.
The specific methods are as follows: Step 1: When the block is stored, a block file will be generated, which records the contents of the current block. For convenience, the file is named after the hash value of the block.
Step 2: There are one or more transaction participants in the event processing of the system Select one transaction participant and find the corresponding "User address" in the B+-tree index with the user name from the "User Set".
Step 3: Find the Key in the "user block file" according to the participant's address. If it exists, extend the value, write the block name to the end of the value, and sort by the time-stamp order. If it does not exist, add the key-value metadata. The key is the participant's address, the value is the new block file name, and update the B+-tree index.
Step 4: Repeat step 2 and step 3 to process the next transaction participant until all participants finish processing and complete this extension operation.
The above process is implemented by Algorithm 3. AppendUserfile(), as shown in Listing 3. else Add a new metadata for the "User Block Set", the "Key" value is UserAddress[i], and the "Value" value is BlockName

end for
Taking two user addresses "35f4ea7dc9ae3b9da2a390d91e5f3d67f89a4312" which is the existing user address and "3377487ea991e4cda1fdf5239da2a390995fb7c4" which is not existing as examples, the extension process is shown in Figure 10. If the user address exists, extend the "User Block Set", otherwise add a new metadata for the set.

Application of B+-Tree and Redis in Improved Block Retrieval algorithm
After the introduction of the "User Block Set", the block retrieval algorithm no longer relies on the "Block Name Set", but establishes an association relationship between the "User Set" and the "User Block Set". Assume that when the system needs to query all block files in which two users participate together. As long as the corresponding two addresses are found through the user file, and then the intersection of the set of block file names corresponding to the two addresses is found in the user block file, one can quickly get all the block files in which the users in question participate together. The retrieval process is shown in Figure 11.
The specific methods are as follows: Step 1: The retrieval method receives the names of one or more participants, and finds the "User address" from the "user name" by retrieving the "User Set".
Step 2: Find the Key where the "User Address" is located through the B+-tree index in the "User Block Set" and obtain all the block file name records of the user.
Step 3: Repeat step 2 until all relevant block file name records of the transaction participants are found.
Step 4: According to the block name file record set obtained in step 2 and step 3, a block file related to all participants is obtained, that is, the target file for this query.
Use the B+-tree to construct the fast location of participants and users and obtain the block file name based on the association between the "User Set" and the "User Block Set" in the Redis cache. Finally, read the "block file" on the disk for verification and processing, to locate the target block.
The above process is implemented by Algorithm 4 .RetrieveBlockFiles (), as shown in Listing 4. Taking participants "3401031976042323304" and "341203199702103187" as examples, the search process is shown in Figure 12. According to the block name set of the two, the intersection "blk04. dat" is the target block for storing the transactions of the two.  Figure 12. Example block retrieval diagram for "User Block Set".

Time Complexity Analysis of Retrieval Algorithm
In this paper, the search algorithm time consists of two parts: B+-tree search time and "User Block Set" intersection time.
In order to illustrate the search time of B+-tree, suppose that the search probability of any item in the tree is p, the total number of users in the consortium blockchain is M, the total number of block files is N, the order of B+-tree is d, the number of orders is t, the average space utilization is f, 0.5 ≤ f ≤ 1 (f = used storage space / maximum available storage space), and each user participates in m blocks on average, then the relationship shown in Table 1 can be obtained. Table 1. B+-tree series, number of Block files and space requirements.

The number of orders
The number of Nodes

Average number of users (subtree)
The number of block files Space requirement of the tree In the B+-tree of this paper, all users are in the leaf node, so the number of users M can be expressed as: Therefore, the number t of orders of the B+-tree can be expressed as: Similarly, the relationship between t and the total number of block files N can be obtained: For the intersection time of user block files in the Redis cache, since the user block names have been sorted (Ordered Set), it can be known from the ordered set algorithm [24] that the time complexity is O(m). Therefore, the time complexity of the improved retrieval algorithm in this paper is O( . Among them, m is the average number of blocks that each user participates in, and m is far less than N. In terms of spatial complexity, the traditional retrieval method is O(N). The improved retrieval algorithm in this paper mainly adds the index structure of the B+-tree. The spatial complexity of the internal nodes of B+ is O(N/fd), so the total spatial complexity is O(N+N/fd).
The traditional block retrieval directly reads data from the disk in the order of the blockchain, and the time for each read from the disk is assumed to be H. Based on the analysis above, we present the time complexity of three retrieval methods (traditional block retrieval, application of Redis in block retrieval, and application of B+-tree and Redis in improved block retrieval) in Table 2: In terms of space complexity, since the number of users N is less than the number of block files M, the space complexity of all three retrieval methods is O (M). In terms of time complexity, BR, RBR, BRBR three block retrievals are: O (H * M), O (N + M) and ( ( +1) + ). When N and M are large, the efficiency of the BRBR algorithm in this paper is more advantageous.

Privacy and Security Concerns Of Non-Regulatory Nodes
In terms of tamper-proof performance, the MTMCB has adopted two methods to ensure security: 1. Blockchain cloud storage transformation algorithm: The complete blockchain is stored in the local and corresponding cloud of the regulatory node, and the blockchain stored in the cloud is the transformation of the local blocks; 2. Distributed storage: The blocks generated by the same exchange will be distributed and stored in the cloud directory of all relevant participants in its transactions.
Among them, the privacy and security concerns of non regulatory nodes (transaction nodes) includes: 1. All transactions recorded in the block use "UserAddress" instead of "UserName", which well isolates the privacy of transaction participants; 2. The transaction node only stores the blocks related to the participant, not the complete blockchain, and the system adopts the "virtual node" mechanism. All the blocks of the transaction node are stored in the virtual node of the cloud corresponding to the node, which indirectly realizes the block security with the help of cloud security. 3. The structure of the block is transparent to the regulatory node. The regulatory node has a timing patrol mechanism, which can regularly verify the same block stored in several transaction related nodes (actually their cloud virtual nodes). Once any forgery or tampering is found, the block rebuilding mechanism is started to realize block synchronization.
In the next step, we plan to further improve the following technical methods so as to improve the security of transaction nodes, the whole system and blocks: (1) decentralized identity based on zero knowledge proofs; (2) secure multiparty computing for privacy enhanced; (3) Layer 2 solutions based on sidechains.

Experimental Environment and Data Preparation
In our experiment, we use a PC with Intel Core i5 Quad Core CPU, 500 GB HDD, and 8 GB memory. The operating system is Windows 8.1, the Redis version is 3.2.8, and the Java JDK version is 1.8.0_131. We use Jedis, the client implementation of the Java version of Redis, to implement operations such as retrieval queries on Redis.
Since the MTMCB system has not been put into practical use for the time being, this experiment ignores steps such as consensus verification, and successively generates 10, 100, 1000, 5000 pieces of data into the chain to realize the extended storage processing of the block while entering the chain.
The file information related to the method in this paper is shown in Figure 13. In this experiment, for the above simulation data and file content, the effects of the original sequential retrieval, the fast retrieval supported by block name file and the fast retrieval supported by Redis cache are compared. Figure 13. The schematic diagram of "Block Name File" extended by RNS.

Block Retrieval Performance Test and Analysis
In order to test the retrieval efficiency of the two proposed retrieval methods named RBR (Application of Redis in Block Retrieval) and BRBR (Application of B+-tree and Redis in Improved Block Retrieval), we choose the traditional block sequential retrieval method (BR) as a reference comparison, including the amount of data is equal in all scenarios, so we can directly compare the retrieval efficiency of the algorithms. In the experiment, the B+-tree is 8-order, and the transaction user is randomly selected from the user file.
As can be seen in Table 3, the time consumption of the three block retrieval algorithms depends on the number of users and the number of block files. We compare the retrieval time of various block retrieval files under different user scales and block file sizes.
For two transaction users and of 500-50,000 block files, the retrieval performance is evaluated. The experimental range of block number is initially 500. In view of the adaptability of the algorithm under the larger block scale, the range is enlarged to 1000 (block size > 4000) and 5000 (block size >10,000), as shown in Table 3. Considering that different numbers of user sizes will also have an impact on the retrieval efficiency, we now select block sizes 1500, 3000, 5000, and 10,000 and retrieval user sizes are from 2, 3, 4, 5, 6, 8, and 10 (randomly selected combinations from user files).
Since the RBR and BRBR algorithm already are very fast, in order to better compare the growth trend of the algorithm in retrieval time, the small absolute increases here turn into relative proportion. We compute and compare the metric as , where i is the number of users participating in the transaction, t2 is the retrieval time when the number of transaction users is 2, and Bi is the retrieval time when the number of transaction users = i. The results of data processing and comparison are shown in Table 4 and Figure 15.  As can be seen from Figure 15, the traditional retrieval BR algorithm is the least affected by the number of transaction users, and the RBR algorithm is the most affected. In different block numbers, when the number of users is less than 3, the three retrieval algorithms are not affected by the number of blocks. However, when the number of users is more than 3, the RBR method is affected significantly, which shows that the complexity of calculation will increase with the number of users in the RBR algorithm.

Stability Analysis of Block Retrieval
The stability of retrieval refers to the relatively consistent retrieval efficiency for the same type of retrieval requirements. We investigate the retrieval stability of three retrieval algorithms. We set the number of transaction users to 2 and the size of block file to 5000. We randomly generate 20 groups of transaction user combinations and respectively find the first block satisfying the conditions in the three retrieval algorithms, as shown in Table 5 and Figure 16.
information is composed into ordered sets according to the transaction participants. Then, the B+-tree index is established for the transaction participants. When searching, the B+-tree index allows us to quickly find the ordered set, including the participants and block name. At last, we can get the information of the relevant block file quickly efficiently by finding the intersection of several related ordered sets. We analyze the time requirements of the retrieval algorithms in a comprehensive experiment. The efficiency and stability of the improved algorithm are verified by experiments.
This solution is currently only applied to MTMCB and may not be applicable to other blockchain systems. In the future, we will study how to apply the ideas in this article to private blockchain systems.