Block chain information query method and device, electronic equipment and readable medium

Abstract

The invention provides a block chain information query method and device, electronic equipment and a readable medium. The method comprises the steps of obtaining a query request of block chain information, wherein the query request comprises query condition information; target historical result information matched with the query condition information is queried from a historical result set, the historical result set comprises multiple pieces of historical result information, and each piece of historical result information corresponds to one piece of historical query condition information; the historical result information is generated according to the historical query condition information, the corresponding historical query result and the effective state information; according to the effective state information of the target historical result information, determining the effective state of a historical query result in the target historical result information at the current moment; and if the effective state of the historical query result at the current moment is effective, generating a target query result of the query request according to block chain information in the historical query result. According to the method, read-write blockage caused by bottom layer read-write of the node can be avoided.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device, and readable medium for querying blockchain information. Background Art

[0002] A blockchain network is typically a distributed network of computers running software that verifies blocks and transactions, known as nodes. This software must be running on a computer to transform it into a blockchain node. A node typically consists of one or more clients. Users use these clients to access data stored on the blockchain node.

[0003] In related technologies, the client can be implemented in a variety of forms or programming languages, all of which can provide users with various services for querying on-chain data. Users access the server provided by the client through an application to read and write data in the blockchain.

[0004] However, in this type of solution, when the client faces high-frequency query demands or a large number of queries in a short period of time, the application will repeatedly trigger the client to execute blockchain read transactions, which will put great pressure on the node's underlying read and write or cause read and write blockages, affecting the node's reading and writing of the blockchain world state or causing the node to be unable to normally participate in the content required by the consensus protocol, affecting the stability of the blockchain node operation. Summary of the Invention

[0005] Based on the above technical problems, the present application provides a method, device, electronic device and readable medium for querying blockchain information to avoid causing great pressure on the underlying reading and writing of the node or causing read and write blockage, thereby improving the stability of the operation of the blockchain node.

[0006] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by practice of the present application.

[0007] According to one aspect of an embodiment of the present application, a method for querying blockchain information is provided, comprising:

[0008] Obtaining a query request for blockchain information, wherein the query request includes query condition information;

[0009] Querying a historical result set for target historical result information that matches the query condition information, wherein the historical result set includes multiple historical result information, each historical result information corresponds to a historical query condition information, and the historical result information is generated based on the historical query condition information, the corresponding historical query result, and the effective status information;

[0010] Determining the current validity status of the historical query result in the target historical result information according to the validity status information of the target historical result information;

[0011] If the historical query result is valid at the current moment, the target query result of the query request is generated according to the blockchain information in the historical query result.

[0012] According to one aspect of an embodiment of the present application, a device for querying blockchain information is provided, comprising:

[0013] A request acquisition module configured to obtain a query request for blockchain information, wherein the query request includes query condition information;

[0014] an information query module configured to query a historical result set for target historical result information that matches the query condition information, wherein the historical result set includes a plurality of historical result information, each historical result information corresponds to a piece of historical query condition information, and the historical result information is generated based on the historical query condition information, the corresponding historical query result, and the effective status information;

[0015] a state determination module configured to determine the current validity state of the historical query result in the target historical result information according to the validity state information of the target historical result information;

[0016] The result generation module is configured to generate a target query result of the query request based on the blockchain information in the historical query result if the validity status of the historical query result at the current moment is valid.

[0017] In some embodiments of the present application, based on the above technical solution, the information query module is further configured as follows: if the effective status of the historical query result at the current moment is invalid or there is no target historical result information matching the query condition information, then according to the query condition information, the blockchain information corresponding to the query condition information is obtained from the blockchain to obtain the target query result; according to the query condition information and the target query result, the corresponding historical result information is added to the historical result set.

[0018] In some embodiments of the present application, based on the above technical solution, the query condition information includes a smart contract address and request contract parameters; the information query module is specifically configured to: execute a query through a smart contract according to the smart contract address and the request contract parameters to obtain an execution query result; in the process of executing the query, obtain a blockchain message generated when executing the query, wherein the blockchain message includes a target account for calling the message when calling the smart contract to execute the query; and use the execution query result and the blockchain message as the target query result.

[0019] In some embodiments of the present application, based on the above technical solution, the information query module is specifically configured to: generate a contract address set according to the target account in each blockchain message; obtain the target block height of the block in the blockchain that contains the execution query result; generate corresponding historical result information according to the contract address set, the query condition information, the execution query result and the target block height and add it to the historical result set, wherein the contract address set is used to retrieve the historical result information according to the target account, and the target block height is used to indicate the effective start block of the historical result information.

[0020] In some embodiments of the present application, based on the above technical solution, the query request also includes a specified block height; the status determination module is specifically configured to: obtain the starting block height and ending block height of the effective status information in the target historical result information; if the specified block height is less than the starting block height and greater than the ending block height, it is determined that the effective status of the historical query result at the current moment is valid.

[0021] In some embodiments of the present application, based on the above technical solution, the information query module is further configured to: if the effective status of the historical query result at the current moment is invalid, then according to the query condition information, obtain the blockchain information corresponding to the query condition information from the blockchain to obtain the target query result; according to the target query result, update the historical query result in the target historical result information; and update the effective status of the target historical result information to valid.

[0022] In some embodiments of the present application, based on the above technical solution, the blockchain information query device further includes:

[0023] A block acquisition module, configured to acquire a block to be uploaded to the blockchain containing transactions to be uploaded to the blockchain;

[0024] a history query module configured to query, from the historical result set, historical result information to be updated associated with each transaction smart contract invoked by the transaction to be on-chain in the block to be on-chain;

[0025] The status update module is configured to update the validity status information of the historical result information to be updated to an invalid status.

[0026] In some embodiments of the present application, based on the above technical solution, the historical query result includes a historical contract address, which is the address of the smart contract called when querying the historical query result; the historical query module is specifically configured to: obtain the smart contract address called by each to-be-chained exchange in the to-be-chained block, and obtain a calling address set; for each smart contract address in the calling address set, obtain the historical query result containing the smart contract address in the historical contract address from the historical result set, and obtain the historical query result to be updated.

[0027] In some embodiments of the present application, based on the above technical solution, the historical query module is specifically configured to: when executing each transaction to be on the chain in the block to be on the chain, obtain the contract call message generated after executing each transaction to be on the chain, and obtain a call message set, wherein each contract call message contains the target account of the message; according to the target account of each contract call message, the contract call messages in the call message set are merged and deduplicated; obtain the target account of each remaining contract call message in the call message set to obtain a call address set.

[0028] In some embodiments of the present application, based on the above technical solution, the status update module is specifically configured to: obtain the block height of the block to be chained in the blockchain; and update the end block height in the effective status information of the historical result information to be updated according to the block height of the block to be chained.

[0029] In some embodiments of the present application, based on the above technical solution, the information query module is further configured to: obtain blockchain information corresponding to the historical query condition information in the historical result information to be updated from the blockchain to obtain an updated query result; add corresponding historical result information to the historical result set based on the historical query condition information, the updated query result and the block height of the block to be chained in the blockchain.

[0030] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute a method for querying blockchain information as in the above technical solution by executing the executable instructions.

[0031] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, a method for querying blockchain information as in the above technical solution is implemented.

[0032] According to one aspect of an embodiment of the present application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain information query method provided in the various optional implementations described above.

