Block chain data query method, device and system and storage medium

Abstract

The invention discloses a block chain data query method, device and system and a storage medium. According to the technical scheme provided by the invention, after a full node receives a data request from a light node, a first event set meeting a query condition is determined based on the data request, certification information used for certification of credibility of the first event set is generated, and a request result including the certification information and the first event set is sent to the light node; and after receiving the request result, the light node can verify whether the first event set is credible based on the proof information so as to realize credible data query of the light node in the block chain network.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain data query method, device, system and storage medium. Background Art

[0002] As a decentralized and distributed system, blockchain is open, traceable and tamper-proof, which makes it widely used in many fields such as financial transactions, supply chain management, or medical information protection.

[0003] In the blockchain network, user nodes include light nodes and full nodes. When synchronizing blockchain data, light nodes synchronize and store block header information, but do not retain complete historical transaction records. Because they do not store complete historical transaction records, light nodes cannot directly query and obtain blockchain data. Full nodes are different from light nodes. When synchronizing blockchain data, full nodes retain all transaction data and status information of the blockchain network, so full nodes can query all data on the blockchain network.

[0004] Light nodes can request full nodes to query blockchain data. A common strategy is that light nodes send data requests to multiple full nodes at the same time. Each full node independently performs query operations based on the data request and feeds back query data to the light node. The light node regards the same majority of the received query data as the final query data. However, in the blockchain network, there may be malicious nodes. Under this query strategy, the more malicious nodes are included in the above multiple full nodes, the lower the credibility of the query data will be, and the query data cannot be guaranteed to be credible.

[0005] Therefore, how to provide a reliable blockchain data query method is an urgent problem to be solved. Summary of the invention

[0006] The present application provides a blockchain data query method, device, system and storage medium, so that light nodes can perform reliable data query in a blockchain network.

[0007] In a first aspect, the present application provides a blockchain data query method, which is applied to a light node in a blockchain network, and the method comprises: the light node sends a data request to a full node, and the data request includes a query condition; the light node receives a request result from the full node, and the request result includes proof information and a first event set, wherein the first event set is a set of blockchain events that meet the query condition, and the proof information is used to prove that the first event set is trusted data that meets the query condition; the light node verifies whether the first event set is trustworthy based on the proof information.

[0008] By adopting the blockchain data query method provided by the present application, the light node can verify whether the first event set returned by the full node is credible based on the above-mentioned proof information, rather than determining the final query data based on the majority of identical results in multiple query data provided by multiple full nodes (wherein the number of malicious nodes included in the multiple full nodes is unknown). On the one hand, the light node can perform credible data queries in the blockchain network. On the other hand, if the light node determines that the first event set is credible, it can no longer send the above-mentioned data request to other full nodes, avoiding invalid repeated queries by multiple full nodes and reducing performance loss. On the other hand, the light node needs to send data requests and receive request results multiple times, and analyze the request results received multiple times to determine the credibility of the request results. Instead of sending a data request once and receiving a request result once, it can determine whether the request result is credible, thereby improving the efficiency of data communication.

[0009] In a possible implementation, the query condition includes at least one of the following: a time range of an event, a value range of one or more numerical parameters of an event, and one or more non-numerical parameters of an event.

[0010] In this implementation, the query conditions may include a variety of specific types of condition parameters, which can effectively enhance the applicability of the solution. In addition, the condition parameters are diverse and specific, which can make the query results more accurate.

[0011] In a possible implementation, the proof information is information obtained based on a zero-knowledge proof protocol.

[0012] In this implementation, the proof information generated based on the zero-knowledge proof protocol proves that the first event set is trusted data that meets the query conditions without disclosing the source blockchain data stored in the full node and the query process of the above-mentioned first event set. While realizing the trusted query of the light node, the data security of the blockchain network is jointly maintained.

[0013] In one possible implementation, the query condition includes a time range of an event, the request result also includes a second event set, the proof information corresponds to the second event set, the second event set is a collection of blockchain events that satisfy the time range, the first event set is included in the second event set, and the light node verifies whether the first event set is credible based on the proof information, including: the light node verifies whether the second event set is credible based on the proof information, so as to verify whether the first event set is credible.

[0014] In this implementation, the first event set is derived from the second event set. This application proves whether the first event set is credible by proving whether the second event set is credible. It can be understood as proving whether the first event set is credible by proving whether the source of the first event set is credible, which can further improve the credibility of the result data.

[0015] In one possible implementation, the light node verifies whether the second event set is credible based on the proof information, including: the light node verifies whether the second event set is credible based on the sum of hash values ​​of all events in the second event set, the second event set, and the proof information, wherein the hash value of the blockchain event is determined based on a homomorphic hash function.

[0016] In this implementation, when the hash value of each blockchain is determined based on a homomorphic hash function, if a first corresponding relationship is stored in the light node (the first corresponding relationship is the corresponding relationship between the index of the event and the hash sum, and the hash sum corresponding to the reference index recorded in the specific first corresponding relationship is: the sum of the hash value of the reference event corresponding to the reference index and the hash values ​​of other events that are earlier than the reference event, and the reference index is any index in the first corresponding relationship), then the sum of the hash values ​​of all events in the second event set can be determined based on the first corresponding relationship and the characteristics of the homomorphic hash function without storing the specific event content of each event. The sum of the hash values ​​of all events in the second event set is determined by calculating the hash value of the specific event content of each event, thereby reducing the storage overhead and computing overhead of the light node.

[0017] In a possible implementation, the request result also includes a first index and a second index, the first index being the index of the earliest event in the second event set, and the second index being the index of the latest event in the second event set. A first correspondence is stored in the light node, and the first correspondence is the correspondence between the index of the event and the hash sum, wherein the hash sum corresponding to the reference index recorded in the first correspondence is: the sum of the hash value of the reference event corresponding to the reference index and the hash values ​​of other events that are earlier than the reference event, and the sum of the hash values ​​of all events in the second event set is determined based on the first index, the second index, and the first correspondence.

[0018] As an example, the sum of the hash values ​​of all events in the second event set is determined based on the first index, the second index, and the first corresponding relationship, including: the sum of the hash values ​​of all events in the second event set is the difference between the second hash sum and the first hash sum, the first hash sum is the hash sum corresponding to the previous index of the first index in time sequence, and the second hash sum is the hash sum corresponding to the second index.

[0019] As another example, the sum of the hash values ​​of all events in the second event set is determined based on the first index, the second index, and the first corresponding relationship, including: the sum of the hash values ​​of all events in the second event set is the sum of the difference between the second hash sum and the third hash sum and the hash value of the earliest event in the second event set, and the third hash sum is the hash sum corresponding to the above-mentioned first index.

[0020] In this implementation, the light node can determine the sum of the hash values ​​of all events in the second event set based on the first index, the second index, and the above-mentioned first corresponding relationship, with a small number of addition and subtraction operations (i.e., a small amount of operations) and a small time complexity, and further improves the query efficiency under the premise of realizing the trusted data query of the light node. In addition, the light node does not need to store the specific event content of the event, reducing the storage overhead.

[0021] In one possible implementation, in the index of blockchain events stored in the light node, different indexes of different events corresponding to the same event type identifier are established in chronological order through pointers, and the event type identifier is used to indicate the type of event corresponding to the index.

[0022] In an embodiment of the present application, in the index of blockchain events stored in the light node, when the indexes of different types of events are associated with each other through pointers, the hash sum corresponding to the reference index recorded in the above-mentioned first correspondence stored in the light node can be: the sum of the hash value of the reference event corresponding to the reference index and the hash values ​​of other events that are earlier than the reference event and belong to the same type of event as the reference event, or, it can also be: the sum of the hash value of the reference event corresponding to the reference index and the hash values ​​of other events that are earlier than the reference event and belong to the same type or different type as the reference event.

[0023] In this implementation, the light node establishes an association relationship between different types of events through pointers. When the light node detects a query task that can be completed by the light node alone, the light node can first determine whether the value of the parameter in the prerequisite of each type of event meets the value condition of the corresponding parameter in the query condition. If not, the light node can directly skip (i.e., omit) the traversal search for events of this type, thereby improving the query efficiency of the query task that can be completed by the light node alone.

[0024] In a possible implementation, the request result includes: X second event sets, proof information corresponding to each of the second event sets in the X second event sets, an event type identifier corresponding to each of the second event sets, the first index corresponding to each of the second event sets, and the second index corresponding to each of the second event sets, where X is the number of types of events of different types. The light node verifies whether the second event set is credible based on the proof information to verify whether the first event set is credible, including: the light node verifies whether each of the second event sets is credible based on the proof information corresponding to each of the second event sets in the X second event sets to verify whether the first event set is credible.

[0025] In this implementation, different event type identifiers correspond to different second event sets, and different types of second event sets correspond to different proof information, which can reduce data coupling. For example, in the above-mentioned first correspondence relationship stored in the light node, the hash sum corresponding to each index can be the sum of the hash value of the event corresponding to the index and the hash values ​​of other events that are earlier than the event and belong to the same type as the event, rather than the hash sum corresponding to each index being the sum of the hash value of the event corresponding to the index and the hash values ​​of other events that are earlier than the event and belong to the same type or different types as the event, thereby reducing data coupling and also achieving the effect of reducing the computational overhead of the hash sum corresponding to each index.

[0026] It should be noted that different event type identifiers correspond to different second event sets, and different types of second event sets correspond to different proof information is only an example. This article does not limit the types of different events contained in the second event set and the number of second event sets corresponding to the proof information. For example, a request result may also include a second event set and a proof information corresponding to the second event set, and different events in the second event set belong to the same type or different types. Alternatively, a request result may also include X second event sets and a proof information corresponding to the X second event sets, that is, the proof information is generated based on the X second event sets. It is understandable that compared with the proof method that different types of second event sets correspond to different proof information, a request result may also include a second event set and a proof information corresponding to the second event set, and different events in the second event set belong to the same type or different types, or a request result may also include X second event sets and a proof information corresponding to the X second event sets, which can effectively reduce the amount of data carried in the request result and reduce communication pressure.

[0027] In one possible implementation, the light node verifies whether the first event set is credible based on the proof information, including: the light node verifies whether the first event set is credible based on the first event set, the sum of hash values ​​of all events in the first event set, and the proof information, wherein the hash value of the blockchain event is determined based on a homomorphic hash function.

[0028] In this implementation, whether the first event set is credible is directly proved based on the first event set itself. The logic is simple and easy to understand, and correspondingly, the request result may not include the second event set, which can reduce the amount of data carried by the request result and reduce communication pressure.

[0029] In a possible implementation, the request result also includes first index information, the first index information includes the index corresponding to each event in the first event set, and the light node stores a second correspondence relationship, the second correspondence relationship is the correspondence between the index of the event and the hash value of the event. Before the light node determines the hash value of each event in the first event set based on the first index information and the second correspondence relationship, and determines the sum of the hash values ​​of all events in the first event set based on the hash value of each event in the first event set, and the proof information.

[0030] In an embodiment of the present application, the hash value of each event is synchronized between the full node and the light node based on the first index information, so that the light node can determine the sum of the hash values ​​of all events in the first event set based on the above-mentioned first index information and the second corresponding relationship, so that the light node does not need to store the specific event content of each event, and determines the sum of the hash values ​​of all events in the first event set by calculating the hash value of each specific event content, thereby reducing storage overhead.

[0031] In a possible implementation, the method further includes: when the light node determines that the first event set is unreliable (specifically, it can be directly determined based on the first event set that the first event set is unreliable, or it can be indirectly determined based on the second event set that the first event set is unreliable), sending the data request to another full node.

