Implementation method capable of verifying casual query scheme based on block chain database

Abstract

The invention discloses a method for realizing a verifiable oblivious query scheme based on a block chain database, a new block chain database query framework EVOchain is constructed, and compared with vchain, the query efficiency of sub-linear time complexity is realized. In the aspect of data result verification, integrity proof does not need to be carried out on a chain. In the aspects of data privacy and security, the method disclosed by the invention ensures very strong data privacy and security, the data is stored on the block chain in a ciphertext form, and the access mode and forward and backward privacy of the data are not exposed by query.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and in particular relates to a method for implementing a verifiable oblivious query scheme based on a blockchain database. Background Art

[0002] In data outsourcing scenarios, searchable encryption technology is a key technology that can ensure data privacy while providing data search on cloud servers. Song first proposed a searchable encryption (SE) scheme for static databases in 2000. Subsequently, Kamara proposed a dynamic searchable encryption (DSE) scheme that supports data updates. However, data updates have raised concerns about data and search privacy. From the perspective of attack results, security issues can be divided into forward privacy and backward privacy. Under the SHBC threat model, attackers may partially execute user queries and attempt to obtain search keywords. In addition, the correctness and completeness of search results cannot be guaranteed.

[0003] To solve these problems, Chai proposed a solution to implement Verifiable Searchable Encryption (VSE) by introducing a Trie-like Authenticated Data Structure (ADS). Each node of the tree represents a keyword and its inverted index. When returning the results, the cloud service provider (CSP) must also attach the corresponding proof generated by the ADS, and the data owner (DO) determines the correctness of the results by verifying the proof. Since the source of verifiability is the set membership proof of ADS, future VSE solutions will focus on the design of ADS. Different ADSs have their own advantages and disadvantages: the tree structure has advantages in providing membership proof and is easy to verify, but it is more difficult to provide non-membership proof, and a large number of proofs need to be modified when users update data.

[0004] To address these issues, Ogata built a VSE scheme based on the Cuckoo Hash Table, which is more efficient in providing various proofs. Some studies have also adopted hash table-based ADS. However, hash tables bring high storage costs. Sardar proposed a dynamic interval accumulator (DIA) tree, which enables the VSE scheme to have forward privacy and support keyword search, but still requires modifying a large number of proofs during the data update phase. In addition, most existing schemes are built under the less used SHBC threat model.

[0005] Some research has also explored verifiable search in distributed environments. Blockchain, as a distributed storage medium, provides verifiable query protocols. The Simplified Payment Verification (SPV) protocol can use Merkle proofs to verify that a transaction has been accepted by the blockchain network. However, as the blockchain scales, its verification and storage costs increase linearly. To ensure the integrity of query results, several verifiable query schemes have been studied in blockchain systems. Xu et al. proposed an accumulator-based authenticated data structure (ADS) and implemented a verifiable query framework called vChain. This framework alleviates the storage and computational costs of light clients. However, the size of the accumulator's public key is linearly proportional to the size of the maximum multiset, and the large amount of proof data results in high communication overhead for light clients. Shao et al. implemented an authenticated range query scheme for blockchains using a trusted execution environment (TEE), but did not discuss potential side-channel attacks against TEEs.

[0006] Zhu et al. proposed a verifiable aggregate query scheme based on accumulators that supports multi-select predicates. However, it uses the same accumulator as vChain and fails to address the linear overhead issue. Furthermore, the ADS construction cost is high because different ADSs are required for different query dimensions.

[0007] Zhang et al. proposed a gas-saving solution for hybrid storage blockchains using the MB-tree structure and cryptographic accumulators. However, this solution still requires high index maintenance costs and a complex query process. LineageChain utilizes a novel skip list index to achieve efficient provenance query processing and stores provenance information in a Merkle tree. Therefore, LineageChain can only guarantee the correctness of query results, not their completeness.

[0008] Most existing verifiable searchable encryption methods for centralized cloud servers are built under the less-used SHBC threat model and fail to account for distributed scenarios. Verifiable search schemes in blockchain scenarios either experience linear increases in verification and storage costs as the blockchain scales, or lead to high communication overhead for light clients. While other research has improved query and verification efficiency, it only guarantees the correctness of query results, not their integrity. Furthermore, existing searches fail to hide access patterns, allowing attackers to infer private information by analyzing access patterns during the search process.