[0033] In an embodiment of the present application, the query conditions and query results will be saved in a historical result set. When processing a query request, the historical result information that matches the query condition information is first queried from the historical result set. If there is a currently valid historical query result, the target query result of the query request is directly generated based on the blockchain information in the historical query result. By searching for the target result from the saved query results, the query result can be directly obtained when triggering the execution of blockchain read and write transactions, thereby avoiding causing greater pressure on the underlying read and write of the node or causing read and write blocking, and thus will not affect the node's reading and writing of the blockchain world state, ensuring that the node can normally participate in the content required by the consensus protocol, which is conducive to improving the stability of the blockchain node operation.

[0034] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0036] Figure 1 It is a system architecture for a query solution applied to blockchain information according to an embodiment of the present application.

[0037] Figure 2 This is a schematic diagram of the blockchain network in an embodiment of the present application.

[0038] Figure 3 This is a schematic diagram of blocks in a blockchain network in an embodiment of the present application.

[0039] Figure 4 Flowchart of a method for querying blockchain information according to an embodiment of the present application.

[0040] Figure 5 Flowchart of a method for querying blockchain information according to an embodiment of the present application.

[0041] Figure 6 Flowchart of a method for querying blockchain information according to an embodiment of the present application.

[0042] Figure 7 Flowchart of a method for querying blockchain information according to an embodiment of the present application.

[0043] Figure 8 This is a schematic flowchart of the blockchain node query process based on parameter cache reading and writing in an embodiment of the present application.

[0044] Figure 9 This is a schematic flowchart of the cache dynamic update process in an embodiment of the present application.

[0045] Figure 10 The block diagram schematically shows the composition of the query device for blockchain information in an embodiment of the present application.

[0046] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0047] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art.

[0048] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner.In the following description, many specific details are provided so as to provide a full understanding of the embodiments of the present application. However, it will be appreciated by those skilled in the art that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps etc. can be adopted. In other cases, known methods, devices, implementations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

[0049] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0050] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0051] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0052] It should be understood that the solution of this application can be applied in scenarios where users access blockchain clients through applications to query blockchain information. Specifically, blockchains contain various types of nodes, including full nodes, archive nodes, and light nodes. This application uses full nodes as an example. Full nodes verify the blockchain block by block, including downloading and verifying the block body and state data of each block. Therefore, full nodes store all blockchain data and can retrieve all states from local storage. Full nodes provide services to the network and provide data upon user request. Users access full node clients through applications to obtain data query services.

[0053] A blockchain network is typically a distributed network of computers running software that verifies blocks and transactions, known as nodes. This software must be running on a computer to transform it into a blockchain node. A node typically consists of one or more clients. Users use these clients to access data stored on the blockchain node.

[0054] In related technologies, the client can be implemented in a variety of forms or programming languages, all of which can provide users with various services for querying on-chain data. Users access the server provided by the client through an application to read and write data in the blockchain.

[0055] However, in this type of solution, when the client faces high-frequency query demands or a large number of queries in a short period of time, the application will repeatedly trigger the client to execute blockchain read transactions, which will put great pressure on the node's underlying read and write or cause read and write blockages, affecting the node's reading and writing of the blockchain world state or causing the node to be unable to normally participate in the content required by the consensus protocol, affecting the stability of the blockchain node operation.

[0056] Based on this, the technical solution of the embodiment of this application proposes a query solution for blockchain information. Specifically, Figure 1As shown, the system architecture 100 for a blockchain information query solution according to an embodiment of the present application may include a terminal device 110, a network 120, and a server 130. Terminal device 110 may include a smartphone, tablet computer, laptop computer, intelligent voice interaction device, smart home appliance, vehicle-mounted terminal, aircraft, and the like. Server 130 may be a server that provides various services. It may be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Network 120 may be a communication medium of various connection types capable of providing a communication link between terminal device 110 and server 130, such as a wired communication link or a wireless communication link.

[0057] Depending on implementation needs, the system architecture in the embodiments of this application can include any number of terminal devices, networks, and servers. For example, server 130 can be a server group consisting of multiple server devices. Furthermore, the technical solutions provided in the embodiments of this application can be applied to terminal device 110, server 130, or implemented jointly by terminal device 110 and server 130, without any specific limitation in this application. In the embodiments of this application, terminal device 110 is installed with an application for querying blockchain data, while server 130 is a node in the blockchain. Server 130 is installed with two blockchain node clients: an execution client and a consensus client. The execution client, also known as the execution engine, is responsible for acquiring blockchain transactions broadcasted within the blockchain network, executing the resulting transactions, and maintaining the latest state of the current blockchain data and database. The consensus client is responsible for participating in the consensus voting process with other nodes. In the solution of this application, terminal device 110 requests data from server 130. Upon request from terminal device 110, server 130, using the solution described in this application, retrieves the data requested by terminal device 110 from its locally stored data and provides it to terminal device 110.

[0058] Server 130 is a blockchain node in the blockchain. A blockchain is a peer-to-peer distributed ledger comprised of multiple nodes. Each node contains a record of all transactions, and all nodes are required to verify each transaction. Each node in a blockchain network can be either a full node or a local blockchain node. A full node can connect to other nodes, while a local blockchain node is an independent node running within the blockchain and is not connected to other nodes. A local blockchain node does not participate in the blockchain network's consensus mechanism like a full node, but it can independently verify transactions and create new blocks. Only the first node can decrypt the confidential information sent by the second node to the first node, thereby obtaining the content and enabling confidential communication between the two nodes.

[0059] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain is essentially a decentralized database, a string of data blocks (i.e., blocks) generated by cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block. The blockchain is maintained by the nodes in the blockchain network. For example, in Figure 2 The blockchain network shown may include multiple nodes 201, which may be the individual clients that form the blockchain network. Each node 201 may receive input information during normal operation and, based on the received input information, maintain shared data within the blockchain network. To ensure information interoperability within the blockchain network, information connections may exist between each node in the blockchain network, allowing nodes to transmit information through these connections. For example, when any node in the blockchain network receives input information, the other nodes in the blockchain network obtain the input information according to a consensus algorithm and store it as shared data, ensuring that the data stored on all nodes in the blockchain network is consistent.

[0060] Each node in a blockchain network has a corresponding node identifier, and each node in the blockchain network can store the node identifiers of other nodes so that it can subsequently broadcast generated blocks to other nodes in the blockchain network based on the node identifiers of other nodes. Each node can maintain a node identifier list, storing the node name and node identifier in the node identifier list. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node.

[0061] Each node in the blockchain network stores the same blockchain. The blockchain consists of multiple blocks, see Figure 3As shown in the figure, the blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information feature value, version number, timestamp, and difficulty value, etc., and the block body stores the input information. The next block of the genesis block uses the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature value of the current block, the block header feature value, version number, timestamp, and difficulty value of the parent block, etc., and so on. Therefore, the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0062] The following is a detailed description of the implementation details of the technical solution of the embodiment of the present application: Figure 4 The flowchart of the method for querying blockchain information according to one embodiment of the present application is shown. The method for querying blockchain information is applied to blockchain nodes and can be executed by a device with computing and processing functions, such as a server or terminal device where the blockchain full node is located. Figure 4 As shown, the blockchain information query method includes at least steps S410 to S440, which are described in detail as follows:

[0063] Step S410: Obtain a query request for blockchain information, where the query request includes query condition information.

[0064] In this embodiment, query requests are typically initiated by users through applications to query the required data within the blockchain. In a specific embodiment, the blockchain node appears to the user as a node gateway. Users initiate calls to the node gateway's query interface via network requests, and the node gateway then invokes the node's virtual machine to execute the request. The blockchain node will... Users enter query criteria based on their needs. Query criteria information is descriptive information used to query blockchain information, including the query criteria and other supplementary information. For example, if the blockchain information being queried is related to a smart contract within the blockchain, the query request typically specifies the smart contract as the query target. The query criteria information will also include smart contract information, such as the smart contract's contract address and the target interface to be invoked.