[0032] In one possible implementation, the time range condition included in the query condition is any moment starting from the first moment, the data request is a subscription type data request, and the light node receives the request result from the full node including: after the light node sends the subscription type data request to the full node once, the light node continues to receive the request result returned from the full node based on the data request.

[0033] In this implementation, based on subscription-type data requests, light nodes can obtain multiple complete and non-omission result data that meets the query conditions based on a single data request, rather than obtaining updated data by periodically and repeatedly sending almost identical data requests. This can reduce network transmission pressure and reduce query delays.

[0034] In one possible implementation, the light node sending a data request to the full node includes: upon determining that result data (for example, result data can be understood as the above-mentioned first event set) contained in the request results previously sent by the full node are all credible result data, the light node sending the data request to the full node.

[0035] In this implementation, after the light node determines that it has received credible result data sent by the full node, it sends a subscription-type data request to the full node, which can effectively reduce the probability of the light node receiving unreliable subscription data.

[0036] In a possible implementation, the method further includes: during the process of continuously receiving the request results, after determining that there is an untrustworthy request result, the light node refuses to receive the request result from the full node, thereby effectively preventing malicious attacks.

[0037] In a second aspect, the present application provides a blockchain data query method, which is applied to a full node in a blockchain network, and the method includes: the full node receives a data request from a light node, and the data request includes a query condition; the full node determines a first event set based on the data request, and the first event set is a set of blockchain events that meet the query condition; the full node generates proof information based on the first event set, and the proof information is used to prove that the first event set is credible; the full node sends a request result to the light node, and the request result includes the proof information and the first event set.

[0038] By adopting the blockchain data query method provided by the present application, the full node can prove to the light node that the first event set is credible based on the above-mentioned proof information, so that the light node can perform credible data query in the blockchain network. In addition, the full node can prove to the light node that the first event set is credible based on the above-mentioned proof information, and there is no need to integrate the return results of multiple full nodes to analyze the credibility of the results, thereby reducing repeated invalid queries, reducing performance loss, and improving data communication efficiency.

[0039] In a possible implementation, the query condition includes at least one of the following: a time range of an event, one or more numerical parameters of an event, and one or more non-numerical parameters of an event.

[0040] In this implementation, the query item may include a variety of specific types of condition parameters, which can effectively enhance the applicability of the solution. In addition, the condition parameters are diverse and specific, which can make the query results more accurate.

[0041] In one possible implementation, the query condition includes a time range of an event, the request result also includes the second event set, the second event set is a collection of blockchain events that meet the time range, the first event set is included in the second event set, and the full node generates proof information based on the first event set, including: the full node generates proof information based on the second event set, and the proof information is used to prove that the first event set is trusted data by proving that the second event set is trusted data.

[0042] In this implementation, the first event set is derived from the second event set. Whether the first event set is credible is proved by proving whether the second event set is credible. This can be understood as proving that the first event set is credible by proving that the source of the first event set is credible, which can further improve the credibility of the result data.

[0043] In a possible implementation manner, the proof information is generated based on a zero-knowledge proof function, a sum of hash values ​​of all events in the second event set, and the second event set.

[0044] As an example, the full node may calculate the hash value of each event in the second event set one by one and sum them up to obtain the sum of the hash values ​​of all events in the second event set, wherein the hash value of the calculated event is calculated based on a homomorphic hash function.

[0045] In this implementation, the proof information is generated based on the zero-knowledge proof protocol without disclosing the source blockchain data stored in the full node and the query process of the above-mentioned first event set, to prove that the first event set is trusted data that meets the query conditions. While realizing the trusted query of the light node, it effectively guarantees the data security on the full node side.

[0046] In a possible implementation, the request result further includes a first index and a second index, wherein the first index is an index of the earliest event in the second event set, and the second index is an index of the latest event in the second event set.

[0047] In this implementation, the first index and the second index are carried in the request result to indicate that the light node determines the sum of the hash values ​​of all events in the second event set based on the first index, the second index, and the first corresponding relationship. Compared with carrying the index corresponding to each event set in the second event set in the request result, and the light node determining the sum of the hash values ​​of all event sets in the second event set based on the index corresponding to each event set in the second event set and the second corresponding relationship, carrying the first index and the second index in the request result can reduce the size of the communication data packet and effectively improve the communication efficiency. The description of the first corresponding relationship and the second corresponding relationship can refer to the description elsewhere in this article and will not be described in detail here.

[0048] In a possible implementation, among the blockchain events stored in the full node, different events corresponding to the same event type identifier are established in chronological order through pointers.

[0049] In this implementation, the full node establishes associations between different types of events through pointers. When executing a query task based on the above query conditions, the full node can first determine whether the values ​​of the parameters in the prerequisites of a certain type of event are consistent with the values ​​of the corresponding parameters in the query conditions. If there are type events in which the values ​​of the parameters in the prerequisites are inconsistent with the values ​​of the corresponding parameters in the query conditions, the traversal query on events of this type can be directly skipped, that is, some types of events that do not correspond to the query conditions can be skipped, thereby effectively improving the query efficiency.

[0050] In a possible implementation, the request result includes: X second event sets, proof information corresponding to each second event set in X second event sets, event type identifier corresponding to each second event set, first index corresponding to each second event set, and second index corresponding to each second event set, wherein the first index is the index of the earliest event in the corresponding second event set, the second index is the index of the latest event in the corresponding second event set, and X is less than or equal to the number of different event types. Different types of second event sets correspond to different proof information, which is conducive to reducing data coupling.

[0051] In one possible implementation, the full node determines a first event set based on the query condition, including: the full node determines a first event type identifier from events with different event type identifiers, the value of a parameter in a prerequisite corresponding to the first event type identifier meets the value condition of the parameter corresponding to the query condition, and the prerequisite refers to a condition that is satisfied by every event corresponding to the first event type identifier; the full node searches for events that satisfy the query condition from the events corresponding to the first event type identifier in pointer order to obtain the first event set.

[0052] In this implementation, the full node can directly skip the traversal query of some types of events that do not correspond to the query conditions based on the prerequisites corresponding to different types of events, thereby effectively improving the query efficiency.

[0053] In a possible implementation, the proof information is generated based on a zero-knowledge proof protocol, a sum of hash values ​​of all events in the first event set, and the first event set.

[0054] In this implementation, whether the first event set is credible is directly proved based on the first event set itself. The logic is simple and easy to understand, and correspondingly, the request result may not include the second event set, which can reduce the amount of data carried by the request result and reduce communication pressure.

[0055] In a possible implementation, the full node stores an index of each event in the first event set, and the request result also includes first index information, where the first index information includes an index corresponding to each event in the first event set.

[0056] In an embodiment of the present application, the request result includes the above-mentioned first index information, which is used to instruct the light node to determine the sum of the hash values ​​of all events in the first event set based on the above-mentioned first index information and the second corresponding relationship, and to determine whether the first event set is credible based on the sum of the hash values ​​of all events in the first event set.

[0057] In one possible implementation, the time range condition included in the query condition is any time from the first moment onwards, the data request is a subscription type data request, and the full node sends the request result to the light node, including: after the full node receives the subscription type data request once, the full node periodically sends the latest request result that meets the query condition to the light node; or, after the full node queries K blockchain events corresponding to the query condition, the full node sends the latest request result to the light node, where K is a positive integer greater than or equal to 1.

[0058] In this implementation, based on subscription-type data requests, the full node can send result data that meets the query conditions to the full node multiple times in full and without omission based on a single data request, rather than receiving almost identical data requests repeatedly and regularly, thereby reducing network transmission pressure and reducing query delays.

[0059] In a third aspect, the present application provides a blockchain data query device, comprising a unit for executing the method shown in any implementation method in the corresponding aspect of the embodiment of the present application.

[0060] In a fourth aspect, the present application provides a blockchain data query device, characterized in that it includes a processor, and the processor is used to read and execute a computer program stored in a memory to implement the method shown in any implementation method in the corresponding aspect of the embodiment of the present application.

[0061] In a possible implementation, the device further includes the above-mentioned memory. Optionally, the processor and the memory are integrated together.

[0062] In one possible implementation, the processor is configured to support the device in executing the corresponding functions in the blockchain data query method, and the memory is used to store the computer programs (or computer executable instructions) and / or data necessary for the device.

[0063] In one possible implementation, the device further includes a communication interface, which is used to support communication between the device and other network elements, such as sending or receiving data and / or signals. Exemplarily, the communication interface can be a transceiver, circuit, bus, module or other type of communication interface.

[0064] In a possible implementation, the device is a chip.

[0065] In a fifth aspect, the present application provides a blockchain data query device, which includes a processor and a transceiver, the processor is coupled to the transceiver, and the processor is used to execute a computer program or instruction to control the transceiver to receive and send information; when the processor executes the computer program or instruction, the processor is also used to implement the above method through a logic circuit or an execution code instruction. Among them, the transceiver can be a transceiver, a transceiver circuit or an input-output interface, which is used to receive signals from other blockchain data query devices other than the blockchain data query device and transmit them to the processor or send signals from the processor to other blockchain data query devices other than the blockchain data query device. When the blockchain data query device is a chip, the transceiver is a transceiver circuit or an input-output interface.

[0066] In a sixth aspect, the present application provides a blockchain data query system, characterized in that the system comprises a first query device and a second query device, the first query device is used to execute the method shown in any implementation method corresponding to the first aspect of the embodiment of the present application, and the second query device is used to execute the method shown in any implementation method corresponding to the second aspect of the embodiment of the present application.

[0067] In the seventh aspect, the present application provides a computer-readable storage medium, characterized in that the computer-readable storage medium is used to store a computer program. When the computer program is executed, the method shown in any implementation method in the corresponding aspect of the embodiment of the present application is implemented.

[0068] It can be understood that the blockchain data query device, blockchain data query system, computer storage medium, computer program, computer program product, and chip system provided above are all used to execute the method shown in any implementation method in the corresponding aspects of the embodiments of the present application. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method, which will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] Figure 1 This is a schematic diagram of an application environment of a blockchain data query method provided by an embodiment of the present application;

[0070] Figure 2A It is a structural model for storing data of light nodes and full nodes in a blockchain network provided by an embodiment of the present application;

[0071] Figure 2B This is a schematic diagram of a full node establishing an association relationship between events of the same type through pointers provided in an embodiment of the present application;

[0072] Figure 3 This is a method flow diagram of a blockchain data query method provided by an embodiment of the present application;

[0073] Figure 4 It is a flowchart diagram of a method for a light node to determine the sum of hash values ​​of all events in a second event set based on a first index and a second index provided by an embodiment of the present application;

[0074] Figure 5A It is a schematic diagram of an index storage method for storing data of different types of events based on pointers in a light node and a full node provided in an embodiment of the present application;

[0075] Figure 5B This is a schematic diagram of another index storage method for storing data of different types of events based on pointers in a light node and a full node provided in an embodiment of the present application;

[0076] Figure 5CThis is a schematic diagram of another index storage method for storing data of different types of events based on pointers in a light node and a full node provided in an embodiment of the present application;

[0077] Figure 6 A schematic diagram of the structure of a blockchain data query device provided in an embodiment of the present application;

[0078] Figure 7 A schematic diagram of the structure of another blockchain data query device provided in an embodiment of the present application;

[0079] Figure 8 A schematic diagram of the structure of another blockchain data query device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0080] The following introduces the terms involved in the embodiments of the present application.