[0009] In recent years, blockchain technology, as a database solution, has revolutionized traditional database systems through its decentralized, transparent, and tamper-resistant features. Unlike traditional databases, blockchain databases can not only store large amounts of data but also ensure data security and integrity. These characteristics make blockchain suitable for a variety of scenarios, including financial transactions, supply chain management, and identity authentication. For example, blockchain databases have been widely recognized in the financial sector. Blockchain platforms such as Ethereum provide smart contracts that automatically execute and verify transactions, eliminating the involvement of intermediaries, thereby reducing costs and improving efficiency. Blockchain database solutions such as Bluzelle further integrate data storage services, allowing users to leverage the decentralized nature of blockchain to protect and manage data, preventing tampering and loss. Blockchain databases are also being used in supply chain management. Research systems such as SEBDB use blockchain technology to achieve greater transparency and traceability, making data records at every stage immutable and ensuring trust and data consistency among all parties in the supply chain. These applications demonstrate the potential of blockchain technology to address the security, data management, and transparency issues faced by traditional databases.

[0010] However, using blockchain as a database presents several challenges. 1. Blockchains lack inherent data encryption capabilities. Their transparency and traceability make information stored on-chain publicly available to all nodes. This advantage ensures data integrity, but it also presents significant challenges for data privacy. Therefore, users typically encrypt sensitive data before storing it on the blockchain. However, on-chain query and verification operations on encrypted data are severely limited, as traditional query mechanisms cannot directly operate on encrypted data. Furthermore, delegating query operations to full nodes further increases the risk of data leakage. Even if the data is encrypted, the query process can still reveal metadata related to the encrypted data (such as access patterns and frequency). 2. To support query processing in a blockchain database, users are burdened with the cost of storing the entire blockchain data. To address this issue, users can choose to operate as light nodes, storing only block headers and querying full nodes for the required data. However, individual full nodes may exhibit malicious behavior, such as intentionally returning partial or tampered query results, thereby compromising the integrity of the query.

[0011] In order to support private data queries, many studies in recent years have applied searchable encryption technology to blockchains. In order to support light nodes to verify the integrity of query results, some works use some authentication data structures (ADS) to verify the integrity of returned results. vChain is the first work to solve the query integrity problem of blockchain databases. vChain focuses on Boolean range queries and designs an authentication data structure based on accumulators to ensure query integrity. However, as an asymmetric primitive, accumulators introduce high-cost bilinear pairing operations and elliptic curve operations. The large amount of proof data causes light clients to face high communication overhead. Zhu et al. proposed a verifiable aggregation query scheme based on accumulators that supports multi-select predicates. However, the accumulator it uses is the same as vChain and fails to solve the linear overhead problem. At the same time, the construction cost of ADS is high because different query dimensions require different ADS. Other studies such as LineageChain

[15] use skip list indexes to improve search efficiency, but cannot detect the integrity of query results. In addition, current studies have not fully considered the privacy issues of on-chain data. Summary of the Invention

[0012] To overcome the shortcomings of the existing technology, the present invention provides a method for implementing a verifiable oblivious query scheme based on a blockchain database, constructing a new blockchain database query framework, EVOchain, which achieves query efficiency with sublinear time complexity compared to vChain. Regarding data result verification, the present invention's method eliminates the need for on-chain integrity proof. Regarding data privacy and security, the present invention ensures strong data privacy and security. Data is stored in encrypted form on the blockchain, and queries do not expose data access patterns or forward and backward privacy.

[0013] The technical solutions adopted by the present invention to solve the technical problems are as follows:

[0014] Step 1: Define four roles, including data owners, data users, service providers, and blockchains;

[0015] Step 2: Build a threat model;

[0016] Step 3: Initialization phase: The data owner sets parameters and the trusted hardware on the service provider side during the initialization phase;

[0017] Step 4: Update phase: During the update phase, the data owner is responsible for updating the encryption index and generating a new block.

[0018] Step 5: Search phase: The data user initiates a query request, searches for a keyword, and verifies the results returned by the service provider.

[0019] Preferably, the step 1 is specifically as follows:

[0020] (1) Data owner: outsources encrypted private files to the blockchain and maintains an established encrypted index in the global state table. At the same time, the data owner is responsible for building consensus proofs and adding new blocks to the blockchain. The data owner is a full node.

[0021] (2) Data users: initiate verifiable encrypted queries on encrypted files; data users are light nodes;

[0022] (3) Service provider: provides query services for lightweight data users; service providers are full nodes;

[0023] (4) Blockchain: Blockchain is responsible for storing encrypted files.

[0024] Preferably, the step 2 is specifically as follows:

[0025] During the query processing, the service provider checks the auxiliary data structure ADS embedded in the blockchain and constructs a verification object VO containing the result verification information. The verification object is returned to the user along with the query result. Using the verification object, the user verifies the correctness and completeness of the query result according to the following criteria:

[0026] Correctness: All returned objects have not been tampered with and meet the query criteria;

[0027] Completeness: All valid results within the query window or subscription period are included.

[0028] Preferably, the step 3 is specifically as follows:

[0029] Step 3-1: The data owner generates a key, initializes an oblivious mapping table EDB, and sends the EDB to other full nodes based on a crash-tolerant consensus protocol;

[0030] Step 3-2: The data owner establishes a secure channel with the trusted hardware on the service provider side;

[0031] Step 3-3: The data owner initializes the trusted hardware on the service provider side and sets the metadata UpCnt and DigList stored therein.

[0032] Preferably, the step 4 is specifically as follows:

[0033] Step 4-1: The data owner sends the new data object and PRF key to the trusted hardware on the service provider side;

[0034] Step 4-2: The trusted hardware on the service provider side uses the PRF key to calculate the encryption index for each new data object and updates the stored UpCnt and DigList metadata. After the calculation is completed, the encryption index is sent to the data owner.

[0035] Step 4-3: The data owner stores the encrypted index in EDB, then constructs a new block using the encrypted data object and broadcasts it to the blockchain network.

[0036] Preferably, the step 5 is specifically as follows:

[0037] Step 5-1: The data user sends the query keyword and the PRF key corresponding to the keyword to the trusted hardware on the service provider side;

[0038] Step 5-2: The trusted hardware on the service provider side calculates the key addr corresponding to all matching records based on the stored metadata, and sends a request to the service provider to retrieve the value corresponding to the key addr in its local EDB;

[0039] Step 5-3: The trusted hardware on the service provider side calculates and verifies the storage locations of all matching records in the blockchain database based on the encrypted index. After verification, it sends the locations to the service provider. The trusted hardware then sends the number of matching records to the data user.

[0040] Step 5-4: The service provider retrieves all matching records based on the storage location provided by the trusted hardware and generates a certificate for each matching record. The service provider then sends all matching records and the corresponding certificates to the data user.

[0041] Step 5-5: The data user verifies the result returned by the service provider.

[0042] A computer program enables a computer to execute the method for implementing the above-mentioned verifiable oblivious query scheme.

[0043] An electronic device comprises: a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the electronic device executes the implementation method of the above-mentioned verifiable casual query scheme.

[0044] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method for implementing the above-mentioned verifiable oblivious query scheme.

[0045] A chip includes: a processor for calling and running a computer program from a memory, so that a device equipped with the chip executes the implementation method of the above-mentioned verifiable oblivious query scheme.

[0046] A computer program product includes a computer storage medium storing a computer program, wherein the computer program includes instructions executable by at least one processor, and when the instructions are executed by the at least one processor, the method for implementing the above-mentioned verifiable oblivious query scheme is implemented.

[0047] The beneficial effects of the present invention are as follows:

[0048] 1) The present invention can resist the privacy leakage problem of outsourced data in the blockchain database during update and query.

[0049] 2) The present invention can ensure that data is not tampered with and supports the correctness and integrity verification of query results.

[0050] 3) The present invention can support high-speed query and retrieval of confidential data, realizing a high-throughput blockchain database. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1This is the EVOchain system architecture diagram of the present invention;

[0052] Figure 2 Flowchart of EVOchain, a verifiable oblivious query solution based on blockchain database. DETAILED DESCRIPTION

[0053] The present invention will be further described below with reference to the accompanying drawings and examples.

[0054] This paper proposes a new blockchain database query framework, EVOchain, which achieves sub-linear query efficiency compared to vChain. Regarding data result verification, this method eliminates the need for on-chain integrity proofs. Regarding data privacy and security, this method ensures strong data privacy and security. Data is stored in encrypted form on the blockchain, and queries do not expose data access patterns or forward and backward privacy.

[0055] The efficient and verifiable oblivious search scheme based on blockchain database designed by this invention has four roles: Figure 1 : Data owners (full nodes), data users (light nodes), service providers (full nodes) and blockchain.

[0056] (1) Data owner: outsources their encrypted private files to the blockchain and maintains an established encrypted index in the global state table. At the same time, the data owner is responsible for building consensus proofs and adding new blocks to the blockchain.