[0065] Step S420, query the target historical result information that matches the query condition information from the historical result set, wherein the historical result set contains multiple historical result information, each historical result information corresponds to a historical query condition information, and the historical result information is generated based on the historical query condition information, the corresponding historical query result and the effective status information.

[0066] The blockchain node searches the historical result set for target historical result information that matches the query condition information. The historical result set is data stored locally on the blockchain node, such as in a local cache database. The historical result set contains multiple historical result information, generated based on historical query requests executed by the blockchain node. Each historical result information corresponds to a single historical query condition information. Depending on the specific implementation, the relationship between historical result information and historical query condition information can be one-to-one or many-to-one. For example, the relationship between historical result information and historical query condition information can be unique, meaning that different historical query condition information will uniquely correspond to one historical result information and, therefore, only one historical query result. However, if the relationship between historical result information and historical query condition information is many-to-one, different historical result information can correspond to the same historical query condition information. For example, historical result information from different periods of the blockchain can be stored as different data entries in the historical result set. However, these historical result information from different periods of time all correspond to the same historical query condition information because they were all obtained by executing queries based on the same historical query condition information. Historical result information is generated based on historical query condition information, the corresponding historical query results, and validity status information. The historical query results are the blockchain information retrieved from the blockchain based on the historical query condition information, while the validity status information indicates whether the historical query results in the historical result information are valid at the current moment—that is, whether the blockchain information in the historical query results is consistent with the data in the current blockchain. Validity status information is generally categorized as valid or invalid. Validity status information changes based on blockchain data updates. For example, when data in the historical query results is updated, the validity status information is set to invalid. In some embodiments, the historical query results in the historical result information are updated based on blockchain data updates; the validity status of such historical result information remains valid. The validity status information itself can be a valid or invalid flag, or it can specify the validity range of the historical query results, such as validity within a specific time period or within a specific block range.

[0067] Step S430: Determine the current validity status of the historical query result in the target historical result information according to the validity status information of the target historical result information.

[0068] Based on the validity status information of the target historical result information, the blockchain node determines the current validity status of the historical query results in the target historical result information. Since the blockchain node stores the historical query results locally in the target historical result information, it needs to confirm whether the data in the historical query results is still valid at the current time. If the data is valid, it means that the data involved has not changed from the time the historical query results were retrieved to the current time. In other words, the historical query result is still the correct result corresponding to the query conditions in the query request. If the data is invalid, it means that the data in the historical query results has changed in the blockchain and needs to be queried again. The specific method for determining the current validity status of the historical query results based on the validity status information depends on the specific form of the validity status information. For example, if the validity status information is a flag, the flag content can be directly read. However, if the validity status information is a time range or a specified block range, a comparison and judgment based on the current time or the current block status in the blockchain is required.

[0069] Step S440: If the historical query result is valid at the current moment, a target query result of the query request is generated based on the blockchain information in the historical query result.

[0070] If the historical query result's validity status at the current moment is valid, it indicates that the historical query result is the query result of the query request. Therefore, the blockchain generates the target query result for the query request based on the blockchain information in the historical query result. For example, the blockchain node repackages the blockchain information in the historical query result into response information corresponding to the query request and feeds this response information back to the requester of the query request. In other embodiments, the blockchain node further processes the blockchain information in the historical query result, weighting it according to user-specified parameters, and then generates the target query result for the query request. For example, if a user's account contains 100 virtual resources A and the user queries how many virtual resources B can be obtained by converting these 100 virtual resources A into virtual resources B, and the current conversion ratio is 1 to 5, the blockchain node will read the blockchain information in the historical query result to indicate that the user's account contains 100 virtual resources A. It then obtains the current conversion ratio of 1 to 5 from the conversion platform, thereby calculating the target query result as 500 virtual resources B.

[0071] In an embodiment of the present application, the query conditions and query results will be saved in a historical result set. When processing a query request, the historical result information that matches the query condition information is first queried from the historical result set. If there is a currently valid historical query result, the target query result of the query request is directly generated based on the blockchain information in the historical query result. By searching for the target result from the saved query results, the query result can be directly obtained when triggering the execution of blockchain read and write transactions, thereby avoiding causing greater pressure on the underlying read and write of the node or causing read and write blocking, and thus will not affect the node's reading and writing of the blockchain world state, ensuring that the node can normally participate in the content required by the consensus protocol, which is conducive to improving the stability of the blockchain node operation.

[0072] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown are as follows Figure 5 As shown, in a method for querying blockchain information in one embodiment of the present application, the solution of the present application may include the following steps:

[0073] Step S510: Obtain a query request for blockchain information, where the query request includes query condition information.

[0074] Optionally, the implementation details of step S510 are the same as Figure 4 The step S410 shown in FIG is the same as that in FIG, and will not be repeated here.

[0075] Step S520, query the target historical result information that matches the query condition information from the historical result set, wherein the historical result set contains multiple historical result information, each historical result information corresponds to a historical query condition information, and the historical result information is generated based on the historical query condition information, the corresponding historical query result and the effective status information.

[0076] Optionally, the implementation details of step S520 are the same as Figure 4 The step S420 shown in FIG is the same as that in FIG, and will not be repeated here.

[0077] Step S530: Determine the current validity status of the historical query result in the target historical result information according to the validity status information of the target historical result information.

[0078] Optionally, the implementation details of step S530 are the same as Figure 4 The step S430 shown in FIG is the same as that in FIG, and will not be repeated here.

[0079] If the current validity status of the historical query result is valid, step S540 is executed. If the current validity status of the historical query result is invalid or there is no target historical result information matching the query condition information, step S550 is executed.

[0080] Step S540: Generate a target query result of the query request based on the blockchain information in the historical query result.

[0081] Optionally, the implementation details of step S540 are the same as Figure 4 The step S440 shown in FIG is the same as that in FIG, and will not be repeated here.

[0082] Step S550: Obtaining blockchain information corresponding to the query condition information from the blockchain according to the query condition information to obtain a target query result;

[0083] Step S560: Add corresponding historical result information to the historical result set according to the query condition information and the target query result.

[0084] In this embodiment, if the current validity status of a historical query result is invalid or no target historical result information matching the query criteria exists, the blockchain node cannot retrieve the target query result from its locally cached data. Therefore, the blockchain node retrieves the blockchain information corresponding to the query criteria from the blockchain to obtain the target query result. Specifically, the blockchain node invokes the corresponding smart contract method or interface based on the query request to execute the query. The blockchain node's local virtual machine executes the invoked method and reads from the node data, obtaining the blockchain information that meets the query criteria as the target query result. The target query result is provided to the requester of the query request. After obtaining the target query result, the blockchain node further updates its local cache based on the target query result. Specifically, the blockchain node adds the corresponding historical result information to the historical result set based on the query criteria and the target query result. The validity status of this newly added historical result information is set to valid, so that when the user provides the same query criteria, the target query result is directly retrieved from the cache. The requested query is executed only when there is no corresponding target query result in the local cache, and the target query result obtained by executing the query is saved to the local cache, thereby reducing the number of times local node data is read in the data query, thereby reducing the occupation of the read and write resources of the blockchain node, which is conducive to improving the read and write efficiency of the blockchain node.