[0081] (1) Blockchain, light node, full node, events:

[0082] Blockchain is a decentralized distributed database that can realize distributed storage of data information. Blockchain technology is a data structure that combines data blocks in a chain. It uses cryptography to generate a set of chronological, tamper-proof, and trustworthy databases. This database uses decentralized storage and can effectively ensure data security, enabling participants to establish consensus on the chronological order and current status of transaction records across the entire network.

[0083] In the blockchain network, user nodes include light nodes and full nodes. Among them, light nodes are also called light clients. When synchronizing blockchain data, light nodes only synchronize and store block header information, but do not retain complete transaction history records. In the blockchain network, based on the storage characteristics of light nodes that do not require high device performance, the number of light nodes in the blockchain network is huge, but because light nodes do not store complete transaction history records, they cannot directly query and obtain blockchain data. Unlike light nodes, full nodes will retain all transaction data and status information of the blockchain network when synchronizing blockchain data, so full nodes can query all data on the blockchain network. Generally speaking, full nodes can be understood as servers in the blockchain.

[0084] In a blockchain transaction, multiple operations may be performed, such as identity registration and transfer. In order to better describe this situation, a specific operation is generally called an "event", which is the basic unit of blockchain data query.

[0085] In this application, the parameters of an event may include a time parameter, an event identifier, and other relevant parameters of the event, etc. The other relevant parameters of the above event may include, but are not limited to, an event type identifier and a contract name.

[0086] The time parameters of an event may include the occurrence time of the event and the blockchain time. The occurrence time of the event is used to indicate the time when the event occurs, and the blockchain time is used to indicate the time of the block sequence in which the event is stored in the blockchain network. As an example, the blockchain time of the event can be generated by the occurrence time of the event and the preset rules. The preset rules depend on the specific design and are not limited in this document.

[0087] (2) Zero-knowledge proof protocol:

[0088] The zero-knowledge proof protocol is a proof method in cryptography that allows the prover to convince the verifier that a statement is true without revealing any other information related to the statement.

[0089] In the zero-knowledge proof protocol, the prover generates the corresponding private proving key (Proving Key) and verification key (Verifying Key), the private proving key is kept confidential, and the verification key can be made public. The prover generates proof information based on the private proving key, the queried result data, and the zero-knowledge proof function, and sends the result data and the proof information to the verifier. The verifier determines that the result data is credible based on the verification key, the result data, the proof information, and the corresponding verification function.

[0090] In an embodiment of the present application, before the light node generates a data request, the full node can generate a private proof key and a verification key based on the zero-knowledge proof protocol in advance, and synchronize the verification key to the light node. After the full node queries the result data, it generates proof information based on the private proof key and sends it to the light node. After the light node receives the proof information, it determines whether the result data is credible based on the proof information and the verification key. For ease of description, this article omits the description of the private proof key and the verification key when describing the parameters used to generate the proof information and verify the proof information.

[0091] (3) Homomorphic hashing:

[0092] Homomorphic hashing is a special kind of hash function that allows certain operations to remain equivalent before and after the hashing. Specifically, for any two inputs A and B and an operator + (addition), the following equality holds:

[0093] H(A+B=H(A)+H(B)

[0094] The following introduces the advantages of the blockchain data query method provided by this application in combination with other blockchain data query methods.

[0095] As a decentralized and distributed system, blockchain is widely used in many fields such as financial transactions, supply chain management, and medical information protection due to its open, traceable and tamper-proof characteristics. th fifth generation (5G) mobile communication networks th In the communication networks that evolve after 5G generation (5G), blockchain can also play an important role in identity management, data management, evidence traceability and auditing.

[0096] As mentioned above, user nodes include light nodes and full nodes. However, most user nodes are not full nodes in the blockchain. These user nodes do not synchronize all blockchain data, which means that these user nodes must rely on full nodes when querying blockchain data. In the blockchain network, the consensus mechanism can ensure the consistency of data when it is written to the blockchain, but there is no corresponding mechanism to ensure the credibility of the query operation of the light node.

[0097] For the query needs of light nodes, a common strategy is that the light node sends the data request to multiple randomly selected full nodes at the same time. Each full node independently performs query operations based on the data request and feeds back the query data to the light node. The light node regards the same majority of the received query data as the final query data. The basic assumption of this strategy is that the number of normal nodes will exceed half of the randomly selected full nodes. However, this assumption is not necessarily true in actual situations. There may be more than half of malicious nodes in the randomly selected full nodes. As the number of malicious nodes contained in the randomly selected full nodes increases, the credibility of the query data will be lower. This strategy cannot fundamentally ensure the credibility of the query data.

[0098] In view of this, the present application provides a blockchain data query method so that light nodes can perform reliable data queries in the blockchain network.

[0099] In the blockchain data query method provided in the embodiment of the present application, the light node sends a data request containing query conditions to the full node, and the full node feeds back the request result to the light node based on the data request, and the request result includes proof information and a first event set, and the first event set is a set of blockchain events that meet the query conditions; the light node can verify whether the first event set is credible based on the proof information. For example, the proof information is generated based on a zero-knowledge proof protocol.

[0100] Therefore, based on the above-mentioned proof information, the light node can verify whether the first event set returned by the full node is credible without having the complete blockchain data, instead of determining the final query data based on the majority of identical results in multiple query data provided by multiple full nodes (wherein the number of malicious nodes included in the multiple full nodes is unknown), thereby enabling the light node to perform credible data queries in the blockchain network.

[0101] On the other hand, the query strategy for determining the final query data based on the majority of identical results in multiple query data provided by multiple full nodes requires multiple full nodes to participate in the query task, and requires multiple full nodes to send query data to light nodes through the network respectively, which is bound to consume a lot of network traffic and may also cause network congestion problems. However, using the blockchain data query method provided by the present application, the light node will no longer send the above data request to other full nodes when determining that the first event set is credible based on the proof information sent by the full node. Therefore, on the basis of credible query, the number of full nodes that execute query tasks based on the data request can be effectively reduced, avoiding invalid repeated queries by multiple full nodes, and reducing performance loss.

[0102] On the other hand, light nodes no longer need to send data requests multiple times, receive request results multiple times, and analyze the request results received multiple times to determine the credibility of the request results. Instead, they only need to send a data request once and receive a request result once to determine whether the request result is credible. This reduces the number of communications between light nodes and multiple full nodes under a query task, thereby reducing network traffic consumption, avoiding network congestion, and improving data communication efficiency.

[0103] In a possible implementation, the above-mentioned proof information is used to prove that the first event set is credible data by proving that the second event set is credible data, the second event set is a set of blockchain events that meet the time range condition in the query condition, and the first event set is included in the second event set. The above-mentioned light node verifies whether the first event set is credible based on the proof information, specifically including: the light node verifies whether the second event set is credible based on the sum of the hash values ​​of all events in the second event set, the second event set, and the proof information, so as to verify whether the first event set is credible. Among them, the request result also carries a first index and a second index, the first index is the index of the earliest event in the second event set, and the second index is the index of the latest event in the second event set. The light node stores a hash sum corresponding to the index of the event, wherein the hash sum corresponding to the reference index is: the sum of the hash value of the reference event corresponding to the reference index and the hash values ​​of other events earlier than the reference event. Thus, the sum of the hash values ​​of all events in the second event set can be obtained based on the first index and the second index. For example, the hash values ​​of all events in the second event set are the difference between the second hash sum and the first hash sum, the first hash sum is the hash corresponding to the previous index of the first index in time sequence, and the second hash sum is the hash corresponding to the second index.

[0104] Therefore, on the one hand, by proving whether the query data in a larger range (the second event set that meets the time range condition in the query condition) is credible, it is possible to reflect whether the query data in a smaller range (the first event set that meets all the query conditions) is credible, thereby realizing a credible query of the light node data. On the other hand, the sum of the hash values ​​of all the events in the second event set is determined based on the difference between the second hash sum and the first hash sum, and then the second event set is verified to be credible based on the sum of the hash values ​​of all the events in the second event set to realize the method of verifying the credibility of the first event set. Compared with the method of verifying the credibility of the first event set based on the sum obtained by adding the hash values ​​of each event in the first event set, the hash corresponding to each index stored in the light node in both methods is the size of a hash value, but the former has a smaller time complexity for calculation, that is, it can effectively reduce the time complexity of calculation without increasing storage overhead, speed up program execution, and indirectly improve data query efficiency.

[0105] In some other possible implementations, in the blockchain data stored by the full node, events of the same type are associated through pointers, and the full node determines the first event set based on the query condition by: determining the first event type identifier from events with different event type identifiers, the value of the parameter in the prerequisite corresponding to the first event type identifier does not conflict with the value of the corresponding parameter in the query condition, and the prerequisite refers to a condition that is satisfied by every event corresponding to the first event type identifier; the full node searches for an event that satisfies the query condition from multiple events corresponding to the first event type identifier in pointer order to obtain the first event set.

[0106] Therefore, when executing a query task based on the above query conditions, if the full node determines that the value of the parameter in the prerequisite of a certain type of event is inconsistent with the value of the corresponding parameter in the query condition, it can directly skip the traversal of the event of that type, that is, skip some types of events that do not correspond to the query conditions, thereby effectively improving the query efficiency. For example, if the value of parameter a in the prerequisite of type A event is mutually exclusive with the value of parameter a in the query condition, it means that all events of type A do not meet the query condition, so the full node can directly skip the event of type A when querying, thereby effectively improving the query efficiency.

[0107] The following combination Figure 1 Introduce the application environment of the blockchain data query method provided by this application.

[0108] like Figure 1 As shown, the blockchain network includes N blockchain nodes, where N is greater than or equal to 2.

[0109] Each of the N blockchain nodes can be used as a full node or a light node, and the number of full nodes included in the N blockchain nodes is greater than or equal to 1, and the number of light nodes is greater than or equal to 1.

[0110] Among them, the light node does not need to store the complete data of the event (for example, the light node does not need to store the specific event content of the event), and the full node stores the complete data of the event. The light node can query the blockchain data through the full node.

[0111] As an example, the data of events stored in a full node may include the event itself and the index of the event, and the data of events stored in a light node may include the index of the event and the hash value of the event. As another example, the data of events stored in a light node may also include the index of the event, the hash sum corresponding to the event or the index of the event, wherein the hash sum corresponding to the event or the index of the event refers to the sum of the hash value of the event and the hash values ​​of other events that are earlier than the event. In some other possible implementations, the data of events stored in a light node and / or a full node may also include an event type identifier of the event, which is used to indicate the type of event. Specifically, it is embodied in the data structure used for data storage, and events of the same type may share the same event type identifier, or an event type identifier may be stored for each event.

[0112] In an embodiment of the present application, each blockchain node in the blockchain network can be a network element in a communication system, and the network elements in the communication system may include terminals, radio access network (RAN) nodes, and core network elements.

[0113] The terminal can be called user equipment (UE), mobile station (MS), mobile terminal (MT), etc., or a device used to provide voice or data connectivity to users, or an IoT device. For example, terminal devices include handheld devices with wireless connection functions, vehicle-mounted devices, etc. At present, terminal devices can be: mobile phones, tablet computers, laptops, PDAs, mobile internet devices (MID), wearable devices (such as smart watches, smart bracelets, pedometers, smart glasses, etc.), vehicle-mounted equipment (such as cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed railways, etc.), satellite terminals, virtual reality (VR) equipment, augmented reality (AR) equipment, smart point of sale (POS) machines, customer-premises equipment (CPE), wireless terminals in industrial control, smart home devices (such as refrigerators, TVs, air conditioners, electric meters, etc.), intelligent robots, robotic arms, workshop equipment, wireless terminals in unmanned driving, wireless terminals in telemedicine, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, or wireless terminals in smart homes, flying equipment (such as intelligent robots, hot air balloons, drones, airplanes), etc. The terminal device can also be a vehicle device, such as a complete vehicle device, a vehicle-mounted module, a vehicle-mounted chip, an on-board unit (OBU) or a telematics box (T-BOX), etc. The terminal device can also be other devices with terminal functions. For example, the terminal device can also be a device that serves as a terminal function in D2D communication.

[0114] The embodiments of the present application do not limit the device form of the terminal. The device for realizing the function of the terminal device can be a terminal device; it can also be a device that can support the terminal device to realize the function, such as a chip system. The device can be installed in the terminal device or used in combination with the terminal device. In the embodiments of the present application, the chip system can be composed of chips, or it can include chips and other discrete devices.

[0115] RAN nodes are nodes in the radio access network (RAN), and can also be called access network equipment or RAN equipment. RAN nodes are used to help terminals achieve wireless access. In some scenarios, the roles of RAN nodes and terminals are relative. For example, a network element configured as a mobile base station (such as a helicopter or drone), for those terminals that access the RAN through a network element configured as a mobile base station, the network element configured as a mobile base station is a base station; but for a fixed base station, the network element configured as a mobile base station is a terminal. RAN nodes and terminals are sometimes referred to as communication devices. For example, the network element configured as a mobile base station can be understood as a communication device with base station functions, and the network element configured as a mobile base station can also be understood as a communication device with terminal functions.

[0116] In a possible scenario, the RAN node may be a base station, an evolved NodeB (eNodeB), a transmitting and receiving point (TRP), a transmitting point (TP), a next generation NodeB (gNB), a next generation base station in the sixth generation (6G) mobile communication system, a base station in a future mobile communication system, a satellite, or an access point (AP) in a WiFi system, an integrated access and backhaul (IAB) node, a RAN node in a mobile switching center non-terrestrial network (NTN) communication system, that is, it may be deployed on a high altitude platform or satellite, etc. The RAN node may be a macro base station, a micro base station or an indoor station, a relay node or a donor node, or a wireless controller in a cloud radio access network (CRAN) scenario. The RAN node may also be a device that functions as a base station in device to device (D2D) communication, vehicle networking communication, drone communication, and machine communication. Optionally, the RAN node may also be a server, a wearable device, a vehicle or an onboard device, etc. For example, the access network device in the vehicle to everything (V2X) technology may be a road side unit (RSU).

[0117] In another possible scenario, multiple RAN nodes collaborate to assist the terminal in achieving wireless access, and different RAN nodes respectively implement part of the functions of the base station. For example, the RAN node may be a centralized unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU), etc. The CU and DU may be separately configured, or may be included in the same network element, such as a baseband unit (BBU). The RU may be included in a radio frequency device or a radio frequency unit, such as a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH). It is understandable that the RAN node may be a CU node, a DU node, or a device including a CU node and a DU node. In addition, the CU may be divided into a RAN node in the access network RAN, or the CU may be divided into a RAN node in the core network (CN), without limitation here.