[0057] (2) Data users: can initiate verifiable encrypted queries on encrypted files.

[0058] (3) Service provider: can provide query services for lightweight data users.

[0059] (4) Blockchain: Blockchain is responsible for storing encrypted files.

[0060] Service providers can be considered untrusted nodes in a blockchain network and potential adversaries. Due to various issues, such as program vulnerabilities, security vulnerabilities, and commercial interests, service providers may return tampered or incomplete query results, thereby undermining the intended security of the blockchain. To address this threat, verifiable query processing is adopted, allowing service providers to prove the integrity of query results.

[0061] Specifically, during query processing, the service provider examines the auxiliary data structure (ADS) embedded in the blockchain and constructs a verification object (VO) containing verification information for the results. This verification object is returned to the user along with the query results. Using the verification object, the user can verify the correctness and completeness of the query results based on the following criteria:

[0062] Correctness: All returned objects have not been tampered with and all meet the query criteria.

[0063] Completeness: All valid results within the query window or subscription period are included.

[0064] The workflow of the blockchain database-based verifiable oblivious query solution EVOchain designed by the present invention is shown in the figure.

[0065] It includes the following three stages:

[0066] (1) Initialization phase: The data owner (full node) sets parameters and the trusted hardware of the service provider (full node) in the initialization phase. This phase is divided into the following steps:

[0067] Step 1: The data owner generates a key, initializes an oblivious mapping table EDB, and sends the EDB to other full nodes based on a crash-tolerant consensus protocol.

[0068] Step 2: The data owner establishes a secure channel with the trusted hardware on the service provider side.

[0069] Step 3: The data owner initializes the trusted hardware on the service provider side and sets the metadata UpCnt and DigList stored therein.

[0070] (2) Update phase: The data owner is responsible for updating the encryption index and generating new blocks during the update phase. This phase is divided into the following steps:

[0071] Step 1: The data owner sends the new data object and PRF key to the trusted hardware on the service provider side.

[0072] Step 2: The trusted hardware on the service provider side uses the PRF key to calculate the encryption index for each new data object and updates the stored UpCnt and DigList metadata. After the calculation is completed, the encryption index is sent to the data owner.

[0073] Step 3: The data owner stores the encrypted index in the EDB. The encrypted data object is then used to construct a new block and broadcast it to the blockchain network.

[0074] (3) Search phase: The data user initiates a query request, searches for a keyword, and verifies the results returned by the service provider. This phase is divided into the following steps:

[0075] Step 1: The data user sends the query keyword and the PRF key corresponding to the keyword to the trusted hardware on the service provider side.

[0076] Step 2: The trusted hardware on the service provider side calculates the key addr corresponding to all matching records based on the stored metadata, and sends a request to the service provider to retrieve the value corresponding to the key addr in its local EDB.

[0077] Step 3: The trusted hardware on the service provider side calculates and verifies the storage locations of all matching records in the blockchain database based on the encrypted index. Once verified, it sends the location to the service provider. The trusted hardware then sends the number of matching records to the data user.

[0078] Step 4: The service provider retrieves all matching records from the storage location provided by the trusted hardware and generates a certificate for each matching record. The service provider then sends all matching records and the corresponding certificates to the data user.

[0079] Step 5: The data user verifies the result returned by the service provider.

[0080] Example:

[0081] 1. Initialization phase;

[0082] To ensure the integrity of query results and prevent untrusted service providers from tampering with or forging query results, trusted hardware technology is introduced, with sensitive operations performed by trusted hardware on the server side. Therefore, during the initialization phase, in addition to setting regular parameters, the trusted hardware also needs to be initialized. The details are as follows (see Table 1):

[0083] Table 1

[0084]

[0085] (1) The data owner randomly selects a key k and a symmetric encryption key ks.

[0086] (2) The data owner establishes a secure channel with the Enclave on the service provider side through remote authentication.

[0087] (3) The data owner initializes an oblivious mapping table (EDB) as the global state and sends it to other full nodes through a crash-tolerant consensus protocol.

[0088] (4) The enclave on the service provider side initializes two UpCnt and DigList to store the update count of the keyword and the summary of all corresponding records.

[0089] 2. Update phase;

[0090] This paper designs a two-level inverted index that records the IDs of data objects containing a keyword and their corresponding block numbers, enabling efficient keyword queries. To ensure data privacy, the data owner uses a lightweight PRF to calculate an encrypted two-level inverted index I and encrypts the data objects in the block. To ensure the integrity of the results, for new data objects, the data owner updates the metadata in the service provider's enclave for subsequent verification. The design details are shown in Table 2:

[0091] Table 2

[0092]

[0093] (1) The data owner sends a batch of data objects and key k to the enclave on the service provider side.

[0094] (2) Enclave first initializes the mapping table I. Then, for each data object o i , extract all the keywords contained in it. For each keyword w, calculate the corresponding PRF key K based on k t =f(k,w), and retrieve UpCnt[w] to obtain cnt(the number of updates of w).

[0095] (3) For the keyword w contained in o_i, generate the key addr of the corresponding index item in the index table = F(K t ,w||cnt||0), and the value Add the key-value pair (addr, val) to I.

[0096] (4) For the keyword w contained in o_i, calculate the hash value of the corresponding index H(currBlkId||i), XOR it with DigList[w] to obtain the new DigList[w] value. At the same time, update UpCnt[w].

[0097] (5) When the processing of the new data object is completed, the Enclave on the service provider side sends I to the data owner.

[0098] (6) The data owner adds the encrypted index in I to EDB and synchronizes this update to other full nodes.

[0099] (7) The data owner uses k_s as the key to encrypt all new data objects and write them into a new block. Afterwards, a balanced Merkle tree is built from the bottom up on all encrypted data objects, and the root hash is written into the block header.

[0100] (8) The data owner broadcasts the new block to the blockchain network, completing the block generation.

[0101] This stage has the following characteristics:

[0102] (1) Data privacy protection: The index is encrypted and stored in an oblivious storage structure to avoid access pattern leakage.

[0103] (2) Data integrity protection: Trusted hardware maintains summary information of keywords to ensure the integrity of the results.

[0104] (3) Efficient index organization: Design a secondary inverted index that supports fast matching record positioning and occupies less storage.

[0105] 3. Search phase;

[0106] The search for keywords is performed jointly by the Enclave and the service provider. The Enclave is responsible for performing sensitive operations, such as parsing and verifying the encrypted index; the service provider is responsible for retrieving the encrypted index requested by the Enclave and obtaining matching data objects from the blockchain database. Details are shown in Table 3:

[0107] Table 3

[0108]

[0109]

[0110] (1) The user compares the query keyword w with the corresponding PRF key K w Sent to the Enclave on the service provider side.

[0111] (2) Enclave first searches for the internally maintained update counter UpCnt[w] and summary DigList[w] of w, and retrieves all index items corresponding to w one by one: for the i-th index item, calculate its key addr in the index table = F(K w ,w||cnt||0), then sends a request to the service provider to obtain the value val corresponding to the key addr in its local EDB. After that, the Enclave parses val to obtain the secondary index

[0112] (3) When all index items are retrieved, Enclave adds all the parsed secondary indexes to the set Res, and compares the summary of the secondary index in Res with DigList[w]. If they are equal, it means that the index items returned by the service provider are correct and complete. Enclave sends cnt←UpCnt[w] and Res to the data user and service provider respectively.

[0113] (4) After receiving the Res set sent by the Enclave, the service provider obtains the i-th encrypted data object o in the block CurrBlkId according to each secondary index (CurrBlkId,i), and generates a Merkle proof for it; it adds o and the proof to R and VO respectively. Finally, the service provider sends R and VO to the data user.

[0114] (5) The data user verifies the correctness and completeness of the results returned by the service provider. First, the number of returned results is determined to be equal to cnt. If not, the result returned by the service provider is incorrect and an error is reported. Then, for each data object in R, the corresponding Merkle proof in VO is used for verification. When all verifications pass, the data user can be confident that the returned results are complete and correct.

[0115] This stage has the following characteristics:

[0116] (1) Data privacy protection: Privacy-sensitive operations are placed within the enclave; the privacy of retrieval from the service provider’s local EDB is guaranteed by the use of oblivious storage.

[0117] (2) Data integrity protection: Enclave can ensure the integrity of the encrypted index; the correctness and integrity of the query results are guaranteed by the immutability of the blockchain.

[0118] (3) Efficient search: The encrypted index parsing process only requires lightweight cryptographic primitives, and service providers can directly locate matching data objects through the secondary inverted index.

[0119] The innovative features of the present invention are as follows:

[0120] 1) This solves the privacy leakage issue of outsourced data in blockchain databases. By encrypting data objects and introducing trusted hardware technology, data privacy is effectively protected. Even if the data is made public, no attacker can obtain any valid information.