[0085] In an embodiment of the present application, the query conditions and query results will be saved in a historical result set. When processing a query request, the historical result information that matches the query condition information is first queried from the historical result set. If there is a currently valid historical query result, the target query result of the query request is directly generated based on the blockchain information in the historical query result. By searching for the target result from the saved query results, the query result can be directly obtained when triggering the execution of blockchain read and write transactions, thereby avoiding causing greater pressure on the underlying read and write of the node or causing read and write blocking, and thus will not affect the node's reading and writing of the blockchain world state, ensuring that the node can normally participate in the content required by the consensus protocol, which is conducive to improving the stability of the blockchain node operation.

[0086] In some optional embodiments of the present application, based on other technical solutions of the present application, the query condition information includes a smart contract address and request contract parameters. In the process of obtaining the target query result by obtaining blockchain information corresponding to the query condition information from the blockchain based on the query condition information, the blockchain node executes the query through the smart contract based on the smart contract address and the request contract parameters, obtaining the query result. During the query execution process, the blockchain message generated during the query execution is obtained, wherein the blockchain message includes the target account of the message invoked when the smart contract is invoked to execute the query. The query result and the blockchain message are then used as the target query result. In this embodiment, the query request includes the smart contract address to be queried and the request contract parameters. The smart contract address is the address of the smart contract to be invoked, and the request contract parameters are information that identifies the information to be queried. Based on the smart contract address and the request contract parameters, the blockchain node invokes the query method in the smart contract, inputting the request contract parameters as function parameters, to obtain the query result. During the query process, the blockchain node obtains messages from all contract calls involved in the query execution. These messages can be proactively output to the blockchain node through the query execution function by pre-integrating information output functions into the execution logic. The output data primarily includes the target account in the blockchain message that invokes the smart contract to execute the query. This target account typically corresponds to the address of the smart contract being invoked. In some embodiments, the blockchain message also includes the initiating account and message data of the smart contract invoking the query. By capturing the blockchain message of the smart contract invoking the query during the query execution process and incorporating the target query results, a more comprehensive collection of smart contracts involved in the query process is achieved, covering inter-contract and cross-contract calls during the execution process, thereby improving the data integrity of the query results.

[0087] In some optional embodiments of the present application, based on other technical solutions of the present application, in the process of adding corresponding historical result information to the historical result set based on the query condition information and the target query result, the blockchain node generates a contract address set based on the target account in each blockchain message, then obtains the target block height of the block in the blockchain containing the execution query result, and then generates corresponding historical result information based on the contract address set, the query condition information, the execution query result, and the target block height and adds it to the historical result set, wherein the contract address set is used to retrieve the historical result information based on the target account, and the target block height is used to indicate the effective start block of the historical result information. In this embodiment, the blockchain node extracts the target accounts in all blockchain messages and forms an array of the union as a contract address set, and then constructs the historical result information based on the format of the historical query results in the historical result set. The historical result information will at least include the contract address set, the query condition information, the execution query result, and the target block height. The contract address set and query condition information are used to retrieve historical result information, while the target block height typically identifies the effective range of the historical result information, meaning that the historical result information becomes effective starting from the target block height. In an embodiment of the present application, historical result information is constructed using the target account in the blockchain message as the contract address. This allows the historical result information to include the address of each associated smart contract, which facilitates the accuracy of the mapping relationship between query results and related smart contracts.

[0088] In some optional embodiments of the present application, based on other technical solutions of the present application, the query request further includes a specified block height. When determining the current validity status of the historical query result in the target historical result information based on the validity status information of the target historical result information, the blockchain node obtains the starting block height and ending block height of the validity status information in the target historical result information. If the specified block height is less than the starting block height and greater than the ending block height, the validity status of the historical query result is determined to be valid at the current time. In this embodiment, the query request specifies the block height where the data to be queried is located. The validity status information in the historical result information also includes the starting block height and ending block height, which indicate the valid block range of the historical query result in the blockchain. After the blockchain node finds the target historical result information with the same query conditions, it further determines whether the target historical result information is valid at the current time based on whether the specified block height is between the starting block height and the ending block height. In some embodiments, the starting block height and the ending block height form a valid interval that is closed on the left and open on the right. As long as the specified block height is within this interval, the historical query result is valid. In another embodiment, the ending block height is set to a null value to indicate that the historical query result is still valid in the latest block in the blockchain. In this case, it is sufficient to compare whether the specified block height is higher than the starting block height. It is understood that in this embodiment, the specified block height can also specify the block in which the query result is located. For example, if there is no corresponding historical query result in the local cache, when executing the query, the blockchain node will determine the query result based on the blockchain state at the specified block height, rather than the state in the latest block. This allows users to retrieve smart contract query results for the blockchain state at a specific block in the past. The specified block height can be left blank to indicate that the current state of the latest block is used. In this embodiment, by determining the validity of historical query results based on the specified block height in the query request and the starting block height and ending block height of the valid state information in the target historical result information, query results based on the historical state of the blockchain can be queried, which helps to increase the diversity of query content.

[0089] In some optional embodiments of the present application, based on other technical solutions of the present application, during the process of adding corresponding historical result information to a historical result set based on query condition information and a target query result, if the historical result set does not exist, the blockchain node first creates a historical result cache in the node gateway and then obtains the block height corresponding to the block in the blockchain containing the target query result. The blockchain node creates historical result information corresponding to the query request based on the block height, query condition information, parameters generated during the process of obtaining the target query result, the address of the invoked smart contract, and the target query result, where the historical result information conforms to the result set structure. Finally, the blockchain node writes the historical result information to the historical result cache, resulting in a historical result set. Specifically, when a blockchain node is newly started or before executing a query for the first time, it typically does not directly create a historical result set in the cache. Therefore, if the historical result set does not exist, the blockchain node first creates a historical result set in the cache. The blockchain node then creates a historical result cache in the node gateway according to the result set structure. The node gateway is a node device used for communication between the node in the blockchain and the requester of the query request. The node gateway can be considered part of the blockchain node. The historical result cache typically allocates cache space within the node gateway of a blockchain node. In one specific embodiment, the node gateway is a remote procedure call gateway, through which the blockchain node communicates with the requester. The blockchain node creates the historical result set in the node's remote procedure call gateway cache. In some embodiments, the newly created historical result cache only contains various data storage structures established or declared according to the result set structure, but does not contain actual data. For example, the blockchain node will allocate a certain amount of cache space as specified in the result set structure and create data structures such as stacks, queues, linked lists, or arrays within the cache to store data. The result set structure typically specifies the data types required for each historical result message in the set, as well as the corresponding data types and constraints for each data type. In one example, a historical result message includes a start block, an end block, query input, a process contract, and a query result. For newly created historical result messages, the end block is typically empty. The blockchain node retrieves the corresponding data according to the structure. Specifically, the blockchain node obtains the block height corresponding to the block in the blockchain containing the target query result as the information corresponding to the start block. The query input corresponds to the query condition information, while the process contract corresponds to the union array of call addresses extracted from all blockchain messages during the process of obtaining the target query result, which usually contains the addresses of all called smart contracts. The query result corresponds to the target query result.Based on the information obtained, the blockchain node will construct historical result information that conforms to the result set structure and write the historical result information to the historical result cache, completing the establishment of the historical result set. In an embodiment of the present application, by creating a historical result cache in the node gateway, the query request parameters, process parameters, result parameters and other information are cached in the node gateway. Therefore, the blockchain node does not need to repeatedly execute repeated large queries under high-frequency queries, and directly feedback the query results based on the data cached by the node gateway, which is conducive to improving query performance.