[0118] In different systems, CU (or CU-CP and CU-UP), DU or RU may also have different names, but those skilled in the art can understand their meanings. For example, in an open RAN (open RAN, ORAN) system, CU may also be called O-CU (open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, CU, CU-CP, CU-UP, DU and RU are described as examples in this application. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application may be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0119] In the embodiments of the present application, the form of the RAN node is not limited, and the device for implementing the function of the RAN node may be a RAN node; or may be a device capable of supporting the RAN node to implement the function, such as a chip system. The device may be installed in the RAN node or used in conjunction with the RAN node.

[0120] The core network elements may include but are not limited to the following network functions (NF): user plane function (UPF), network exposure function (NEF), charging function (CHF), network function repository function (NRF), policy control function (PCF), unified data management function (UDM) 134, application function (AF), service management function, authentication server function (AUSF), access and mobility management function (AMF), session management function (SMF), gateway (GW) and service control function.

[0121] As an example, the blockchain data query method provided in this application can be applied to an operator network scenario, where a blockchain network is formed between CHFs of different operators in the operator network scenario. Each CHF can be used as a full node or a light node in the blockchain network.

[0122] Among them, the CHF as a light node does not store the complete data of the event, and the CHF as a full node stores the complete data of the event. The light node CHF can query the blockchain data of the services related to the user identification card (such as fixed-line telephone, mobile phone, or broadband services) through the full node CHF. For example, the light node CHF can query the full node CHF to obtain broadband billing information.

[0123] It is understandable that the blockchain data query method provided by the present application can also be applied to other blockchain network scenarios. For example, it can also be applied to the Internet of Vehicles scenario, in which a blockchain network is formed between roadside units and roadside units, and between roadside units and vehicle management office servers. Among them, each roadside unit and vehicle management office server can be used as a light node or a full node, which is not limited in this article. The roadside unit as a light node can receive data requests from the Internet of Vehicles device in the vehicle, and initiate corresponding data requests to the full node based on the data request of the Internet of Vehicles device. In one possible implementation, the data of the event stored in the roadside unit or vehicle management office server as a light node or a full node can also include an event type identifier of the event, which is used to indicate the type of the event. Among them, the roadside unit or the vehicle management office server can define the distinguishing features between different types of events based on different regional locations, which is not limited in this article.

[0124] As an example, in the blockchain data query method provided by this application, a structural model of the event data stored by the light node and the full node can be as follows: Figure 2A shown.

[0125] In a blockchain network, one transaction corresponds to one block, and one transaction corresponds to one or more events.

[0126] like Figure 2A As shown, in the structural model corresponding to the full node, the labels "#102", "#103", and "#104" are the indexes of each block stored in the full node. In one possible implementation, the data stored in each block includes the block hash and transaction hash corresponding to the transaction, and the transaction hash includes a summary hash (also called a root hash). According to the classification of different events in the transaction, the summary hash can correspond to two secondary hashes, and each secondary hash corresponds to multiple events. In the full node, the data of each event corresponding to the secondary hash includes the index of the event (index) and the event itself (event).

[0127] In the structural model corresponding to the light node, the labels "#102", "#103", and "#104" are the indexes of each block stored in the light node, where the data stored in each block includes the block hash and transaction hash corresponding to the transaction, and the transaction hash includes the summary hash.

[0128] In one possible implementation, the data of a transaction stored in the light node is stored in the summary hash, and in the embodiment of the present application, the light node also stores the secondary hash corresponding to the summary hash of the event, and the data of multiple events corresponding to the secondary hash. Unlike the full node, the data of each event corresponding to the secondary hash includes the index of the event and the relevant hash of the event. In one possible implementation, the relevant hash of the event can be the hash value of the event, and in some other possible implementations, the relevant hash of the event can be the sum of the hash value of the event and the hash values ​​of other events that are earlier than the event.

[0129] In a possible implementation, a data model for representing query conditions can be defined in light nodes and full nodes, and the data model can include one or more of the following: the time range of the event, the value range of one or more numerical parameters of the event, and one or more non-numeric parameters of the event. As an example, the data model is {T, V, W}, including three types of parameters, where T is a timestamp, V is a numerical parameter, and W is a non-numeric parameter. V and W can be arrays, for example, V is an array including the value ranges corresponding to one or more numerical parameters, and W is an array including the values ​​corresponding to one or more non-numeric parameters. Among them, the non-numeric parameters of the event included in W can include the operation type of the event (operater type), the contract name, etc. For example, when the non-numeric parameters of the event included in W have the operation type of the event, the value of the event operation type can be: Register, Delete.

[0130] As an example, the query condition can be expressed as: {<t1,t2> , [<v1,v2> ,...],[w1,...]}, where<t1,t2> is the time range condition for the query.<v1,v2> is the value range condition of one of the numeric parameters, w1 is the value of one of the non-numeric parameters, for example, the numeric parameter is the identifier of the event, and the non-numeric parameter is the operation type of the event. The query condition can be expressed as: {[2022 / 06 / 18,2022 / 07 / 18],[id>107953],[Operater type==Register&Delete]}. A data request containing the query condition is sent to the full node, and the full node sends a request result to the light node based on the data request. For example, the request result can be {r, zkproof}, where r is the event set that meets the query condition, and zkproof is the proof information generated based on the zero-knowledge proof function. In one possible implementation, when the light node wants to query all the data in the blockchain network, the value of each of the conditions T, V, and W included in the query condition can be null.

[0131] In a possible implementation, the data of the events stored by the full node and the light node also include a pointer to the next event of the same type (for example, the next event is an event that occurs before the current event).

[0132] For example, Figure 2B As shown, two adjacent events of the same type in the full node establish an association relationship through pointers. When the full node searches for data, it can first determine whether each type of event has features that contradict the query conditions. If so, it can directly skip the traversal query task for events of this type, thereby improving query efficiency.

[0133] Based on the application environment of the blockchain data query method provided by the present application as described above, and the structural model of the event data stored in the light node and the full node, the following is combined with Figure 3 The method flow chart shown introduces the blockchain data query method provided by this application.

[0134] like Figure 3 As shown, the blockchain data query method includes:

[0135] S301, the light node sends a data request to the full node, where the data request includes query conditions.

[0136] Accordingly, the full node receives the data request.

[0137] In a possible implementation, the query condition includes at least one of the following: a time range of the event, a value range of one or more numerical parameters of the event, and one or more non-numerical parameters of the event.

[0138] The time of the event may include the time of occurrence of the event and / or the blockchain time of the event. For example, in the query condition, the time range condition of the event may be later than June 18, 2022 and earlier than July 18, 2022.

[0139] The numerical parameter of the event may include one or more items such as the event ID, transaction amount, number of visits, etc. For example, when the numerical parameter of the event includes the event ID in the query condition, the value or value range condition of the event ID may be: id>107953.

[0140] Non-numeric parameters of an event may include the operation type of the event, contract name, etc.

[0141] As an example, the light node can present (display) a query page to the user based on the above data model o, and receive the query content input by the user through the query page to determine the above query conditions.

[0142] The light node will store the address of at least one full node in the blockchain network, for example, the address of a full node that is closer to the light node. After generating a data request based on the query conditions, the light node will send the data request to a random full node among the at least one full node.

[0143] S302, the full node determines a first event set based on the data request, where the first event set is a set of blockchain events that meet the query conditions.

[0144] In an embodiment of the present application, the number of blockchain events included in the first event set is greater than or equal to 0.

[0145] In some possible implementations, among the blockchain event data stored in the full node, data of events of the same type are associated with each other through pointers. Exemplarily, among the blockchain events stored in the full node, different events corresponding to the same event type identifier are sequentially ordered through pointers in chronological order.

[0146] As an example, when a full node performs a data query based on a query condition, it can first determine whether the value of the parameter in the prerequisite of an event identified by a certain event type meets the value condition of the corresponding parameter in the query condition. If it is consistent, it can further traverse the corresponding type event in the order of the pointer to find the event that meets the query condition to obtain the above-mentioned first event set. Among them, the prerequisite of an event identified by a certain event type refers to the condition that all events of this type meet, and the specific value of the parameter in the prerequisite corresponding to each type of event is related to the basis for event classification. Exemplarily, the parameters in the prerequisite corresponding to any type of event may include one or more of the following: the time parameter of the event, one or more numerical parameters of the event, and one or more non-numerical parameters of the event. For example, the basis for classification between events includes the operation type parameter of the event, and the event whose operation type parameter value is 'registration' belongs to type A event, then the prerequisite corresponding to the time of type A includes the value of the operation type parameter as registration.