[0121] 2) We achieve efficient and secure keyword queries on encrypted data. We design a novel two-level inverted index to efficiently organize records with the same keyword. We also construct an encrypted index using lightweight cryptographic primitives and store it in oblivious storage, ensuring oblivious security.

[0122] 3) Guarantee the integrity of outsourced data and query results. By leveraging the immutable nature of blockchain, the integrity of outsourced data is ensured. By performing index verification in trusted hardware and constructing Merkle proofs based on the inherent characteristics of blockchain, the integrity and correctness of query results are also guaranteed.

Claims

1. A method for implementing a verifiable oblivious query scheme based on a blockchain database, characterized in that: The steps include: Step 1: Define four roles, including data owners, data users, service providers, and blockchains; Step 2: Build a threat model; Step 3: Initialization phase: The data owner sets parameters and the trusted hardware on the service provider side during the initialization phase; Step 4: Update phase: During the update phase, the data owner is responsible for updating the encryption index and generating a new block. Step 5: Search phase: The data user initiates a query request, searches for a keyword, and verifies the results returned by the service provider.

2. The method for implementing a verifiable oblivious query scheme based on a blockchain database according to claim 1, characterized in that: The step 1 is specifically as follows: (1) Data owner: outsources encrypted private files to the blockchain and maintains an established encrypted index in the global state table. At the same time, the data owner is responsible for building consensus proofs and adding new blocks to the blockchain. The data owner is a full node. (2) Data users: initiate verifiable encrypted queries on encrypted files; data users are light nodes; (3) Service provider: provides query services for lightweight data users; service providers are full nodes; (4) Blockchain: Blockchain is responsible for storing encrypted files.

3. The method for implementing a verifiable oblivious query scheme based on a blockchain database according to claim 2, characterized in that: The step 2 is specifically as follows: During the query processing, the service provider checks the auxiliary data structure ADS embedded in the blockchain and constructs a verification object VO containing the result verification information. The verification object is returned to the user along with the query result. Using the verification object, the user verifies the correctness and completeness of the query result according to the following criteria: Correctness: All returned objects have not been tampered with and meet the query criteria; Completeness: All valid results within the query window or subscription period are included.

4. The method for implementing a verifiable oblivious query scheme based on a blockchain database according to claim 3, characterized in that: The step 3 is specifically as follows: Step 3-1: The data owner generates a key, initializes an oblivious mapping table EDB, and sends the EDB to other full nodes based on a crash-tolerant consensus protocol; Step 3-2: The data owner establishes a secure channel with the trusted hardware on the service provider side; Step 3-3: The data owner initializes the trusted hardware on the service provider side and sets the metadata UpCnt and DigList stored therein.

5. The method for implementing a verifiable oblivious query scheme based on a blockchain database according to claim 4, characterized in that: The step 4 is specifically as follows: Step 4-1: The data owner sends the new data object and PRF key to the trusted hardware on the service provider side; Step 4-2: The trusted hardware on the service provider side uses the PRF key to calculate the encryption index for each new data object and updates the stored UpCnt and DigList metadata. After the calculation is completed, the encryption index is sent to the data owner. Step 4-3: The data owner stores the encrypted index in EDB, then constructs a new block using the encrypted data object and broadcasts it to the blockchain network.

6. The method for implementing a verifiable oblivious query scheme based on a blockchain database according to claim 5, characterized in that: The step 5 is specifically as follows: Step 5-1: The data user sends the query keyword and the PRF key corresponding to the keyword to the trusted hardware on the service provider side; Step 5-2: The trusted hardware on the service provider side calculates the key addr corresponding to all matching records based on the stored metadata, and sends a request to the service provider to retrieve the value corresponding to the key addr in its local EDB; Step 5-3: The trusted hardware on the service provider side calculates and verifies the storage locations of all matching records in the blockchain database based on the encrypted index. After verification, it sends the locations to the service provider. The trusted hardware then sends the number of matching records to the data user. Step 5-4: The service provider retrieves all matching records based on the storage location provided by the trusted hardware and generates a certificate for each matching record. The service provider then sends all matching records and the corresponding certificates to the data user. Step 5-5: The data user verifies the result returned by the service provider.

7. A computer program, characterized in that The computer program enables a computer to execute the method according to any one of claims 1 to 6.

8. An electronic device, characterized in that: include: processor and memory; The memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the electronic device performs the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A chip, characterized in that: include: A processor, configured to call and run a computer program from a memory, so that a device equipped with the chip executes the method according to any one of claims 1 to 6.

Images