[0090] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown are as follows Figure 6 As shown, in a method for querying blockchain information in one embodiment of the present application, the query condition information includes a smart contract address and request contract parameters. The solution of the present application may include the following steps:

[0091] Step S610: Obtain a query request for blockchain information, where the query request includes query condition information.

[0092] Optionally, the implementation details of step S610 are the same as Figure 4 The step S410 shown in FIG is the same as that in FIG, and will not be repeated here.

[0093] Step S620, query the target historical result information that matches the query condition information from the historical result set, wherein the historical result set contains multiple historical result information, each historical result information corresponds to a historical query condition information, and the historical result information is generated based on the historical query condition information, the corresponding historical query result and the effective status information.

[0094] Optionally, the implementation details of step S620 are the same as Figure 4 The step S420 shown in FIG is the same as that in FIG, and will not be repeated here.

[0095] Step S630: Determine the current validity status of the historical query result in the target historical result information according to the validity status information of the target historical result information.

[0096] Optionally, the implementation details of step S630 are the same as Figure 4 The step S430 shown in FIG is the same as that in FIG, and will not be repeated here.

[0097] If the validity status of the historical query result at the current moment is valid, step S640 is executed; if the validity status of the historical query result at the current moment is invalid, step S650 is executed.

[0098] Step S640: Generate a target query result of the query request based on the blockchain information in the historical query result.

[0099] Optionally, the implementation details of step S640 are the same as Figure 4 The step S440 shown in FIG is the same as that in FIG, and will not be repeated here.

[0100] Step S650: Obtaining blockchain information corresponding to the query condition information from the blockchain according to the query condition information to obtain a target query result;

[0101] Step S660: updating the historical query results in the target historical result information according to the target query result;

[0102] Step S670: Update the validity status of the target historical result information to valid.

[0103] In this embodiment, if the current validity status of a historical query result is invalid or no target historical result information matching the query criteria exists, the blockchain node cannot retrieve the target query result from its locally cached data. Therefore, the blockchain node retrieves the blockchain information corresponding to the query criteria from the blockchain to obtain the target query result. Specifically, the blockchain node invokes the corresponding smart contract method or interface based on the query request to execute the query. The blockchain node's local virtual machine executes the invoked method and reads from the node data, obtaining blockchain information matching the query criteria as the target query result. The target query result is then provided to the requester of the query. After obtaining the target query result, the blockchain node further updates the expired data in its local cache based on the target query result. Specifically, the blockchain node updates the historical query result in the target historical result information based on the target query result. Since the current validity status of the historical query result is invalid, indicating that the historical query result in the target historical result information does not match the current blockchain data, the blockchain node replaces the historical query result in the target historical result information with the target query result. Subsequently, the blockchain node updates the validity status of the target historical result information to valid. For example, this can be done by updating a marker or updating the validity period, depending on how the validity status information is represented. When the locally cached data becomes invalid, a query is first executed, and then the invalid data in the local cache is updated to valid data based on the query results. This allows for timely updates to the data in the local cache. Furthermore, compared to dedicated query and update processes, updating the local cached data along with the user's query request does not require an additional query process, reducing the consumption of read and write resources on the blockchain node.

[0104] In an embodiment of the present application, the query conditions and query results will be saved in a historical result set. When processing a query request, the historical result information that matches the query condition information is first queried from the historical result set. If there is a currently valid historical query result, the target query result of the query request is directly generated based on the blockchain information in the historical query result. By searching for the target result from the saved query results, the query result can be directly obtained when triggering the execution of blockchain read and write transactions, thereby avoiding causing greater pressure on the underlying read and write of the node or causing read and write blocking, and thus will not affect the node's reading and writing of the blockchain world state, ensuring that the node can normally participate in the content required by the consensus protocol, which is conducive to improving the stability of the blockchain node operation.

[0105] In the embodiments of the present application, it is also proposed to Figure 4 Other embodiments that refine the technical solution of the embodiment shown are as follows Figure 7 As shown, in a method for querying blockchain information in one embodiment of the present application, the solution of the present application may include the following steps:

[0106] Step S710: Obtain a query request for blockchain information, where the query request includes query condition information.

[0107] Optionally, the implementation details of step S710 are the same as Figure 4 The step S410 shown in FIG is the same as that in FIG, and will not be repeated here.

[0108] Step S720, query the target historical result information that matches the query condition information from the historical result set, wherein the historical result set contains multiple historical result information, each historical result information corresponds to a historical query condition information, and the historical result information is generated based on the historical query condition information, the corresponding historical query result and the effective status information.

[0109] Optionally, the implementation details of step S720 are the same as Figure 4 The step S420 shown in FIG is the same as that in FIG, and will not be repeated here.

[0110] Step S730: Determine the current validity status of the historical query result in the target historical result information according to the validity status information of the target historical result information.

[0111] Optionally, the implementation details of step S730 are the same as Figure 4 The step S430 shown in FIG is the same as that in FIG, and will not be repeated here.

[0112] Step S740: If the historical query result is valid at the current moment, a target query result of the query request is generated based on the blockchain information in the historical query result.

[0113] Optionally, the implementation details of step S740 are the same as Figure 4 The step S440 shown in FIG is the same as that in FIG, and will not be repeated here.

[0114] Step S750: Obtain the block to be uploaded containing the transaction to be uploaded;

[0115] Step S760: According to the transaction smart contract called by each transaction to be on-chain in the block to be on-chained, query the historical result information to be updated associated with the transaction smart contract from the historical result set;

[0116] Step S770: Update the validity status information of the historical result information to be updated to an invalid status.

[0117] In this embodiment, when a blockchain node is performing the on-chain or verification process for a pending block, it updates the validity status of historical result information in its cache based on the pending transactions in the pending block. Specifically, the blockchain node obtains the pending block containing the pending transaction. This pending block can be a block generated by the node itself or a message received from another node requesting verification of a new block. The blockchain node can update the data in its local cache while processing the pending block, for example, during or after verifying or executing the pending transactions in the pending block. Based on the transaction smart contract invoked by each pending transaction in the pending block, the blockchain node queries the historical result set for the historical result information associated with the transaction smart contract to be updated. Specifically, the historical result set queries for historical result information that invoked the transaction smart contract or for historical result information related to accounts involved in the transaction smart contract. For the historical result information associated with the pending transaction, the blockchain node updates its validity status to invalid. In this way, after the block to be chained is uploaded, the data in the associated historical result information in the local cache is inconsistent with the data in the blockchain, but its status is also updated to invalid. Subsequent query requests will find that the query results in the local cache are invalid, and the query process will be re-executed to obtain the latest query result data. By updating the validity status information of the historical result information in the local cache based on the content of the block to be chained, the blockchain node can promptly mark the invalid query results, thereby ensuring the accuracy of the query results obtained from the local cache.

[0118] In some optional embodiments of the present application, based on other technical solutions of the present application, the historical query result includes a historical contract address, which is the address of the smart contract invoked when querying the historical query result. In the process of querying the historical result set for the historical result information to be updated associated with the transaction smart contract invoked by each transaction to be on-chain in the block to be on-chain, the blockchain node obtains the smart contract address invoked by each transaction to be on-chain in the block to be on-chain, and obtains a call address set. For each smart contract address in the call address set, the blockchain node obtains the historical query result containing the smart contract address from the historical result set, and obtains the historical query result to be updated. In this embodiment, the blockchain node compares the smart contract address invoked by each transaction to be on-chain with the historical contract address in the historical query result. If the historical contract address in the historical query result matches the smart contract address in the historical result set, it indicates that the historical query result is the historical result information to be updated associated with the transaction smart contract. By matching the smart contract address called by the historical query results with the smart contract address called by each exchange to be on-chain, the historical query results to be updated are determined, so that all historical query results involved in the block to be on-chain can be quickly determined. Compared with searching based on the affected data, the amount of processing resources required for the retrieval process can be reduced, thereby improving processing efficiency.