[0147] Exemplary, multiplexing Figure 2BDifferent skip list sequences are established in the full node based on different event types. When synchronizing blockchain data, the full node will store a pointer to the next event of the same event type and whose blockchain time is earlier than the current event in the data of an event. For example, the event types may include three types: A, B, and C. Correspondingly, the full node stores skip list sequences corresponding to the three types A, B, and C. The full node can search for events that meet the above query conditions from the skip list sequences corresponding to A, B, and C in parallel based on the query conditions to obtain the above first event set. Among them, if the value of the parameter in the prerequisite of a certain type of event is inconsistent with the value of the corresponding parameter in the query condition, the traversal query process for the event of this type can be skipped. For example, the value of the a parameter in the prerequisite of the A type event and the value of the a parameter in the query condition are mutually exclusive, then it is determined that all events of type A do not meet the query condition, and the traversal query of the event of type A is skipped.

[0148] Among them, different types of events may be related to scenario parameters of specific application scenarios, or one or more of the above numerical parameters, or one or more of the non-numerical parameters. For example, in the CHF scenario, different event types may be defined based on different data service charging functions and different regional locations.

[0149] Based on this, when a full node performs data query based on the skip list sequence and query conditions, it can skip irrelevant events and quickly access data of a certain type of event to improve query efficiency.

[0150] In some other possible implementations, the full node further determines a second event set based on the above data request, where the second event set is a collection of blockchain events that meet the time range condition in the above query condition.

[0151] In some possible implementations, in the data of blockchain events stored in the light node, data of events of the same type are associated with each other through pointers. Exemplarily, in the data of blockchain events stored in the light node, data of different events corresponding to the same event type identifier are sequentially established through pointers in chronological order. It should be noted that in addition to establishing an association relationship between events of the same type through pointers in light nodes and full nodes, an association relationship between events of the same type can also be established through other alternative appropriate methods, such as by storing data of events of the same type in the same storage area or the same database, or by using a table, to establish an association relationship between events of the same type, which is not limited in this article.

[0152] S303, the full node generates proof information based on the above first event set.

[0153] In a possible implementation, the full node directly proves that the first event set is credible based on the first event set. Specifically, the full node generates the above-mentioned proof information based on the first event set, the sum of the hash values ​​of all events in the first event set, and the zero-knowledge proof function. Wherein, when the number of events included in the first event set is greater than or equal to 1, the full node can generate proof information based on the zero-knowledge proof function, at least one event in the first event set, and the sum of the hash values ​​of all events in the first event set. When the number of events included in the first event set is equal to 0, the full node can generate proof information based on the zero-knowledge proof function, the first event set whose set is empty, and the sum of the hash values ​​of all events in the first event set (the hash of the first event set whose set is empty).

[0154] As an example, the full node stores the specific content of each event but does not store the hash value corresponding to each event. The full node can obtain the hash value corresponding to each event in the first event set by calculation, and then add the hash value of each event in the first event set to obtain the sum of the hash values ​​of all events in the first event set, so as to generate proof information based on the sum of the hash values ​​of all events in the first event set.

[0155] In some other possible implementations, the full node indirectly proves that the first event set is credible by proving that the second event set is credible, the query condition in the above data request includes the time range of the event, the second event set is a set of blockchain events that meet the time range condition, and the first event set is included in the second event set. Wherein, the number of blockchain events included in the second event set is greater than or equal to 0. When the query condition of the data request only includes the time range condition, or the number of blockchain events included in the second event set is equal to 0, the second event set is the same as the first event set.

[0156] Specifically, in step S303, the full node generates the proof information based on the above-mentioned first event set, including: the full node generates the above-mentioned proof information based on the second event set. As an example, the full node can generate the above-mentioned proof information based on the zero-knowledge proof function, the second event set, and the sum of the hash values ​​of all events in the second event set. Wherein, when the number of events included in the second event set is greater than or equal to 1, the full node can generate the above-mentioned proof information based on the zero-knowledge proof function, at least one event in the second event set, and the sum of the hash values ​​of all events in the second event set. When the number of events included in the second event set is equal to 0, the full node can generate the above-mentioned proof information based on the zero-knowledge proof function, the second event set whose set is empty, and the sum of the hash values ​​of all events in the second event set (the hash of the second event set whose set is empty).

[0157] It is understandable that if the second event set is credible, then the first event set included in the second event set must also be credible. If the second event set is not credible, it means that the whole node is not credible, and the first event set must also be not credible. Based on this, the whole node can prove that the first event set with a smaller scope is credible by proving that the second event set is credible, and because the first event set is derived from the second event set, the credibility of the result data can be further improved by proving that the data source with a larger scope is credible to prove that the first event set with a smaller scope is credible.

[0158] S304, the full node sends a request result to the light node, where the request result includes proof information and a first event set.

[0159] Accordingly, the light node receives the request result.

[0160] In an embodiment of the present application, the first event set is used to refer to all events that meet the query conditions. The full node sends the first event set to the light node, which can be sent in the form of an array or a collection, etc., which is not limited in this document.

[0161] S305, the light node verifies whether the first event set is credible based on the proof information.

[0162] In a possible implementation, the full node in step S303 directly proves that the first event set is credible based on the first event set, and the above request result in step S304 also includes first index information. The first index information includes the index corresponding to each event in the first event set, and the data of each event stored in the light node includes the index and the hash value of the event corresponding to the index. For example, the light node stores a second corresponding relationship, which is the corresponding relationship between the index of the event and the hash value of the event.

[0163] Specifically, after receiving the request result, the light node can determine the hash value of each event in the first event set based on the first index information and the second corresponding relationship, and verify whether the first event set is credible based on the first event set, the sum of the hash values ​​of all events in the first event set, the above-mentioned proof information, and the verification function in the zero-knowledge proof protocol. Among them, the hash value of the blockchain event is determined based on the homomorphic hash function. Among them, if the number of events included in the first event set is greater than or equal to 1, the light node can verify whether the first event set is credible based on at least one event in the first event set, the sum of the hash values ​​of all events in the first event set, the above-mentioned proof information, and the verification function in the zero-knowledge proof protocol. If the number of events included in the first event set is equal to 0, the light node can verify whether the first event set is credible based on the first event set with an empty set, the sum of the hash values ​​of all events in the first event set (the hash value of the first event set with an empty set), the above-mentioned proof information, and the verification function in the zero-knowledge proof protocol.

[0164] In a possible implementation, the light node can determine whether the first event set is credible by using the verification equation f(H,zkproof,r)=0 in the zero-knowledge proof. Wherein, H is the sum of the hash values ​​of all events in the first event set, zkproof is the proof information corresponding to the first event set, and r is the first event set. If the operation result of equation f is 0, it means that the first event set is credible, and if the operation result of equation f is not 0, it means that the first event set is not credible.

[0165] In some other possible implementations, if the full node indirectly proves that the first event set is credible by proving that the second event set is credible, the above request result also includes the second event set. After the light node receives the request result, it verifies whether the second event set is credible based on the second event set, the sum of the hash values ​​of all events in the second event set, and the above proof information. Among them, if the number of events included in the second event set is greater than or equal to 1, the light node can verify whether the second event set is credible based on at least one event in the second event set, the sum of the hash values ​​of all events in the second event set, the above proof information, and the verification function in the zero-knowledge proof protocol. If the number of events included in the second event set is equal to 0, the light node can verify whether the second event set is credible based on the second event set with an empty set, the sum of the hash values ​​of all events in the second event set (the hash value of the second event set with an empty set), the above proof information, and the verification function in the zero-knowledge proof protocol.

[0166] As an example, the above request result also includes second index information, which includes the index corresponding to each event in the second event set, and the light node stores the hash value of each event (such as the above second correspondence). After receiving the above request result, the light node can determine the hash value corresponding to each event in the second event set based on the second index information and the second correspondence, so as to calculate the sum of the hash values ​​of all events in the second event set, and then verify whether the second event set is credible based on the sum of the hash values ​​of all events in the second event set.

[0167] As another example, the above request result also includes a first index and a second index, the first index is the index of the earliest event in the second event set, the second index is the index of the latest event in the second event set, and the light node stores a first corresponding relationship, which is the corresponding relationship between the index of the event and the hash sum. Specifically, the hash sum corresponding to the reference index recorded in the first corresponding relationship is: the sum of the hash value of the reference event corresponding to the reference index and the hash values ​​of other events earlier than the reference event. Therefore, after the light node receives the request result, it can determine the sum of the hash values ​​of all events in the second event set based on the first index, the second index, and the first corresponding relationship, and then verify whether the second event set is credible based on the sum of the hash values ​​of all events in the second event set. Among them, in order to make the event corresponding to a certain time in the second event set unique, the time of the above event can refer to the blockchain time of the event. In some other possible implementations, if the full node can also uniquely determine an event based on the time when an event occurs, the time of the event can also refer to the time when the event occurs. The description of the time of the event elsewhere in this article can refer to the description here.

[0168] The following combination Figure 4 Introduce how the light node determines that the second event set is credible based on the first index and the second index, such as Figure 4 As shown:

[0169] The above step S304 is specifically as follows: the light node receives the request result, which includes the first event set, the second event set, the first index, the second index, and the proof information, and the proof information corresponds to the second event set.

[0170] The above step S305 specifically includes:

[0171] S3051: Determine the sum of hash values ​​of all events in the second event set based on the first corresponding relationship, the first index, and the second index.

[0172] S3052: Determine whether the second event set is credible based on the sum of the hash values ​​of all events in the second event set, the second event set, and a verification function of the zero-knowledge proof.

[0173] There are two ways (method 1 and method 2) to determine the sum of the hash values ​​of all events in the second event set in S3051.

[0174] Mode 1: S30511, based on the first corresponding relationship and the first index, determine the hash sum corresponding to the previous index of the first index in time sequence and the second hash sum corresponding to the second index. S30512, use the difference between the second hash sum and the first hash sum as the sum of the hash values ​​of all events in the second event set.

[0175] For example, the result of the above request can be: {r, e, zkproof, [n1, n2]}, where r is the first event set, e is the second event set, zkproof is the proof information, n1 is the first index, and n2 is the second index. The sum of the hash values ​​of all events in the second event set is hash [event.n1 + (event.n1 + 1) + ... + (event.n2)], event.n1 refers to the event corresponding to index n1, hash (event.n1) refers to the hash value of the event corresponding to n1, and based on the properties of homomorphic hashing, the following equation can be obtained:

[0176] hash[event.n1+(event.n1+1)+...+(event.n2)]

[0177] =hash(event.n1)+hash(event.n1+1)+…+hash(event.n2)

[0178] Assuming that the difference between two adjacent indexes in the complete index sequence is i, and n1 is not the starting index in the complete index sequence, the sum of the hash values ​​of all events in the second event set (H) satisfies the following formula 1, where index.(n1-1) is the first hash sum and index.n2 is the second hash sum.

[0179] H=hash[event.n1+(event.n1+1)+...+(event.n2)]

[0180] =hash(event.n1)+hash(event.n1+1)+…+hash(event.n2)

[0181] =index.n2-index.(n1-i) (Formula 1)