[0119] In some optional embodiments of the present application, based on other technical solutions of the present application, in the process of obtaining the smart contract address called by each transaction to be on-chain in the block to be on-chain and obtaining a call address set, when executing each transaction to be on-chain in the block to be on-chain, the blockchain node will obtain the contract call message generated after executing each transaction to be on-chain, obtaining a call message set, wherein each contract call message contains the target account of the message. Then, based on the target account of each contract call message, the contract call messages in the call message set are merged and deduplicated, and the target accounts of the remaining contract call messages in the call message set are obtained to obtain a call address set. In this embodiment, the contract call messages are deduplicated based on the target account. Specifically, the union of all contract call messages can be taken, and the duplicate smart contract addresses in the call message set can be removed to obtain the set of contracts whose states have changed in the blockchain, i.e., the call address set. In this way, when processing each address in the call address set, the additional read and write volume caused by duplicate addresses can be reduced, further reducing resource consumption during cache updates.

[0120] In some optional embodiments of the present application, based on other technical solutions of the present application, in the process of updating the effective status information of the historical result information to be updated to an invalid state, the blockchain node will obtain the block height of the block to be chained in the blockchain, and then update the end block height in the effective status information of the historical result information to be updated according to the block height of the block to be chained. In this embodiment, by updating the end block height in the effective status information of the historical result information to be updated to the block height of the block to be chained, the effective status of the historical result information to be updated is made to last until the block to be chained, that is, after the block to be chained is chained, the historical result information to be updated changes from valid to invalid, thereby avoiding hitting expired cache data when searching the cache, and ensuring the timeliness and accuracy of the retrieval results.

[0121] In some optional embodiments of the present application, based on other technical solutions of the present application, the blockchain node further retrieves blockchain information corresponding to the historical query condition information from the blockchain based on the historical query condition information in the historical result information to be updated, obtains an updated query result, and then adds the corresponding historical result information to the historical result set based on the historical query condition information, the updated query result, and the block height of the block to be uploaded to the blockchain. In this embodiment, the blockchain node re-executes the query based on the historical query condition information in the historical result information and updates the result to the historical result set. This ensures that the query results obtained based on the latest blockchain state search are available in the cache. In some embodiments, the blockchain node filters the historical query condition information to be updated based on conditions such as the frequency, number of times, or priority of the historical query condition information being called. Only historical query condition information with a usage frequency exceeding a certain threshold will be re-queried and updated after a new block is uploaded to the blockchain, thereby ensuring efficient use of blockchain node resources. By updating the query results stored in the cache based on the latest state of the uploaded block, the accuracy of the query results in the cache can be ensured, query result errors can be avoided, and the stability of the solution can be improved.

[0122] The following is an example of the implementation details of the technical solution of the embodiment of the present application: Figure 8 , Figure 8 This is a schematic flow chart of the blockchain node query process based on parameter cache reading and writing in the embodiment of this application. Figure 8 As shown in the figure, in this process, the blockchain full node serves the user as a node RPC gateway, which is used to accept the user's Web3 query request, execute the read query of the blockchain VM virtual machine at the bottom layer, and finally return the result. Figure 8There are two users who use Web3 service queries. In some embodiments, one user may also initiate two queries. The user will initiate a Web3 query, that is, request the Web3 query interface of the blockchain node, and initiate a query such as "eth_call". This query only queries the status of the smart contract on the blockchain and does not change the world state of the blockchain. The blockchain VM virtual machine is the module that actually runs blockchain smart contract transactions and maintains the blockchain world state data. When executing a query, a query message set will be generated. It is a message set of all contract calls involved in the query on the blockchain node. The result of the query will be written to the parameter cache. The parameter cache is a cache module that actually caches the query parameters, process parameters, and return parameters of the Web3 query. The whole query process mainly includes 5 steps. Step 1 is to initiate a query. When user A uses a Web3 application on the blockchain, he initiates a Web3 query to the blockchain node through the Web3 client and sends the following information to the Web3 service gateway:

[0123] Web3_REQ=(eth_call,<BlockNum,ContractAddr,Input> )

[0124] Among them, Web3_REQ refers to the request data submitted by the user to the Web3 service gateway, ContractAddr is the smart contract address, and Input is the function and input parameters of the requested contract. It is worth noting that BlockNum is optional in traditional blockchain clients, that is, the user can choose to return the smart contract query result of the status of a certain block in the past history, or leave it blank, which means that the current latest block is used. Step 2 is to execute the query. In this step, it is assumed that the system does not contain any cache when it is newly started, so the transaction of the query still needs to be executed. When the virtual machine executes, this technology will perform stubs and track all internal messages involved in its eth_call transaction, which is called the query message set:

[0125] RETURN,Msgs=EXEC(ContractAddr,Input)

[0126] Msg i =<From,To,Data>

[0127] Among them, EXEC function is the function executed by the virtual machine, RETURN is the execution query result, Msgs is the query message set, which consists of several query messages Msg, Msg iThis represents the virtual machine message generated during the i-th query. This technology instrumentates it as a tuple consisting of three elements: the message's initiating account, the message's target account, and the message's data. In this technology, the simplest setup only uses the To field, while the From and Data fields can be expanded as needed.

[0128] Step 3 is to return the result and write the parameter cache. After the virtual machine is executed, the result will be returned to the node gateway, which will then forward it to the user.

[0129] Web3_RESP=RETURN

[0130] The node gateway then writes the query into the parameter cache. Specifically, the node gateway constructs the parameters generated during the query, the parameters of the query request, and the parameters obtained from the query into a parameter cache element, which can be a row in a data table, as follows:

[0131] Contracts=∪Msg i .To

[0132] Call2return= <BlockNum,NULL,Input,Contracts,RETURN)

[0133] Contracts is an array consisting of the union of the To fields in all Msg messages. NULL indicates a blank field. The semantics of the Call2return elements in the diagram are: start block, end block, query input, process contract, and query result. The cached value of this parameter cache element, Call2return, is then written to any memory-based cache database.

[0134] Step 4 is to initiate a new query. When user B uses a Web3 application on the blockchain, he initiates a Web3 query to the blockchain node through the Web3 client and sends the following information to the Web3 service gateway:

[0135] New_Web3_REQ=(eth_call,<NewBlockNum,ContractAddr,Input> )

[0136] That is, the parameters of New_Web3_REQ and Web3_REQ except NewBlockNum are the same.

[0137] Step 5 is a cache hit. The node initiates a query to the in-memory database of the parameter cache:

[0138] Row=QUERY(“SELECT*WHERE input=Input and contract[0]=ContractAddr”)

[0139] That is, the query is for rows where the input field is consistent with the Input field in the cache, and the contract [0] of the first message is consistent with the ContractAddr. It is understood that the results in such data rows can be used as the query results of New_Web3_REQ when the blockchain data has not been updated.

[0140] After the gateway node obtains the data row, it still needs to make the following judgment on the validity of the data:

[0141] Row.StartBlock≤NewBlockNum<Row.EndBlock