[0182] For example, if the first index is the third index in the complete index sequence, and the second index is the fifth index, then the sum of the hash values ​​of all events in the second event set of the request result (G) is the sum of the events corresponding to the third index, the fourth index, and the fifth index, that is, H = hash(3) + hash(4) + hash(5). The hash sum corresponding to the third index is index3 = hash(1) + hash(2) + hash(3), where hash(1) is the hash value of the event corresponding to the first index, the hash sum corresponding to the previous index of the third index in time sequence is index2 = hash(1) + hash(2), and the hash sum corresponding to the fifth index is index5 = hash(1) + hash(2) + hash(3) + hash(4) + hash(5), so H = index5 - index2 = hash(3) + hash(4) + hash(5).

[0183] Method 2: The request result also includes the hash value of the event corresponding to the first index (target hash value). S3051 specifically includes: S30513, based on the first corresponding relationship and the first index, determining the third hash sum corresponding to the first index and the second hash sum corresponding to the second index; S30514, taking the difference between the second hash sum and the third hash sum and the sum of the target hash value as the sum of the hash values ​​of all events in the second event set.

[0184] Exemplarily, the hash value (target hash value) hash (event.n1) of the event corresponding to the first index is denoted as h, and the sum of the hash values ​​of all events in the second event set (H) satisfies the following formula 2, where the third hash sum is index.n1.

[0185] H=hash[event.n1+(event.n1+1)+...+(event.n2)]

[0186] =hash(event.n1)+hash(event.n1+1)+…+hash(event.n2)

[0187] =index.n2-index.n1+h (Formula 2)

[0188] For example, if the first index is the third index in the complete index sequence, and the second index is the fifth index, then the sum of the hash values ​​of all events in the second event set of the request result (G) is the sum of the hash values ​​of the event corresponding to the third index, the event corresponding to the fourth index, and the event corresponding to the fifth index, that is, H = hash(3) + hash(4) + hash(5), and the target hash value in the request result is hash(3). The hash sum corresponding to the third index stored at the light node is index3 = hash(1) + hash(2) + hash(3), and the hash sum corresponding to the fifth index is index5 = hash(1) + hash(2) + hash(3) + hash(4) + hash(5), so H = index5-index3 + hash(3) = hash(3) + hash(4) + hash(5).

[0189] In the embodiment of the present application, the method of determining the sum of the hash values ​​of all events in the second event set based on the first index and the second index (that is, the above-mentioned method 1 and method 2) is applicable to the scenario where the number of events included in the second event set is greater than or equal to 2. Among them, the first index in the above-mentioned method 1 is not the starting index in the second event set, that is, method 1 is applicable to the scenario where the first index is not the starting index in the second event set.

[0190] In an embodiment of the present application, the light node determines the sum of the hash values ​​of all events in the second event set based on the difference between the second hash sum and the first hash sum, which can effectively reduce the time complexity of the calculation.

[0191] In an embodiment of the present application, when the second event set contains only one event, that is, the number of events contained in the second event set is equal to 1, the request result may not include an index, but instead include a hash value of only the one event contained in the second event set. After the light node receives the request result, it can determine whether the second event set is credible based on the hash value of the one event, the specific event content of the one event, and the verification function in the zero-knowledge proof protocol.

[0192] In addition, if the first index is the starting index in the index sequence, the sum of the hash values ​​of all events in the second event set is the second hash sum. Alternatively, the sum of the hash values ​​of all events in the second event set can also be obtained based on the above method 2.

[0193] It should be noted that Formula 1 in Mode 1 or Formula 2 in Mode 2 may also be modified accordingly to obtain other suitable calculation methods for determining the sum of the hash values ​​of all events in the second event set, which is not limited herein.

[0194] In a possible implementation, the light node can determine whether the second event set is credible by the verification equation f(H,zkproof,e)=0 in the zero-knowledge proof. Among them, H is the sum of the hash values ​​of all events in the second event set, zkproof is the proof information corresponding to the second event set, and e is the second event set. If the calculation result of equation f is 0, it means that the second event set is credible (that is, the first event set is credible), and if the calculation result of equation f is not 0, it means that the second event set is not credible (that is, the first event set is not credible).

[0195] In the embodiment of the present application, if the light node verifies whether the first event set is credible based on the proof information, the first event set is used as the request result of the above data request. If the light node verifies that the first event set is untrustworthy based on the proof information, the light node sends the above data request to another full node until the credible query data is obtained.

[0196] In one possible implementation, the time range condition included in the above query condition is any moment starting from the first moment, the above data request is a subscription type data request, and step S304, the light node receives the request result from the full node, including: after the light node sends a subscription type data request to the full node once, the light node continues to receive the request results returned from the full node based on the above data request from the first moment.

[0197] As an example, the above query condition includes the following:<t1,∞> ,<v1,v2> ,w}. Among them,<t1,∞> Indicates that the time range of the query data starts from time point t1 to the future.<v1,v2> is one of the numeric parameter query conditions, and w is one of the non-numeric parameter query conditions.

[0198] In a possible implementation, after receiving the data request of the subscription type once, the full node can periodically send the latest request result that meets the above query conditions to the light node. The cycle duration is designed based on specific needs, for example, it can be one day, two days, etc., which is not limited in this article.

[0199] Alternatively, in some other possible implementations, after the full node queries K blockchain events corresponding to the query conditions, it updates the latest request result to the light node, where K is a positive integer greater than or equal to 1. The specific value of K can be determined based on specific design requirements, and this document does not limit this.

[0200] Based on subscription-type data requests, full nodes will always provide real-time data updates to light nodes, allowing light nodes to continuously obtain data that meets the query conditions without having to repeatedly send query requests, reducing network transmission pressure, reducing query delays, and ensuring that light nodes always obtain the latest data.

[0201] It should be noted that each request result sent by the full node to the light node contains corresponding proof information to ensure the credible query of data. For example, there may be some full nodes that return credible data when sending request results for the first few times, but it may also be a malicious disguise of the full node, or the full node is illegally invaded, so that the request results sent by the full node later are malicious attack data. Therefore, the request results contain proof information every time, which can ensure that the light node can realize the credible query of data.

[0202] In one possible implementation, after generating a data subscription type data request, the light node will randomly select a full node and send the data request to the selected full node. After receiving the data request, the full node starts to query the data. The full node retrieves data from its synchronized blockchain data and matches events that meet the conditions based on numerical and non-numerical parameter query conditions. In addition, the full node will continue to monitor events in the newly generated blockchain data. Once a new event that meets the conditions is generated, the full node will return the query results to the light node, and the light node will complete the data verification.

[0203] In one possible implementation, the light node may choose to send a subscription-type data request to the full node only when it determines that all request results previously sent by the full node are credible (it can also be understood that the first event set carried in the previously received request results are credible).

[0204] In one possible implementation, while the light node is continuously receiving the request results, after determining that any unreliable request result has been received (which can also be understood as the first event set carried in any of the above request results being unreliable), the light node refuses to receive the request results from the full node.

[0205] In some possible implementations, the stored blockchain events in full nodes and light nodes are divided into at least two different types of events based on the different prerequisites of different types of events.

[0206] In some possible implementations, different events in the second event set may be events of the same type or events of different types. The request result includes a second event set and proof information corresponding to the second event set. When the light node determines that the second event set is credible, it determines that the first event set is credible.

[0207] In a scenario where different events in the second event set can be events of the same type or events of different types, different events corresponding to the same event type identifier in the full node can be ordered in time sequence through pointers, and / or, data of different events corresponding to the same event type identifier in the light node can be ordered in time sequence through pointers. In the light node, the data of the event can include a hash value of the event or a hash sum corresponding to an index of the event, and in the full node, the data of the event includes the specific event content of the event.

[0208] As an example, in the case where the two different events in the second event set can be events of the same type or events of different types, and the light node stores the data of the events in the manner of the above-mentioned first corresponding relationship, and the light node establishes a parallel relationship between the data of the same type of events through pointers, the index method in the data of the events stored in the light node and the storage method of the pointer information can be as follows: Figure 5A As shown. Figure 5A In the data, the indexes of data of different types of events are in the same index sequence (for example, including indexes increasing from 1 to 15 in sequence), the types of different events corresponding to different indexes are the same or different, and the hash sum corresponding to each index is the sum of the hash value of the event corresponding to the index and the hash values ​​of other events of the same type or different types that are earlier than the event.

[0209] It should be noted that in Figure 5A In the figure, different arrow types are used to distinguish pointers of different types of events only for the convenience of intuitive description. In actual storage, pointers of different types of events can be distinguished by event type identifiers, pointer identifiers, etc. This article does not limit this.

[0210] In addition, in the embodiment of the present application, the event indicated by the same index stored in the light node and the full node is the same event or the data of the same event. Correspondingly, in the case where different events in the second event set can be events of the same type or events of different types, and the light node stores the data of the event in the manner of the above-mentioned first correspondence (that is, the full node carries the first index and the second index in the request result to indicate the light node to determine the sum of the hash values ​​of all event sets of the second event set), the indexing method and pointer information of the event stored in the full node can also refer to Figure 5A , but unlike the light node, the data of the event corresponding to the index in the full node is not the hash sum, but the specific event content of the event.

[0211] In some other possible implementations, the second event set corresponds to one type of event (or can also be understood as corresponding to one of the event type identifiers), different event type identifiers correspond to different second event sets, and the request result carries multiple second event sets corresponding to different event types and multiple proof information corresponding to each second event set.

[0212] Specifically, the above step S302 (the full node determines the first event set based on the data request) specifically includes: the full node determines the first event set based on the data request, and determines the second event sets corresponding to the X different event type identifiers respectively.

[0213] The types of every two events included in the first event set may be the same or different, and the types of events included in the same second event set are the same. For example, the event types include type A, type B, and type C, X is 3, and the X second event sets include a second event set corresponding to type A, a second event set corresponding to type B, and a second event set corresponding to type C, and the number of events included in each second event set is greater than or equal to 0.

[0214] The above S303 (the full node generates proof information based on the above first event set) specifically includes: the full node generates proof information corresponding to each second event set in the X second event sets based on the X second event sets corresponding to the X different event type identifiers, and determines the first index and the second index corresponding to each second event set.

[0215] As an example, the light node stores event data in the manner of the above-mentioned second correspondence, and the request result in S304 may include: X second event sets, proof information corresponding to each second event set in the X second event sets, event type identifiers corresponding to each second event set, and second index information corresponding to each second event set, where X is the number of different types of events.

[0216] As another example, the light node stores event data in the manner of the above-mentioned first correspondence, and the request result in S304 may include: X second event sets, proof information corresponding to each second event set in the X second event sets, event type identifiers corresponding to each second event set, first indexes corresponding to each second event set, and second indexes corresponding to each second event set, where X is the number of different types of events.

[0217] Correspondingly, in the above step S305, the light node verifies whether the second event set is credible based on the proof information to verify whether the first event set is credible, specifically including: the light node verifies whether each second event set is credible based on the proof information corresponding to each second event set in the above X second event sets to verify whether the first event set is credible.

[0218] As an example, the request result includes the first index, second index, event type identifier, and proof information corresponding to each second event set. The light node can determine the hash sum corresponding to the previous index of the first index of the second event set and the hash sum corresponding to the second index of the second event set based on the event type identifier of each second event set, and then determine the sum of the hash values ​​of all events in the second event set corresponding to each second event set based on the above method 1.