[0142] This means checking whether NewBlockNum in the cache is within the left-closed and right-open interval of the StartBlock and EndBlock blocks. Typically, if the data is the latest valid data, its EndBlock will be null. In this case, only the StartBlock needs to be compared.

[0143] If the judgment is true, the cache hits and the value of Row.return is returned to the new query user. Otherwise, steps 2-3 are executed to execute the query content and obtain the blockchain content.

[0144] See also Figure 9 , Figure 9 This is a schematic flow chart of the cache dynamic update process in the embodiment of this application. Figure 9 As shown in Figure 1, the process mainly involves block packaging or verification, on-chain transaction message set and parameter cache. Among them, the on-chain transaction message set contains all transaction messages of several transactions in the block. Specifically, the process mainly includes three steps. First, the accounting program of the blockchain node (which can be Figure 8 The node gateway or the program on the host where the virtual machine is located) generates a block after packaging itself, or receives a communication packet from an external node and needs to verify a new block, as follows.

[0145] Bbck=<BbckNum,TXs>

[0146] The block bbck is simply represented by the BbckNum block height and its transaction TXs, where TXs contains a total of N blockchain transactions TX.

[0147] The virtual machine will execute the block's transactions or verify the transactions. During the execution of the transaction, the virtual machine will track the internal messages of each transaction and synthesize the message set of all transactions on the chain, as follows

[0148] TXMsgs i =EXEC(TX i )

[0149] TXMsg k =<TXi-j,From,To,Data>

[0150] Similarly, TXMsgs i Represents the internal message set formed after the execution of the i-th TX. Each on-chain transaction will have several internal messages, so after merging, a new internal message set TXMsgs containing all transactions is formed. TXMsg_k represents the k-th TXMsgs, which contains the j-th internal message of transaction i, expressed as TXi-j. The parameters From, To and Data are the same as described above. After obtaining the internal message set, the blockchain node will k The contracts involved in the operation need to mark their expiration time in the cache as follows:

[0151] DeltaContracts=Unique(∪TXMsg k .To)

[0152] First, take the union of all TXMsg, Unique is the deduplication function, that is, remove the repeated contract addresses, and form the contract set DeltaContracts whose status changes in the block, each element of which is represented by DeltaContract i After that, the node traverses each DeltaContract i , set the end block of all caches of affected contracts to the current newly packaged / verified block. In this way, based on the judgment in the above query process, Web3 queries initiated in the block number will not mistakenly hit the old expired cache.

[0153] It should be noted that although the steps of the method of the present application are described in a specific order in the drawings, this does not require or imply that the steps must be performed in this specific order, or that all steps must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0154] The following introduces the device implementation of the present application, which can be used to execute the blockchain information query method in the above embodiment of the present application. Figure 10 The block diagram of the query device for blockchain information in the embodiment of the present application is schematically shown. Figure 10 As shown, the blockchain information query device 1000 may mainly include:

[0155] A request acquisition module 1010 is configured to obtain a query request for blockchain information, wherein the query request includes query condition information;

[0156] An information query module 1020 is configured to query a historical result set for target historical result information that matches the query condition information, wherein the historical result set includes multiple historical result information, each historical result information corresponds to a historical query condition information, and the historical result information is generated based on the historical query condition information, the corresponding historical query result, and the effectiveness status information;

[0157] A state determination module 1030 is configured to determine the current validity state of the historical query result in the target historical result information according to the validity state information of the target historical result information;

[0158] The result generation module 1040 is configured to generate a target query result of the query request based on the blockchain information in the historical query result if the validity status of the historical query result at the current moment is valid.

[0159] In some embodiments of the present application, based on the above technical solution, the information query module 1020 is further configured to: if the effective status of the historical query result at the current moment is invalid or there is no target historical result information matching the query condition information, then according to the query condition information, obtain the blockchain information corresponding to the query condition information from the blockchain to obtain the target query result; according to the query condition information and the target query result, add the corresponding historical result information to the historical result set.

[0160] In some embodiments of the present application, based on the above technical solution, the query condition information includes a smart contract address and request contract parameters; the information query module 1020 is specifically configured to: execute a query through a smart contract according to the smart contract address and the request contract parameters to obtain an execution query result; in the process of executing the query, obtain a blockchain message generated when executing the query, wherein the blockchain message includes the initiating account when calling the smart contract to execute the query, the target account of the message, and the message data; and use the execution query result and the blockchain message as the target query result.

[0161] In some embodiments of the present application, based on the above technical solution, the information query module 1020 is specifically configured to: generate a contract address set according to the target account in each blockchain message; obtain the target block height of the block in the blockchain that contains the execution query result; generate corresponding historical result information according to the contract address set, the query condition information, the execution query result and the target block height and add it to the historical result set, wherein the contract address set is used to retrieve the historical result information according to the target account, and the target block height is used to indicate the effective start block of the historical result information.

[0162] In some embodiments of the present application, based on the above technical solution, the query request also includes a specified block height; the status determination module 1030 is specifically configured to: obtain the starting block height and ending block height of the effective status information in the target historical result information; if the specified block height is less than the starting block height and greater than the ending block height, it is determined that the effective status of the historical query result at the current moment is valid.

[0163] In some embodiments of the present application, based on the above technical solution, the information query module 1020 is further configured to: if the effective status of the historical query result at the current moment is invalid, then according to the query condition information, obtain the blockchain information corresponding to the query condition information from the blockchain to obtain the target query result; according to the target query result, update the historical query result in the target historical result information; and update the effective status of the target historical result information to valid.

[0164] In some embodiments of the present application, based on the above technical solution, the blockchain information query device further includes:

[0165] A block acquisition module, configured to acquire a block to be uploaded to the blockchain containing transactions to be uploaded to the blockchain;

[0166] a history query module configured to query, from the historical result set, historical result information to be updated associated with each transaction smart contract invoked by the transaction to be on-chain in the block to be on-chain;

[0167] The status update module is configured to update the validity status information of the historical result information to be updated to an invalid status.

[0168] In some embodiments of the present application, based on the above technical solution, the historical query result includes a historical contract address, which is the address of the smart contract called when querying the historical query result; the historical query module is specifically configured to: obtain the smart contract address called by each to-be-chained exchange in the to-be-chained block, and obtain a calling address set; for each smart contract address in the calling address set, obtain the historical query result containing the smart contract address in the historical contract address from the historical result set, and obtain the historical query result to be updated.

[0169] In some embodiments of the present application, based on the above technical solution, the historical query module is specifically configured to: when executing each transaction to be on the chain in the block to be on the chain, obtain the contract call message generated after executing each transaction to be on the chain, and obtain a call message set, wherein each contract call message contains the target account of the message; according to the target account of each contract call message, the contract call messages in the call message set are merged and deduplicated; obtain the target account of each remaining contract call message in the call message set to obtain a call address set.

[0170] In some embodiments of the present application, based on the above technical solution, the status update module is specifically configured to: obtain the block height of the block to be chained in the blockchain; and update the end block height in the effective status information of the historical result information to be updated according to the block height of the block to be chained.

[0171] In some embodiments of the present application, based on the above technical solution, the information query module 1020 is further configured to: obtain blockchain information corresponding to the historical query condition information in the historical result information to be updated from the blockchain to obtain an updated query result; and add corresponding historical result information to the historical result set based on the historical query condition information, the updated query result and the block height of the block to be chained in the blockchain.

[0172] It should be noted that the apparatus provided in the above embodiment and the method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module performs the operation has been described in detail in the method embodiment and will not be repeated here.

[0173] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device according to an embodiment of the present application is shown.

[0174] It should be noted that Figure 11 The computer system 1100 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0175] like Figure 11 As shown, computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1102 or programs loaded from storage 1108 into random access memory (RAM) 1103. RAM 1103 also stores various programs and data required for system operation. CPU 1101, ROM 1102, and RAM 1103 are connected to each other via a bus 1104. An input / output (I / O) interface 1105 is also connected to bus 1104.

[0176] The following components are connected to the I / O interface 1105: an input section 1106 including a keyboard, a mouse, and the like; an output section 1107 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 1108 including a hard disk; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card or a modem. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. Removable media 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1110 as needed, so that computer programs read from the removable media can be installed in the storage section 1108 as needed.

[0177] In particular, according to an embodiment of the present application, the processes described in the various method flow charts can be implemented as computer software programs. For example, an embodiment of the present application includes a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the methods shown in the flow charts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1109, and / or installed from a removable medium 1111. When the computer program is executed by the central processing unit (CPU) 1101, the various functions defined in the system of the present application are executed.

[0178] It should be noted that the computer-readable medium shown in the embodiments of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0179] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0180] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiment of the application, the features and functions of two or more modules or units described above can be concretized in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0181] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

[0182] Those skilled in the art will readily appreciate other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of this application and include common knowledge or customary techniques in the art that are not disclosed herein.

[0183] It should be understood that the present application is not limited to the exact structures described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for querying blockchain information, characterized in that: include: Obtaining a query request for blockchain information, wherein the query request includes query condition information; Querying a historical result set for target historical result information that matches the query condition information, wherein the historical result set includes multiple historical result information, each historical result information corresponds to a historical query condition information, and the historical result information is generated based on the historical query condition information, the corresponding historical query result, and the effective status information; Determining the current validity status of the historical query result in the target historical result information according to the validity status information of the target historical result information; If the historical query result is valid at the current moment, the target query result of the query request is generated according to the blockchain information in the historical query result.

2. The query method according to claim 1, characterized in that: The method further comprises: If the historical query result is invalid at the current moment or there is no target historical result information matching the query condition information, then according to the query condition information, obtain the blockchain information corresponding to the query condition information from the blockchain to obtain the target query result; According to the query condition information and the target query result, corresponding historical result information is added to the historical result set.

3. The query method according to claim 2, characterized in that: The query condition information includes a smart contract address and request contract parameters; obtaining blockchain information corresponding to the query condition information from the blockchain according to the query condition information to obtain a target query result includes: Execute a query through the smart contract according to the smart contract address and the requested contract parameters, and obtain an execution query result; During the query execution process, obtaining a blockchain message generated when executing the query, wherein the blockchain message includes a target account for invoking the message when invoking the smart contract to execute the query; The execution query result and the blockchain message are used as the target query result.

4. The query method according to claim 3, characterized in that: Adding corresponding historical result information to the historical result set according to the query condition information and the target query result includes: Generate a set of contract addresses based on the target account in each blockchain message; Obtaining a target block height of a block in the blockchain containing the query execution result; According to the contract address set, the query condition information, the execution query result and the target block height, corresponding historical result information is generated and added to the historical result set, wherein the contract address set is used to retrieve the historical result information according to the target account, and the target block height is used to indicate the effective start block of the historical result information.

5. The method according to claim 2, characterized in that The query request further includes a specified block height; and determining, based on the validity status information of the target historical result information, the validity status of the historical query result in the target historical result information at the current moment, includes: Obtain the start block height and end block height of the effective status information in the target historical result information; If the designated block height is less than the start block height and greater than the end block height, it is determined that the historical query result is valid at the current time.

6. The method according to claim 2, characterized in that Adding corresponding historical result information to the historical result set according to the query condition information and the target query result includes: If the historical result set does not exist, creating a historical result cache in a node gateway, wherein the node gateway is used for communication between the node in the blockchain and the requester of the query request; Obtaining the block height corresponding to the block in the blockchain that contains the target query result; Creating historical result information corresponding to the query request based on the block height, the query condition information, the parameters generated in the process of obtaining the target query result, the called smart contract address, and the target query result; The historical result information is written into the historical result cache to obtain the historical result set.

7. The query method according to claim 1, characterized in that: The method further comprises: If the historical query result is invalid at the current moment, then according to the query condition information, obtain the blockchain information corresponding to the query condition information from the blockchain to obtain the target query result; According to the target query result, update the historical query result in the target historical result information; Update the validity status of the target historical result information to valid.

8. The query method according to claim 1, characterized in that: The method further comprises: Get the block to be uploaded containing the transaction to be uploaded; According to the transaction smart contract called by each transaction to be on-chain in the block to be on-chain, query the historical result information to be updated associated with the transaction smart contract from the historical result set; The validity status information of the historical result information to be updated is updated to an invalid status.

9. The query method according to claim 8, characterized in that: The historical query result includes a historical contract address, which is the address of the smart contract called when querying the historical query result; querying the historical result information to be updated associated with the transaction smart contract from the historical result set according to the transaction smart contract called by each transaction to be on-chain in the block to be on-chain, includes: Obtain the smart contract address called by each to-be-on-chain exchange in the to-be-on-chain block to obtain a call address set; For each smart contract address in the call address set, obtain the historical query results containing the smart contract address in the historical contract addresses from the historical result set to obtain the historical query results to be updated.

10. The query method according to claim 9, characterized in that: The step of obtaining the smart contract address called by each to-be-on-chain exchange in the to-be-on-chain block to obtain a call address set includes: When executing each transaction to be on-chain in the block to be on-chain, obtaining a contract call message generated after executing each transaction to be on-chain, and obtaining a call message set, wherein each contract call message includes a target account of the message; Merge and remove duplicate contract call messages in the call message set based on the target account of each contract call message; Obtain the target accounts of the remaining contract call messages in the call message set to obtain a call address set.

11. The query method according to claim 8, characterized in that: Updating the validity status information of the historical result information to be updated to an invalid status includes: Obtaining the block height of the block to be chained in the blockchain; According to the block height of the block to be chained, the end block height in the validity status information of the historical result information to be updated is updated.

12. The query method according to claim 8, characterized in that: The method further comprises: According to the historical query condition information in the historical result information to be updated, the blockchain information corresponding to the historical query condition information is obtained from the blockchain to obtain an updated query result; According to the historical query condition information, the updated query result and the block height of the block to be chained in the blockchain, corresponding historical result information is added to the historical result set.

13. A device for querying blockchain information, characterized in that: include: A request acquisition module configured to obtain a query request for blockchain information, wherein the query request includes query condition information; an information query module configured to query a historical result set for target historical result information that matches the query condition information, wherein the historical result set includes a plurality of historical result information, each historical result information corresponds to a piece of historical query condition information, and the historical result information is generated based on the historical query condition information, the corresponding historical query result, and the effective status information; a state determination module configured to determine the current validity state of the historical query result in the target historical result information according to the validity state information of the target historical result information; The result generation module is configured to generate a target query result of the query request based on the blockchain information in the historical query result if the validity status of the historical query result at the current moment is valid.

14. An electronic device, characterized in that: include: processor; a memory for storing executable instructions of the processor; The processor is configured to execute the blockchain information query method described in any one of claims 1 to 12 by executing the executable instructions.

15. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for querying blockchain information according to any one of claims 1 to 12 is implemented.

16. A computer program product, characterized in that The computer program product includes a computer program, which is stored in a computer-readable storage medium. The processor of the electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device performs the blockchain information query method as claimed in any one of claims 1 to 12.

Images