[0219] As an example, the event types include type A, type B, and type C. The request result sent by the full node to the light node can be: "{r,[e A ,Id A ,n A1 ,n A2 ,zkproof A ],[e B ,Id B ,n B1 ,n B2 ,zkproof B ],[e C ,Id C ,n C1 ,n C2 ,zkproof C ]}", where r is the first event set, e is the second event set, and the letter corresponding to the subscript of e is used to distinguish different types of second event sets, n A1 is the first index corresponding to the second event set corresponding to type A, n A2 is the second index corresponding to the second event set corresponding to type A, n B1 、n B2 、n C1 、n c2 The meaning and A1 、n A2 Similar, zkproof A is the proof information corresponding to the second event set of type A, zkproof B 、zkproof C The meaning and zkproof A Similar, Id A 、Id B 、Id CThey are used to identify the event type corresponding to the corresponding second event set. The light node can be based on n A1 、n A2 Based on the above first correspondence, the sum of the hash values ​​of all events in the second event set corresponding to type A is determined, and then based on e A , the sum of the hash values ​​of all events in the second event set (H A ), and zkproof A , by verifying the equation f(H A ,zkproof A ,e A )=0 verifies whether the second event set corresponding to the A type event is credible. By analogy, the light node determines that the first event set is credible when verifying that the second event sets corresponding to the A type event, the B type event, and the C type event are credible.

[0220] When the light node stores event data through the above first correspondence, and the request result includes the above X second event sets, the data of different events corresponding to the same event type identifier in the full node and the light node are associated with each other through pointers in chronological order. As an example, the index and pointer information of different types of events stored in the light node can be stored as follows: Figure 5B or Figure 5C Two different approaches are shown.

[0221] exist Figure 5B In the , the indexes of different types of events correspond to different index sequences, that is, type A, type B, and type C events correspond to different index sequences respectively, and the hash sum corresponding to the index is the sum of the hash value of the event corresponding to the index and the hash values ​​of other events of the same type that are earlier than the event.

[0222] exist Figure 5C In the example, the indexes of different types of events are in the same index sequence, which may include Figure 5C As shown in the indexes from 1 to 15, in the index sequence, the events corresponding to different indexes can be events of the same type or different types, and the hash sum corresponding to the index is the sum of the hash value of the event corresponding to the index and the hash values ​​of other events of the same type that are earlier than the event.

[0223] In addition, in the embodiment of the present application, the event indicated by the same index stored in the light node and the full node is the same event or the data of the same event. Correspondingly, when a second event set corresponds to an event type, and the light node stores the event data in the manner of the above-mentioned first correspondence (that is, the full node carries the first index and the second index in the request result to indicate the light node to determine the sum of the hash values ​​of all event sets of the second event set), the indexing method and pointer information of the event stored in the full node can also refer to Figure 5B or Figure 5C As shown, the only difference from the light node is that the data of the event corresponding to the index in the full node is not the hash sum, but the specific event content of the event.

[0224] In this application, "sending information to... (e.g., a light node)" or the related illustrations in the accompanying drawings can be understood as the destination end of the information being a light node. It can include sending information to a light node directly or indirectly. "Receiving information from... (e.g., a light node)" or "receiving information from... (e.g., a light node)", or the related illustrations in the accompanying drawings can be understood as the source end of the information being a light node, which can include receiving information from a light node directly or indirectly. The information may be processed as necessary between the source end and the destination end of the information transmission, such as format changes, etc., but the destination end can understand the valid information from the source end. Similar expressions in this application can be understood similarly and will not be repeated here.

[0225] It is understandable that the present application uses light nodes and full nodes as examples of the execution subjects of the interactive illustration, but the present application does not limit the execution subjects of the interactive illustration. For example, the light node in the method provided by the present application may also be a chip, chip system, or processor applied to the light node, or a logical node, logic module, or software that can implement all or part of the light node; the full node in the method provided by the present application may also be a chip, chip system, or processor applied to the full node, or a logical node, logic module, or software that can implement all or part of the full node function.

[0226] It can be understood that in the above embodiments, the methods and / or steps implemented by the light node can also be implemented by components that can be used for light nodes (such as chips or circuits); the methods and / or steps implemented by the full node can also be implemented by components that can be used for full nodes (such as chips or circuits).

[0227] The above mainly introduces the scheme provided by the embodiment of the present application from the perspective of interaction between various nodes. Accordingly, the embodiment of the present application also provides a blockchain data query device, which is used to implement the above various methods. The blockchain data query device can be a light node in the above method embodiment, or a component that can be used for a light node; or, the blockchain data query device can be a full node in the above method embodiment, or a component that can be used for a full node. It can be understood that in order to implement the above functions, the blockchain data query device includes a hardware structure and / or software module corresponding to each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0228] The embodiment of the present application can divide the functional modules of the blockchain data query device according to the above method embodiment. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing unit. The above integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0229] Based on the same concept of the above blockchain data query method, this application also provides the following blockchain data query device:

[0230] like Figure 6 As shown, it is a structural schematic diagram of a blockchain data query device provided in an embodiment of the present application, and the blockchain data query device is applied to a light node in a blockchain network, including:

[0231] A sending unit 601 is used to send a data request to all nodes, where the data request includes a query condition;

[0232] A receiving unit 602 is used to receive a request result from the full node, the request result including proof information and a first event set, the first event set being a set of blockchain events that meet the query condition, and the proof information being used to prove that the first event set is credible data that meets the query condition;

[0233] The verification unit 603 is used to verify whether the first event set is credible based on the certification information.

[0234] In a possible implementation, the query condition includes a time range of an event, the request result also includes a second event set, the certification information corresponds to the second event set, the second event set is a set of blockchain events that meet the time range, and the first event set is included in the second event set. The verification unit 603 is specifically used to verify whether the second event set is credible based on the certification information, so as to verify whether the first event set is credible.

[0235] In one possible implementation, the verification unit 603 is specifically used to verify whether the second event set is credible based on the sum of the hash values ​​of all events in the second event set, the second event set, and the proof information, wherein the hash value of the blockchain event is determined based on a homomorphic hash function.

[0236] In a possible implementation, the request result also includes a first index and a second index, a first corresponding relationship is stored in the light node, and the sum of the hash values ​​of all events in the second event set is determined based on the first index, the second index, and the first corresponding relationship.

[0237] In one possible implementation, in the index of blockchain events stored in the above-mentioned blockchain data query device, different indexes of different events corresponding to the same event type identifier are established in chronological order through pointers.

[0238] In a possible implementation, the request result includes: X second event sets, proof information corresponding to each second event set in the X second event sets, event type identifiers corresponding to each second event set, the first index corresponding to each second event set, and the second index corresponding to each second event set, where X is the number of types of events of different types. The verification unit 603 is specifically used by the light node to verify whether each second event set is credible based on the proof information corresponding to each second event set in the X second event sets, so as to verify whether the first event set is credible.

[0239] In a possible implementation, the request result also includes first index information, which includes the index corresponding to each event in the first event set. The light node stores a second correspondence, which is the correspondence between the index of the event and the hash value of the event. The verification unit 603 is specifically used to verify whether the first event set is credible based on the first event set, the sum of the hash values ​​of all events in the first event set, and the proof information.

[0240] In a possible implementation, the above-mentioned blockchain data query device also includes a determination unit 604, which is used to determine the hash value of each event in the first event set based on the first index information and the second correspondence, and determine the sum of the hash values ​​of all events in the first event set based on the hash value of each event in the first event set.

[0241] In a possible implementation, the receiving unit 602 is specifically configured to continuously receive the request result returned from the full node based on the data request after sending the data request of the subscription type to the full node once.

[0242] like Figure 7 As shown, it is a structural schematic diagram of another blockchain data query device provided in an embodiment of the present application, and the blockchain data query device is applied to a full node in a blockchain network, including:

[0243] The receiving unit 701 is configured to receive a data request from a light node, wherein the data request includes a query condition;

[0244] A search unit 702 is used to determine a first event set based on the data request, where the first event set is a set of blockchain events that meet the query condition;

[0245] A generating unit 703, configured to generate certification information based on the first event set, wherein the certification information is used to prove that the first event set is credible;

[0246] The sending unit 704 is used to send a request result to the light node, where the request result includes the certification information and the first event set.

[0247] In a possible implementation, the generating unit 703 is specifically configured to generate proof information based on the second event set, where the proof information is used to prove that the first event set is credible data by proving that the second event set is credible data.

[0248] In a possible implementation manner, the request result also includes a first index and a second index.

[0249] In one possible implementation, among the blockchain events stored in the blockchain data query device, different events corresponding to the same event type identifier are established in chronological order through pointers.

[0250] In a possible implementation, the request result includes: X second event sets, proof information corresponding to each second event set in X second event sets, event type identifiers corresponding to each second event set, a first index corresponding to each second event set, and a second index corresponding to each second event set, wherein the first index is the index of the earliest event in the corresponding second event set, the second index is the index of the latest event in the corresponding second event set, and X is less than or equal to the number of different event types.

[0251] In one possible implementation, the above-mentioned search unit 702 is specifically used to determine a first event type identifier from events with different event type identifiers, the value of the parameter in the prerequisite corresponding to the first event type identifier does not conflict with the value of the corresponding parameter in the query condition, and the prerequisite refers to a condition that is satisfied by every event corresponding to the first event type identifier, and the full node searches for events that satisfy the query condition from one or more events corresponding to the first event type identifier in pointer order to obtain the first event set.

[0252] In a possible implementation, the full node stores an index of each event in the first event set, and the request result also includes first index information, where the first index information includes an index corresponding to each event in the first event set.

[0253] In a possible implementation, the time range condition included in the query condition is any time from the first moment, the data request is a subscription type data request, and the sending unit 704 is specifically used to periodically send the latest request result that meets the query condition to the light node after receiving the data request of the subscription type once; or, the sending unit 704 is specifically used to send the latest request result to the light node after querying K blockchain events corresponding to the query condition, where K is a positive integer greater than or equal to 1.

[0254] It should be noted that Figure 6 and Figure 7 For the explanation of the terms such as query condition, proof information, request result, first index, second index, first corresponding relationship, event type identifier, first event set, second event set, first index information, second corresponding relationship, and subscription type data request, please refer to the relevant instructions in the blockchain data query method above, which will not be elaborated here.

[0255] like Figure 8As shown, it is a schematic diagram of the structure of another blockchain data query device provided in an embodiment of the present application, and the blockchain data query device 800 includes one or more processors 801 (one processor is illustrated in the figure). Optionally, the blockchain data query device 800 may also include a memory 803 (indicated by a dotted line in the figure). The memory 803 is used to store instructions executed by the processor 801, or to store input data required for the processor 801 to run instructions, or to store data generated after the processor 801 runs instructions. Optionally, the blockchain data query device 800 may also include an interface circuit 802 (indicated by a dotted line in the figure), and the processor 801 and the interface circuit 802 are coupled to each other. It can be understood that the interface circuit 802 can be a transceiver or an input-output interface.

[0256] In one possible implementation, the processor 801 can be used to implement the steps or functions performed by the above-mentioned verification unit 603 and / or determination unit 604, and the interface circuit 802 can be used to implement the steps or functions performed by the above-mentioned sending unit 601 and / or receiving unit 602.

[0257] In one possible implementation, the processor 801 can be used to implement the steps or functions performed by the above-mentioned search unit 702 and / or generation unit 703, and the interface circuit 802 can be used to implement the steps or functions performed by the receiving unit 701 and / or sending unit 704.

[0258] The division of modules in this application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional module in each example of this application may be integrated into one processor, or may exist physically separately, or two or more modules may be integrated into one module. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0259] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0260] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction is executed, the method in the above embodiment is implemented.

[0261] The embodiments of the present application also provide a computer program product including instructions, which, when executed on a computer, enables the computer to execute the method in the above embodiments.

[0262] The present application also provides a computer program, which is used to implement the method in the above embodiment.

[0263] The present application also provides a blockchain data query device, including a processor, and the processor is used to execute the method in the above embodiment.

[0264] The present application also provides a blockchain data query system, including a first query device (e.g., a light node) and a second query device (e.g., a full node). The first query device can be used to execute the steps performed by the light node in the method in the above embodiment, and the second query device can be used to execute the steps performed by the full node in the method in the above embodiment.

[0265] An embodiment of the present application also provides a communication system, which may include the above-mentioned blockchain data query device applied to a light node in a blockchain network and the above-mentioned blockchain data query device applied to a full node in a blockchain network.

[0266] The embodiment of the present application also provides a circuit, which is coupled to a memory and is used to execute the method shown in the above embodiment. The circuit may include a chip circuit.

[0267] It should be noted that the above units or one or more of the units can be implemented by software, hardware or a combination of the two. When any of the above units or units is implemented by software, the software exists in the form of computer program instructions and is stored in a memory, and a processor can be used to execute the program instructions and implement the above method flow.

[0268] In this application, the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, or all or part of the circuits in the aforementioned devices for implementing processing functions, which may implement or execute the methods, steps and logic block diagrams disclosed in this application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the method disclosed in this application may be directly embodied as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0269] When the above units or units are implemented in hardware, the hardware can be any one or any combination of a CPU, a microprocessor, a digital signal processing (DSP) chip, a microcontroller unit (MCU), an artificial intelligence processor, an ASIC, a SoC, an FPGA, a programmable logic device (PLD), a dedicated digital circuit, a hardware accelerator or a non-integrated discrete device, which can run the necessary software or not rely on the software to execute the above method flow.

[0270] Optionally, the embodiment of the present application further provides a chip system, including: at least one processor and an interface, the at least one processor is coupled to a memory via the interface, and when the at least one processor runs a computer program or instruction in the memory, the chip system executes a method in any of the above method embodiments. Optionally, the chip system may be composed of a chip, or may include a chip and other discrete devices, which is not specifically limited in the embodiment of the present application.

[0271] The memory in the present application may also be a circuit or any other device capable of implementing a storage function, for storing program instructions and / or data. The memory is any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. For example, the memory may be a non-volatile memory, such as a digital versatile disc (DVD), a hard disk drive (HDD) or a solid-state drive (SSD), etc., or a volatile memory (volatile memory), such as a random-access memory (RAM).

[0272] It should be understood that in the description of the present application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship, for example, A / B can represent A or B; wherein A and B can be singular or plural. Also, in the description of the present application, unless otherwise specified, "multiple" refers to two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, wherein a, b, c can be single or multiple. In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second", etc. are used to distinguish the same items or similar items with substantially the same functions and effects. Those skilled in the art can understand that the words "first", "second", etc. do not limit the quantity and execution order, and the words "first", "second", etc. do not limit them to be necessarily different. Meanwhile, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.

[0273] The "embodiment" mentioned in this document means that the specific features, structures or characteristics described in conjunction with the embodiment can be included in one or more embodiments of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It can be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0274] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using a software program, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loading and executing computer program instructions on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center.

[0275] Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by viewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "one" or "an" does not exclude multiple situations. A single processor or other unit may implement several functions listed in a claim. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

[0276] It is understood that the various numbers involved in the embodiments of the present application are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. The size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic.

[0277] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0278] The components in the device of the embodiment of the present application can be merged, divided and deleted according to actual needs. Those skilled in the art can combine or combine the different embodiments and features of the different embodiments described in this specification.

[0279] In the present application, under the premise of no logical contradiction, the examples may reference each other, for example, the methods and / or terms between method embodiments may reference each other, for example, the functions and / or terms between device embodiments may reference each other, for example, the functions and / or terms between device examples and method examples may reference each other.

Claims

1. A blockchain data query method, characterized in that: Applied to a light node in a blockchain network, the method comprises: The light node sends a data request to the full node, where the data request includes a query condition; The light node receives a request result from the full node, the request result including proof information and a first event set, the first event set being a set of blockchain events that satisfy the query condition, and the proof information being used to prove that the first event set is credible data that satisfies the query condition; The light node verifies whether the first event set is credible based on the proof information.

2. The method according to claim 1, characterized in that The query condition includes at least one of the following: a time range of an event, a value range of one or more numerical parameters of an event, and one or more non-numerical parameters of an event.

3. The method according to claim 1 or 2, characterized in that: The proof information is information obtained based on a zero-knowledge proof protocol.

4. The method according to any one of claims 1 to 3, characterized in that: The query condition includes a time range of an event, the request result also includes a second event set, the proof information corresponds to the second event set, the second event set is a set of blockchain events that meet the time range, and the first event set is included in the second event set. The light node verifies whether the first event set is credible based on the proof information, including: The light node verifies whether the second event set is credible based on the proof information to verify whether the first event set is credible.

5. The method according to claim 4, characterized in that The light node verifies whether the second event set is credible based on the proof information, including: The light node verifies whether the second event set is credible based on the sum of the hash values ​​of all events in the second event set, the second event set, and the proof information, wherein the hash value of the blockchain event is determined based on a homomorphic hash function.

6. The method according to claim 5, characterized in that The request result also includes a first index and a second index, the first index is the index of the earliest event in the second event set, the second index is the index of the latest event in the second event set, and the light node stores a first corresponding relationship, the first corresponding relationship is the corresponding relationship between the index of the event and the hash sum, wherein the hash sum corresponding to the reference index in the first corresponding relationship is: the sum of the hash value of the reference event corresponding to the reference index and the hash values ​​of other events earlier than the reference event, The sum of the hash values ​​of all events in the second event set is determined based on the first index, the second index, and the first corresponding relationship.

7. The method according to claim 6, characterized in that The sum of hash values ​​of all events in the second event set is the difference between a second hash sum and a first hash sum, wherein the first hash sum is the hash sum corresponding to the previous index of the first index in time sequence, and the second hash sum is the hash sum corresponding to the second index.

8. The method according to claim 7, characterized in that In the blockchain event data stored in the light node, the hash sums corresponding to the indexes of different events corresponding to the same event type identifier are established in chronological order through pointers, and the event type identifier is used to indicate the type of event corresponding to the index.

9. The method according to claim 8, characterized in that The request result includes: X second event sets, proof information corresponding to each second event set in X second event sets, event type identifier corresponding to each second event set, the first index corresponding to each second event set, and the second index corresponding to each second event set, where X is the number of types of events of different types. The light node verifies whether the second event set is credible based on the proof information to verify whether the first event set is credible, including: The light node verifies whether each of the second event sets in the X second event sets is credible based on the proof information corresponding to each of the second event sets, so as to verify whether the first event set is credible.

10. The method according to any one of claims 1 to 3, characterized in that: The light node verifies whether the first event set is credible based on the proof information, including: The light node verifies whether the first event set is credible based on the first event set, the sum of hash values ​​of all events in the first event set, and the proof information, wherein the hash value of the blockchain event is determined based on a homomorphic hash function.

11. The method according to claim 10, characterized in that The request result also includes first index information, the first index information includes an index corresponding to each event in the first event set, the light node stores a second corresponding relationship, the second corresponding relationship is a corresponding relationship between the index of the event and the hash value of the event, and before the light node is based on the first event set, the sum of the hash values ​​of all events in the first event set, and the proof information, the method also includes: The light node determines a hash value of each event in the first event set based on the first index information and the second corresponding relationship, and determines a sum of hash values ​​of all events in the first event set based on the hash value of each event in the first event set.

12. The method according to any one of claims 1 to 11, characterized in that: The time range condition included in the query condition is any time from the first time, the data request is a subscription type data request, and the result of the request received by the light node from the full node includes: After the light node sends the data request of the subscription type to the full node once, the light node continues to receive the request result returned by the full node based on the data request.

13. A blockchain data query method, characterized in that: Applied to a full node in a blockchain network, the method comprises: The full node receives a data request from a light node, where the data request includes a query condition; The full node determines a first event set based on the data request, where the first event set is a set of blockchain events that meet the query condition; The full node generates certification information based on the first event set, where the certification information is used to prove that the first event set is credible; The full node sends a request result to the light node, where the request result includes the proof information and the first event set.

14. The method according to claim 13, characterized in that The query condition includes at least one of the following: a time range of an event, a numerical parameter of an event, and a non-numerical parameter of an event.

15. The method according to claim 13 or 14, characterized in that The query condition includes a time range of an event, the request result also includes the second event set, the second event set is a set of blockchain events that meet the time range, the first event set is included in the second event set, and the full node generates proof information based on the first event set including: The full node generates proof information based on the second event set, where the proof information is used to prove that the first event set is credible data by proving that the second event set is credible data.

16. The method according to claim 15, characterized in that The proof information is generated based on a zero-knowledge proof function, a sum of hash values ​​of all events in the second event set, and the second event set.

17. The method according to claim 16, characterized in that The request result also includes a first index and a second index, wherein the first index is the index of the earliest event in the second event set, and the second index is the index of the latest event in the second event set.

18. The method according to any one of claims 13 to 17, characterized in that: Among the blockchain events stored in the full node, different events corresponding to the same event type identifier are established in a chronological order through pointers.

19. The method according to claim 18, characterized in that The request result includes: X second event sets, proof information corresponding to each second event set in X second event sets, event type identifier corresponding to each second event set, a first index corresponding to each second event set, and a second index corresponding to each second event set, wherein the first index is the index of the earliest event in the corresponding second event set, the second index is the index of the latest event in the corresponding second event set, and X is less than or equal to the number of types of different event types.

20. The method according to claim 18 or 19, characterized in that The full node determines a first event set based on the query condition, including: The full node determines a first event type identifier from events with different event type identifiers, the value of a parameter in a prerequisite corresponding to the first event type identifier meets the value condition of the corresponding parameter in the query condition, and the prerequisite refers to a condition that is satisfied by each event corresponding to the first event type identifier; The full node searches for events that meet the query condition from events corresponding to the first event type identifier in pointer order to obtain the first event set.

21. The method according to claim 13 or 14, characterized in that The proof information is generated based on a zero-knowledge proof protocol, a sum of hash values ​​of all events in the first event set, and the first event set.

22. The method according to claim 21, characterized in that The full node stores the index of each event in the first event set, and the request result also includes first index information, which includes the index corresponding to each event in the first event set.

23. The method according to any one of claims 13 to 22, characterized in that: The time range condition included in the query condition is any time from the first time, the data request is a subscription type data request, and the full node sends the request result to the light node including: After receiving the data request of the subscription type once, the full node periodically sends the latest request result that meets the query condition to the light node; or, After querying K blockchain events corresponding to the query condition, the full node sends the latest request result to the light node, where K is a positive integer greater than or equal to 1.

24. A blockchain data query device, characterized in that: Comprising means for performing the method as claimed in any one of claims 1 to 23.

25. A blockchain data query device, characterized in that: The device comprises a processor, wherein the processor is used to read and execute a computer program stored in a memory to implement the method according to any one of claims 1 to 23.

26. The device according to claim 25, characterized in that Also included is the memory.

27. A blockchain data query system, characterized in that: The system comprises a first query device and a second query device, wherein the first query device is used to execute the method according to any one of claims 1 to 12, and the second query device is used to execute the method according to any one of claims 13 to 23.

28. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store a computer program, and when the computer program is executed, the method according to any one of claims 1 to 23 is performed.

Images