Data processing method and device, equipment and medium

Abstract

The invention discloses a data processing method and device, equipment and a medium, and the method comprises the steps: obtaining global branch information from a business database based on query information when the query information sent by a business object through a business query client is obtained; the query information carries a block query height specified by the business object; the global branch information is used for indicating a branch identifier of the branched main chain and a to-be-confirmed block height range; when the block query height is within the to-be-confirmed block height range, determining a query index based on the block query height and a branch identifier of the branch main chain; and in a business database, searching business data matched with the query index, and when the business data matched with the query index is searched, taking the searched business data as target business data, and sending the target business data to the business query client. By adopting the method and the device, when the block chain is bifurcated, the consistency of external display of the business data in the business database can be ensured.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular, to a data processing method, apparatus, device, and medium. Background Art

[0002] Currently, business data on the blockchain (such as block headers, transaction data, contract data, etc.) is open, and users can choose to directly query the required data on the blockchain. For example, relevant data can be queried through information such as block height, block hash value, transaction hash value, etc. However, since no queryable index is established on the chain, this method does not support users to perform personalized queries (such as querying the time when the first transaction of a specific contract occurred or the number of times the contract was called within a certain period, etc.). To overcome the limitations of on-chain queries, an external system (such as a blockchain browser) that can meet business query requirements can be built. The data source of this system is the blockchain, that is, the business data on the blockchain can be synchronized to this system, and various indexes can be added for users to query, so as to enrich the query dimensions of the business.

[0003] The inventors found in practice that when the blockchain forks, it will switch from a certain fork chain (such as fork chain 1) to other fork chains with the same height but different content (such as fork chain 2). At this time, the external system also needs to synchronously update the business data on the fork chain stored in its business database. However, this switching process involves deleting, modifying, or replacing a large amount of business data on the original fork chain 1 with the business data on fork chain 2 in the business database. If the user queries data in the business database by block height before the blockchain fork data is updated, the query results may simultaneously show the business data on both fork chain 1 and fork chain 2, resulting in the problem that the business data queried in the business database is inconsistent with the business data on the chain. Summary of the Invention

[0004] Embodiments of this application provide a data processing method, apparatus, device, and medium, which can ensure the consistency of the external display of business data in the business database when the blockchain forks.

[0005] On the one hand, embodiments of this application provide a data processing method, which is executed by a business server. The business server is used to synchronize business data on the blockchain to the business database; the data index of the business database is determined by a branch identifier and a block height; the branch identifier is used to identify the to-be-confirmed fork chain in the blockchain; the block height is used to indicate the block where the business data on the to-be-confirmed fork chain is located; the method includes:

[0006] When obtaining the query information sent by the service object through the service query client, based on the query information, obtain the global branch information from the service database; the query information carries the block query height specified by the service object; the global branch information is used to indicate the branch identifier of the forked main chain and the range of block heights to be confirmed; the range of block heights to be confirmed is determined by the confirmed block height and the maximum block height of the blockchain; the forked main chain is determined by the blockchain nodes in the blockchain network where the blockchain is located in the forked chain to be confirmed;

[0007] When the block query height is within the range of block heights to be confirmed, determine the query index based on the block query height and the branch identifier of the forked main chain;

[0008] In the service database, search for service data that matches the query index, and when the service data that matches the query index is found, use the found service data as the target service data and send the target service data to the service query client.

[0009] On the one hand, an embodiment of the present application provides a data processing device, which is characterized in that the device runs on a service server, and the service server is used to synchronize the service data on the blockchain to the service database; the data index of the service database is determined by the branch identifier and the block height; the branch identifier is used to identify the forked chain to be confirmed in the blockchain; the block height is used to indicate the block where the service data on the forked chain to be confirmed is located; the device includes:

[0010] An information acquisition module, configured to, when obtaining the query information sent by the service object through the service query client, obtain the global branch information from the service database based on the query information; the query information carries the block query height specified by the service object; the global branch information is used to indicate the branch identifier of the forked main chain and the range of block heights to be confirmed; the range of block heights to be confirmed is determined by the confirmed block height and the maximum block height of the blockchain; the forked main chain is determined by the blockchain nodes in the blockchain network where the blockchain is located in the forked chain to be confirmed;

[0011] A first determination module, configured to determine the query index based on the block query height and the branch identifier of the forked main chain when the block query height is within the range of block heights to be confirmed;

[0012] A data search module, configured to search for service data that matches the query index in the service database, and when the service data that matches the query index is found, use the found service data as the target service data and send the target service data to the service query client.

[0013] Among them, the information acquisition module is specifically configured to, when obtaining the query information sent by the service object through the service query client, obtain the global branch index based on the block query height carried in the query information; and obtain the global branch information through the global branch index in the service database.

[0014] Among them, the first determination module is specifically configured to, when the block query height is greater than the confirmed block height and less than or equal to the maximum block height, determine that the block query height is within the range of the to-be-confirmed block height, and determine the query index by performing a splicing process on the block query height and the branch identifier of the forked main chain.

[0015] Among them, the first determination module includes:

[0016] The first splicing unit is configured to perform a splicing process on the block query height and the branch identifier of the forked main chain to obtain a query index for the target block header information; the target block header information is the block header information in the block with the block query height specified by the service object for query.

[0017] Among them, the query information includes a transaction query index; the transaction query index is the transaction index of the target transaction data specified by the service object for query in the block with the block query height.

[0018] The first determination module includes:

[0019] The second splicing unit is configured to perform a splicing process on the block query height, the transaction query index, and the branch identifier of the forked main chain to obtain a query index for the target transaction data.

[0020] Among them, the query information includes a contract query index; the contract query index is the contract index of the target contract data specified by the service object for query in the block with the block query height.

[0021] The first determination module includes:

[0022] The third splicing unit is configured to perform a splicing process on the block query height, the contract query index, and the branch identifier of the forked main chain to obtain a query index for the target contract data.

[0023] Among them, the device further includes:

[0024] The second determination module is configured to determine the query index based on the block query height when the block query height is less than or equal to the confirmed block height.

[0025] Among them, the to-be-confirmed forked chain includes a first to-be-confirmed forked chain and a second to-be-confirmed forked chain, and the first to-be-confirmed forked chain is different from the second to-be-confirmed forked chain; the forked main chain is the first to-be-confirmed forked chain selected by the blockchain node from the to-be-confirmed forked chains; the device further includes:

[0026] An identity change module, which is used to, when detecting that a blockchain node switches the forked main chain from a first to-be-confirmed forked chain to a second to-be-confirmed forked chain, if all the business data on the second to-be-confirmed forked chain has been stored in the business database, or the block synchronization height of the second to-be-confirmed forked chain in the business database is greater than or equal to the block synchronization height of the first to-be-confirmed forked chain in the business database, change the branch identifier of the forked main chain in the global branch information from the branch identifier of the first to-be-confirmed forked chain to the branch identifier of the second to-be-confirmed forked chain.

[0027] Wherein, the block hash value corresponding to the block with the maximum block height on the first to-be-confirmed forked chain is the first block hash value; the apparatus further includes:

[0028] A forked chain switching module, which is used to obtain the block hash value corresponding to the block with the maximum block height from the blockchain, and use the obtained block hash value as the second block hash value; when the second block hash value is different from the first block hash value, search in the business database for the branch identifier of the to-be-confirmed forked chain where the block corresponding to the second block hash value is located, and if the found branch identifier is the branch identifier of the second to-be-confirmed forked chain, determine that the blockchain node switches the forked main chain from the first to-be-confirmed forked chain to the second to-be-confirmed forked chain.

[0029] Wherein, the apparatus further includes:

[0030] A switching prompt module, which is used to send a forked chain switching prompt message to the business query client based on the communication connection between the business query client and the business server; the forked chain switching prompt message is used to indicate that the forked main chain switches from the first to-be-confirmed forked chain where the target business data is located to the second to-be-confirmed forked chain.

[0031] Wherein, the apparatus further includes:

[0032] A forked chain confirmation module, which is used to, when detecting that the forked main chain of the blockchain node is an already-confirmed forked chain in the blockchain, delete the business data on the to-be-confirmed forked chain stored in the business database; synchronize the business data on the already-confirmed forked chain to the business database; the data index of the business database is determined by the block height associated with the blockchain; configure the global branch information stored in the business database as a null value.

[0033] An embodiment of the present application provides a computer device on the one hand, including: a processor and a memory;

[0034] The processor is connected to the memory, wherein the memory is used to store a computer program, and when the computer program is executed by the processor, the computer device executes the method provided by the embodiment of the present application.

[0035] On the one hand, an embodiment of the present application provides a computer-readable storage medium storing a computer program, which is adapted to be loaded and executed by a processor so that a computer device having the processor executes the method provided by the embodiment of the present application.

[0036] On the one hand, an embodiment of the present application provides a computer program product, which includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided by the embodiment of the present application.

[0037] In an embodiment of the present application, the business server may synchronize the business data on the blockchain to the business database, and the data index of the business database is determined by the branch identifier and the block height; the branch identifier here can be used to identify the to-be-confirmed fork chain in the blockchain; the block height can be used to indicate the block where the business data on the to-be-confirmed fork chain is located; when the business server obtains the query information sent by the business object through the business query client, it can obtain the global branch information from the business database based on the query information; the query information carries the block query height specified by the business object; the global branch information can be used to indicate the branch identifier of the fork main chain and the range of to-be-confirmed block heights; the range of to-be-confirmed block heights here is determined by the confirmed block height and the maximum block height of the blockchain; the fork main chain is determined by the blockchain nodes in the blockchain network where the blockchain is located in the to-be-confirmed fork chain; further, when the foregoing block query height is within the range of to-be-confirmed block heights, the query index can be determined based on the block query height and the branch identifier of the fork main chain; in the business database, search for the business data that matches the query index, and when the business data that matches the query index is found, the found business data can be used as the target business data, and the target business data can be sent to the business query client. It can be seen that the embodiment of the present application provides a blockchain data synchronization storage and acquisition solution in a forked blockchain. When the blockchain forks, the business server (belonging to an external system) can save all the forked chains (i.e., the foregoing to-be-confirmed fork chains) that have not been confirmed by the blockchain nodes to the business database, and each forked chain can be marked with its own branch identifier when synchronizing data. In this way, when synchronizing any business data on any forked chain, the corresponding data index can be constructed in the business database based on the branch identifier of the forked chain and the block height of the block where the business data is located, for the business object to perform personalized queries, thereby enriching the query dimension of the business; and in order to ensure the accuracy and reliability of business queries, the global branch information can be added to the business database to indicate the branch identifier of the current fork main chain and the range of to-be-confirmed block heights. In this way, when the business object queries the business data within the range of to-be-confirmed block heights in the business database, the query index can be determined based on the block height to be queried (i.e., the foregoing block query height) and the branch identifier of the fork main chain. It can be understood that the matching business data (i.e., the foregoing target business data) found in the business database through the query index is consistent with the relevant business data on the fork main chain of the blockchain at this time, so as to ensure the consistency of the business data (or blockchain fork data) displayed externally in the business database when the blockchain forks, and can improve the query experience of the business object. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0039] Figure 1 It is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0040] Figure 2 It is a schematic diagram of a data processing scenario provided by an embodiment of the present application;

[0041] Figure 3 It is a flowchart of a data processing method provided by an embodiment of the present application Figure 1 ;

[0042] Figure 4 It is a flowchart of a data processing method provided by an embodiment of the present application Figure 2 ;

[0043] Figure 5 It is a schematic diagram of a business data query scenario provided by an embodiment of the present application;

[0044] Figure 6 It is a schematic diagram of the structure of a data processing device provided by an embodiment of the present application;

[0045] Figure 7 It is a schematic diagram of the structure of a computer device provided by an embodiment of the present application. Detailed implementation manners

[0046] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present application.

[0047] Please refer to Figure 1 , Figure 1 It is a schematic diagram of a system architecture provided by an embodiment of the present application. As Figure 1As shown in the figure, the system architecture may include a business server 100, a terminal cluster, and a blockchain network 300. Among them, the terminal cluster may include multiple terminal devices (which may be simply referred to as terminals), and the embodiments of the present application do not limit the number of terminal devices included in the terminal cluster. For example, the terminal cluster may specifically include: terminal device 200a, terminal device 200b, terminal device 200c, …, terminal device 200n. Among them, there may be a communication connection between the terminal clusters. For example, there is a communication connection between terminal device 200a and terminal device 200b, and there is a communication connection between terminal device 200a and terminal device 200c. At the same time, any terminal device in the terminal cluster may have a communication connection with the business server 100, so that each terminal device in the terminal cluster can perform data interaction with the business server 100 through this communication connection. For example, there is a communication connection between terminal device 200a and business server 100. Among them, the above communication connection does not limit the connection method, and it can be directly or indirectly connected through a wired communication method, or directly or indirectly connected through a wireless communication method, or through other methods, and the embodiments of the present application do not make restrictions here.

[0048] Among them, the business server 100 may be an independent physical server, or 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, and big data and artificial intelligence platforms. The number of business servers may be one or more, and no restrictions are made here. One terminal device may be connected to one business server, and each business server can perform data interaction with the terminal device connected to it.

[0049] Among them, the above terminal devices may be intelligent terminals such as smart phones, tablet computers, laptop computers, desktop computers, desktop computers, palm computers, mobile internet devices (MID), wearable devices (such as smart watches, smart helmets, etc.), smart computers, smart homes, and smart vehicles. Any terminal device and the business server can be directly or indirectly connected through wired or wireless means, and the embodiments of the present application do not make restrictions here.

[0050] It should be understood that, as Figure 1 shown, each terminal device in the terminal cluster may be installed with a client. When the client runs on each terminal device, it can be respectively connected to the above Figure 1Data interaction is carried out between the business servers 100 shown. Among them, the client can be an information client (such as a business query client), a financial client (for example, a resource client, a payment client, a shopping client), an entertainment client (such as a game client, a live broadcast client, a novel client), a multimedia client (such as a video client, a music client), a vehicle-mounted client, a smart home client, a browser, etc., which are application programs with the function of displaying data information such as text, images, videos, and audio. Among them, the client can be an independent client or an embedded sub-client integrated in a certain client (such as a payment client, etc.), which is not limited here. Taking the business query client as an example, the terminal device 200a can perform data transmission with the business server 100 through the business query client running on it. For example, the terminal device 200a can send a query request to the business server 100 through this business query client, so as to obtain the required data.

[0051] Among them, terminal devices can be roughly divided into two terminal types according to their operation methods. For the convenience of distinction, they can be respectively called the first terminal type and the second terminal type here. Among them, the terminal device with the first terminal type (which can also be called a desktop device or a desktop-oriented terminal device) refers to a terminal device mainly based on interactive operations such as mouse clicks and keyboard inputs. Any client running on such a terminal device can usually support opening one or more windows simultaneously (that is, support multi-page display). Therefore, such a terminal device has the characteristic of interacting with windows as the dimension. Terminal devices with the first terminal type can include laptop computers, desktop computers, smart computers, some tablet computers (such as Microsoft's Surface Pro, which can be operated with an external keyboard and mouse), etc.; while the terminal device with the second terminal type (which can also be called a non-desktop device) refers to a terminal device mainly based on interactive operations such as user hand clicks or swipes. Any client running on such a terminal device can usually only open one window (that is, support single-page display). Terminal devices with the second terminal type can include smart phones, some tablet computers (such as iPad), mobile Internet devices, wearable devices (such as smart watches, smart bracelets, etc.), smart vehicles, etc. Based on this, the embodiments of this application can also divide the clients installed and running on different terminal types into two client types. Among them, the client type of the client installed and running on the terminal device with the first terminal type can be called the first client type (that is, a desktop-oriented client, which can also be called a non-mobile terminal, such as a computer terminal), and the client type of the client installed and running on the terminal device with the second terminal type can be called the second client type (that is, a mobile terminal, such as a mobile phone terminal). For two different client types of the same application, there may also be certain differences in their page layouts and interaction methods. The method provided in this application is applicable to all client types. Therefore, all embodiments of this application do not limit the terminal types of the terminal devices involved, nor do they limit the client types of the clients involved, and the differences in the page layouts and interaction methods of different client types will not be distinguished and described subsequently.

[0052] It can be understood that blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. It is mainly used to sort data in chronological order, encrypt it into a ledger, make it unforgeable and tamper-proof, and at the same time, data verification, storage, and update can be carried out. Blockchain is a chain composed of one block after another. Each block stores certain information, and they are connected into a chain according to the chronological order of their generation. Blockchain is essentially a decentralized database, and each node in this database stores the same blockchain. As long as one node in the entire database can work, the entire blockchain is secure. For exampleFigure 1 The blockchain network 300 shown can be applied to a blockchain system, which refers to a system for data sharing between blockchain nodes. The blockchain network 300 can be deployed with multiple blockchain nodes (which can be simply referred to as nodes), and the number of blockchain nodes deployed in the blockchain network 300 will not be limited here. For example, as Figure 1 shown, the blockchain network 300 can specifically include node 300a, node 300b, node 300c, node 300d, …, node 300m. Among them, the blockchain node can be a server connected to the blockchain network or a terminal connected to the blockchain network. The specific form of the blockchain node is not limited here. Each blockchain node can include a hardware layer, an intermediate layer, an operating system layer, and an application layer. The foregoing business server 100 can have a communication connection with any blockchain node in the blockchain network 300, so that the business server 100 can perform data interaction with the business server 100 through this communication connection. For example, there is a communication connection between the business server 100 and the node 300a, and the business server 100 can synchronize the data on the blockchain corresponding to the blockchain network 300 through this communication connection. Among them, the communication connection here does not limit the connection method, and can be directly or indirectly connected through a wired communication method, or can be directly or indirectly connected through a wireless communication method, or can also be through other methods, which are not limited in the embodiments of the present application.

[0053] Among them, the foregoing server connected to the blockchain network can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0054] It should be noted that the blockchain network in the embodiments of the present application can be a hierarchical structure or a single-layer structure, and the specific structure of the blockchain network is not limited here.

[0055] For example, optionally, for a blockchain network with a hierarchical structure, Figure 1 the blockchain network 300 shown can be further divided into a business network (i.e., a witness network) and a core consensus network, and the business network and the core consensus network are independent of each other. Among them, multiple nodes can be deployed in both the business network and the core consensus network, and the number of nodes deployed in the two networks will not be limited here. For example, the business network can include Figure 1 the nodes 300a, 300b, and 300c shown, and the core consensus network can include Figure 1The nodes 300d, 300e, …, 300m shown. Among them, the nodes in the business network can be called business nodes, and the business nodes here are mainly used to execute transaction services to obtain transaction data associated with the transaction service and perform data clearing and synchronization in a timely manner. It can be understood that business nodes do not need to participate in the accounting consensus, but can obtain block header data and partially authorized visible block data from the core consensus network through identity authentication. Among them, the business node can be a full node (Full Node) containing a complete blockchain database, or a lightweight node (Lightweight Node) storing part of the data in the blockchain database. Such nodes can complete transaction verification through the "Simplified Payment Verification (SPV)" method, so they can also be called SPV nodes. The types of business nodes will not be limited here. Similarly, the nodes in the core consensus network can be called consensus nodes (also called core nodes, that is, accounting nodes), and the consensus nodes here can run the blockchain consensus protocol. Among them, the consensus node can be a full node containing a complete blockchain database. The consensus node can participate in verifying and broadcasting transaction data and block information, and will discover and maintain connections with other nodes. In addition, optionally, the business network and the core consensus network can be network-isolated through a routing network (i.e., the routing proxy layer). For example, through the routing nodes in the routing network, the peer-to-peer network can be network-layered to form a hierarchical structure of "business network - core consensus network", thereby improving the confidentiality and security of data on the blockchain. The number of routing nodes in the routing network can be one or more, which is not limited here.

[0056] It can be understood that the above-mentioned business network and core consensus network can be in different network environments. For example, in some embodiments, the business nodes can be deployed in the business network in the public network, while the consensus nodes running the blockchain consensus protocol can be deployed in the private core consensus network, and the two can interact through the routing boundary. In this case, since the core consensus network is in a relatively secure private cloud, its mutual access already has a consensus mechanism to ensure security and does not require additional identity management and network control; while the business nodes are in the public network and may be accessed by other uncertain network terminals, so the behavior of business nodes and other possible nodes accessing the core consensus network needs to be strictly controlled. Optionally, in some other embodiments, the business nodes and the consensus nodes can also directly transmit data without passing through the routing nodes, which is not limited here.

[0057] For another example, optionally, for a blockchain network with a single-layer structure Figure 1The blockchain network 300 shown may include consensus nodes and ordinary nodes. The consensus nodes participate in consensus, while the ordinary nodes do not participate in consensus, but can help spread block and voting messages, and synchronize states with each other, etc. For example, nodes 300a, 300b, 300c, and 300d in Figure 1 can be used as consensus nodes, and the remaining nodes can be used as ordinary nodes. Here, neither the number of consensus nodes nor the number of ordinary nodes is limited.

[0058] In the above blockchain system, the consensus nodes can be responsible for the consensus in the blockchain network (such as blockchain network 300) where the corresponding blockchain is located. For the above blockchain network 300, the specific process of writing the transaction data in the blockchain network 300 into the corresponding blockchain ledger (for example, a distributed database) can be as follows: the user client sends the transaction data to a non-consensus node (such as a business node or an ordinary node), and then the transaction data is passed between the non-consensus nodes in the above blockchain network 300 in a relay manner until the consensus node (such as node 300d) in the above blockchain network 300 receives the transaction data. At this time, the consensus node packs the transaction data into a block, so that subsequent consensus can be carried out with other consensus nodes, and after the consensus is passed, the block passed by the consensus can be written into the distributed database of the blockchain network 300.

[0059] Optionally, it can be understood that after the consensus is passed, the consensus node can also write the block carrying the transaction data and multiple other blocks associated with the block into the distributed database in parallel through the storage layer of its own blockchain network 300 (for example, the core consensus network under the hierarchical structure). In this way, the limitation of the blockchain structure of the blockchain can be broken through from the root, and thus the storage efficiency of data storage can be effectively improved.

[0060] In the embodiments of the present application, all nodes in the blockchain network (such as the foregoing consensus nodes, business nodes, and ordinary nodes) can be collectively referred to as blockchain nodes. Among them, the embodiments of the present application can configure a blockchain node for any role (such as any individual user, any enterprise, any institution, etc., an entity object) accessing the blockchain network. For example, assume that as Figure 1 shown, nodes 300a, 300b, and 300c in the blockchain network 300 are all business nodes, then there can be a one-to-one correspondence between nodes 300a, 300b, and 300c and the corresponding roles that need to access the blockchain network 300, and the blockchain nodes associated with different roles can be the same blockchain node.

[0061] It can be understood that a smart contract can be deployed in the above blockchain system. In the blockchain system, the smart contract can be understood as a piece of code that can be understood and executed by each node of the blockchain (such as a consensus node), and can execute any logic and obtain results. In practical applications, the smart contract can be managed and used through transactions on the blockchain. Each transaction is equivalent to an RPC (Remote Procedure Call) request to the blockchain system. For example, an entity object (such as a user requesting to execute a transaction service) can initiate a contract call request (also referred to as a transaction service request) through a client (such as a payment client) on its held terminal device (such as the above terminal device 200a), and call a relevant business contract that has been deployed on the blockchain (such as the blockchain corresponding to the above blockchain network 300). The blockchain system can include one or more smart contracts, and these smart contracts can be distinguished by contract identifiers. In the contract call request initiated by the client, the contract identifier of the smart contract can be carried to specify the smart contract that the blockchain needs to run. Among them, the contract identifier can include, but is not limited to, the contract identifier number of the smart contract (i.e., contract ID, where ID is the abbreviation of Identity document), contract name, contract address, contract function name (also referred to as contract method name), etc. The specific form of the contract identifier will not be limited here.

[0062] It can be understood that the embodiments of the present application relate to a business query system. Here, the business query system refers to an external system that is public and independent of the blockchain network (such as Figure 1 the blockchain network 300 shown). The data source of this system is the blockchain and can be used to provide query services related to the blockchain externally, that is, any entity object can perform personalized queries locally in the business query system without manually writing corresponding code to query the required data on the blockchain. The business query system can specifically include a business server and a business query client. Among them, the business server (such as Figure 1 the business server 100 shown) can be used to request to synchronize the data on the blockchain from any blockchain node in the blockchain network (such as any blockchain node in the above blockchain network 300, such as node 300d), and store the synchronized data in its own business database for query. For the convenience of distinction, the embodiments of the present application can collectively refer to the blockchain data synchronized by the business server as business data. The business data can include, but is not limited to, block header information (which can be abbreviated as block header), transaction data, contract data, account information, and other blockchain data. Since these business data are sourced from the blockchain, it is possible to query the data on the chain in the business database.

[0063] Among them, any block may include block header information and a block body; the block header information here may include information such as the hash value of the parent block of the block, the block height, the version number, the timestamp, the difficulty value, the nonce, and the Merkle root, etc.; the block body may include the transaction data packed into the block and the Merkle path composed of the transaction hash values corresponding to these transaction data.

[0064] Among them, the transaction data refers to the data associated with the transaction service obtained after executing the transaction service. The transaction service may include, but is not limited to, bill services (such as e-bill issuance services, e-bill circulation services, e-bill red-ink services, e-bill archiving services, etc. related to e-bills), bill derivative services associated with bill services (such as credit services, import and export services, enterprise qualification services, credit investigation services, credit purchase services, and tax refund services, etc.), document services (such as e-document issuance services, e-document circulation services, e-document amendment services, e-document archiving services, etc. related to e-documents), document derivative services associated with document services (institutional cooperation services, enterprise qualification services, prescription statistics services, qualification review services, etc.), etc.; correspondingly, the transaction data generated after executing the transaction service may include, but is not limited to, e-bills associated with bill services, some authorized visible bill information in the e-bill (for example, bill number, payee, etc.), general bill associated resources associated with the e-bill (for example, credit investigation information, tax information, etc.), and e-documents associated with document services or some authorized visible document information in the e-document (for example, certificate information in the e-certificate), general document associated resources associated with the e-document (for example, qualification information, prescription statistics results, etc.). Here, the specific content of the transaction data associated with the transaction service is not restricted.

[0065] Among them, contract data can be understood as the data recorded in the contract log after executing a transaction business by invoking a business contract on the blockchain. Since the relevant transaction data may only show some simple contract call information (such as calling a certain contract method in the business contract), while the contract data can be used to display the specific actions that occurred in detail. For example, the contract data may include the basic information of the business contract (such as contract identification, contract type, etc.), the identity information of the business contract caller, the direction of resource transfer (such as enterprise A issuing an electronic bill to user B), the data status of both parties to the transaction (such as the transaction read-write set obtained after executing the transaction business), etc. The specific content of the contract data is not restricted here. Among them, the business contracts used to execute the above transaction business may include, but are not limited to, electronic bill issuance contracts, electronic bill transfer contracts, electronic bill red-emption contracts, electronic bill archiving contracts, bill derivative business contracts, tax application contracts, electronic document issuance contracts, electronic document transfer contracts, electronic document amendment contracts, electronic document archiving contracts, document derivative business contracts, etc., which are not limited here.

[0066] Among them, account information refers to the information associated with the accounts of the entity objects involved in the transaction business (such as the aforementioned enterprise A and user B), such as account address, account balance, historical transaction records, etc. The specific content of the account information is not restricted here.

[0067] Among them, the data storage method adopted by the embodiments of the present application for the business database is not limited. For example, it can adopt KV (abbreviation for Key-Value) storage, MySQL storage, etc. Among them, KV storage can also be called key-value pair storage or key-value storage. Each unique identifier is stored as a key (i.e., Key) with a related value (i.e., Value). This data pairing is called a "key-value" pair. In a key-value pair, the key must be unique, and the value related to the key can be accessed through the key. That is to say, the Key can be used as an index to implement the functions of data storage, modification, query, and deletion. For ease of understanding, the subsequent embodiments of the present application will be described by taking KV storage as an example. That is, the aforementioned business database can specifically be a database adopting the KV storage method (which can be called a KV database), such as Redis, Memcached, etcd, Zookeeper, etc., without limitation here. Based on this, an index relationship in the form of key-value pairs can be established in the business database to support the query ability. Among them, the key can be in the form of plain text, numbers, or hash values (i.e., hash values), etc. The specific content of the value is business data. These business data can include both the original business data synchronized from the blockchain and other data (which can be called derivative business data) derived from the core data indicators (such as price, computing power, transaction quantity, etc.) constructed according to the original business data and the business query system. And the business data can be stored in the business database in the form of strings, lists, or objects, without limitation on the storage form of the business data here.

[0068] Among them, the business query client can run on a terminal device and is a tool for browsing, querying, and analyzing blockchain data. It can convert the data obtained from the blockchain through parsing into a graphical interface that is easy to understand (without limitation on the interface form and content here), enabling users to conveniently understand and query the transactions and other information on the blockchain. For example, relevant information related to a specific business contract (such as a business contract related to an exchange) can be efficiently queried through the business query client. It can be understood that when the business query client runs on, for example Figure 1When on any one of the terminal devices in the shown terminal cluster (such as terminal device 200a), data interaction can occur between the service query client and the service server 100. For example, when a certain entity object (such as the aforementioned enterprise A) wishes to query the quantity of electronic invoices issued by the electronic invoice issuance contract on the call chain within a certain day, it can send corresponding query information to the service server 100, so that the service server 100 can query in the service database according to the query information and return the query result (i.e., the counted quantity of electronic invoices) to the service query client. It can be understood that the service query client can include, but is not limited to: an independent client, a small program running as a subroutine in the client, and a web application or extension program opened through a browser, etc. The embodiments of the present application do not limit the type of the service query client. For example, the service query client can specifically be a blockchain browser, and the business object can browse or query all service data synchronized from the blockchain through the blockchain browser.

[0069] For ease of understanding and description, the entity object that performs data query through the service query client in the embodiments of the present application (for example, individual users, enterprise users, institutions, etc.) can be referred to as a business object (such as the aforementioned enterprise A). This business object can be, for example, a developer of the service query system, a holder of digital resources, a user of a decentralized application (i.e., DApp), a supervisor of the blockchain system, or a user interested in the blockchain, etc. In addition, the terminal device associated with the business object (such as the aforementioned terminal device 200a) can be referred to as a business terminal.

[0070] It can be understood that in special cases, the blockchain may fork. For example, when the blockchain system is upgraded, there may be changes in the consensus rules (such as the blockchain consensus protocol), and there may also be differences in opinions among blockchain nodes. Since the blockchain nodes with upgraded software and those without upgraded software in the blockchain system use different consensus rules, forks may occur, that is, on the basis of the original blockchain, one or more additional blockchains are split based on different consensus rules. Since it takes some time for each blockchain node to confirm a certain blockchain among multiple forked blockchains (which can be simply referred to as forked chains), all forked chains that have not been confirmed by blockchain nodes can be collectively referred to as to-be-confirmed forked chains, and the number of to-be-confirmed forked chains is not limited here; during the waiting for confirmation, the blockchain system still needs to maintain normal business operations. Therefore, each relevant blockchain node can select a forked chain as the forked main chain from multiple to-be-confirmed forked chains according to the specified main chain selection rule. The forked main chain can be understood as the effective forked chain selected by the blockchain node, and the reading of blockchain data will be performed on this forked main chain. The embodiments of this application do not limit the main chain selection rule. For example, the longest forked chain can be selected from multiple to-be-confirmed forked chains as the forked main chain. In addition, before a certain forked chain is finally confirmed by blockchain nodes, all forked chains are continuously developing. Therefore, the forked main chain can be switched from the current forked chain to other forked chains at any time.

[0071] In view of the problem of data inconsistency existing in the current business query system during blockchain forking, the embodiments of this application provide a blockchain data synchronization storage and acquisition solution in a forked blockchain, which can ensure the consistency of the business data displayed externally in the business database when the blockchain forks. Among them, the business object can choose to use the block height for data query. Here, the block height (which can be abbreviated as height) is the identifier of the block and is used to measure the distance between a certain block in the blockchain and the first block. Through the block height, the position of a certain block on the chain can be accurately understood, which is equivalent to positioning a coordinate for the block; for easy distinction, the block height specified by the business object for query can be called the block query height. Based on this, in order to implement data query based on the block height, the data index of the business database can be constructed based on the block height. For example, when the business database is the aforementioned KV database, the business data can be used as the value, and the key corresponding to the value can be used as the data index corresponding to the business data. The key with any business data can include the block height of the block where the business data is located. It can be understood that when the blockchain forks, there will be blocks with the same block height but different contents on different to-be-confirmed forked chains. That is to say, before these blocks are finally confirmed, any one of them may be replaced by other blocks with the same block height but different contents. At this time, if the relevant data index only includes the block height, it is obviously difficult to distinguish the business data with the same block height on different to-be-confirmed forked chains. Based on this, when the business server synchronizes the business data on the to-be-confirmed forked chain to the business database, a branch identifier of the to-be-confirmed forked chain where it is located can be added to the data index corresponding to these business data for distinction. That is to say, the data index corresponding to the business data on the to-be-confirmed forked chain can include both the branch identifier of the to-be-confirmed forked chain and the block height of the block where the business data is located. Among them, the branch identifier can include, but is not limited to, the branch number, branch name, etc. of the to-be-confirmed forked chain. Here, the specific form of the branch identifier will not be limited, and a branch identifier is used to uniquely identify a forked chain.

[0072] It should be noted that the business server can synchronously store all blockchain fork data (i.e., business data on all to-be-confirmed fork chains) in the business database. To ensure the consistency of data query, in the embodiments of this application, global branch information is added to the business database, indicating that business data exceeding the specified block height needs to be queried based on the branch identifier of the fork main chain. Among them, the global branch information can be used to indicate the branch identifier of the fork main chain (also referred to as the global branch number) and the range of to-be-confirmed block heights. Here, the range of to-be-confirmed block heights is determined by the confirmed block height of the blockchain (such as height C1) and the maximum block height (such as height C2). That is to say, when querying business data with a block query height (such as height C3) specified by the business object that is greater than the confirmed block height and less than or equal to the maximum block height, the branch identifier of the fork main chain needs to be used. Among them, the confirmed block height refers to the maximum block height on the chain that has been confirmed by the blockchain node, and the maximum block height refers to the maximum block height currently generated by the blockchain node. When the blockchain forks, all blocks from the next block height after the confirmed block height until the maximum block height (i.e., blocks within the range of to-be-confirmed block heights) have not been confirmed by the blockchain node, that is, the maximum block height is greater than the confirmed block height.

[0073] It is understandable that, according to the characteristics of the blockchain, the business data on the fork chain is confirmed after waiting for a certain number of blocks, and the number of blocks that different blockchains need to wait for may be different. For example, assume that a certain blockchain X requires 10 blocks for confirmation. For the business data in the i-th block on blockchain X (when it is the 1st block for confirmation), when the (i + 9)-th block appears (when it is the 10th block for confirmation), it is basically tamper-proof. Among the latest block height N (i.e., the maximum block height of blockchain X) and the previous 9 blocks up to block height (N - 10 + 2) ((N - 10 + 1) is the confirmed block height of blockchain X), they may all be switched to other forks at any time. If you want to query the business data within this range (i.e., the range of block heights to be confirmed), you need to select a fork chain as the main fork chain and consider that the data on the main fork chain is correct at present (of course, it may be switched to other fork chains later). Therefore, the business data within this range needs to be queried based on the branch identifier of the main fork chain; only the business data before block height (N - 10 + 2) is already determined and can be directly queried according to the block height. It is understandable that when the blockchain node switches the main fork chain, the branch identifier of the main fork chain in the global branch information also needs to be changed accordingly. Subsequently, the new branch identifier will be used to query the business data within the range of block heights to be confirmed. For example, assume that the blockchain node switches the main fork chain from fork chain 1 to fork chain 2. The business server will switch the branch identifier of the main fork chain in the global branch information from the branch identifier of fork chain 1 to the branch identifier of fork chain 2. At this time, the branch identifier of fork chain 2 will be used to query the business data within the range of block heights to be confirmed. That is to say, when the blockchain node switches to other fork chains, the business server only needs to modify the branch identifier of the main fork chain in the global branch information, which is equivalent to quickly switching the main fork chain as a whole. Compared with the method of deleting, modifying, or replacing relevant business data item by item in the business database, the operation of only modifying the branch identifier is lighter, so as to achieve the efficient update of blockchain fork data in the business query system.

[0074] It is understandable that the fork chain to be confirmed is continuously developing. As time goes by, the confirmed block height and the maximum block height will also be continuously updated. That is to say, the range of block heights to be confirmed is in dynamic change. Therefore, when it is detected that the confirmed block height or the maximum block height is updated, the business server will update the range of block heights to be confirmed accordingly.

[0075] In the embodiments of the present application, when a blockchain forks, the business server can synchronize the business data on the to-be-confirmed forked chain to the business database. For such business data, its data index in the business database is determined by the branch identifier and the block height; the branch identifier here can be used to identify the to-be-confirmed forked chain in the blockchain; the block height can be used to indicate the block where the business data on the to-be-confirmed forked chain is located; based on this, when the business server obtains the query information sent by the business object through the business query client, it can obtain the global branch information from the business database based on the query information; the query information carries the block query height specified by the business object; further, when the foregoing block query height is within the range of the to-be-confirmed block height, the query index can be determined based on the block query height and the branch identifier of the forked main chain; in the business database, search for the business data that matches the query index, and when the business data that matches the query index is found, the found business data can be used as the target business data, and the target business data can be sent to the business query client.

[0076] It can be seen that the embodiments of the present application can support building corresponding data indexes for any business data in the business database. For example, the data index corresponding to the business data on the to-be-confirmed forked chain can include the branch identifier of the to-be-confirmed forked chain and the block height of the block where the business data is located, for the business object to perform personalized queries, thereby enriching the query dimensions of the business, and the global branch information can be used to indicate the current forked main chain and the range of the to-be-confirmed block height. In this way, when the business object queries the business data within the range of the to-be-confirmed block height in the business database, the query index can be determined based on the block query height and the branch identifier of the forked main chain. At this time, the business data (i.e., the foregoing target business data) found in the business database that matches the query index is actually consistent with the relevant business data on the valid forked chain (i.e., the forked main chain) selected by the blockchain node, thereby ensuring the consistency of the external display of the business data in the business database and improving the query experience of the business object.

[0077] For ease of understanding, further, please refer to Figure 2 , Figure 2 which is a schematic diagram of a data processing scenario provided by the embodiments of the present application. As Figure 2 shown, the user 21a can be used as the foregoing business object, the client 21b associated with the user 21a can be used as the foregoing business query client, and the terminal device 21 where the client 21b is located can be used as the foregoing business terminal. As Figure 2The shown server 22 can be used as the aforementioned business server, and the blockchain network 20 can be used as the aforementioned blockchain network. Multiple blockchain nodes can be deployed in the blockchain network 20. For example, the multiple blockchain nodes here can specifically include node 20a, node 20b, node 20c, and node 20d. These multiple blockchain nodes can be used to jointly maintain the blockchain 20e.

[0078] As Figure 2 shown, the server 22 can synchronize the business data on the blockchain 20e to the database 22a it runs. The database 22a can be used as the aforementioned business database. It can be understood that when the blockchain 20e forks, the server 22 can also synchronize the business data on all the fork chains to the database 22a. For example, assume that at the block height of 2, two different blocks (such as block 3a and block 3b) compete for the same position, and the blockchain 20e splits into two fork chains, namely fork chain E1 and fork chain E2. As new blocks are continuously added to the chain, these two fork chains are also continuously growing. Each fork chain can contain one or more blocks. The number of blocks on the fork chain is not restricted here. For example, fork chain E1 can contain block 3a, block 4a, and block 5a, and fork chain E2 can contain block 3b, block 4b. When the blockchain nodes in the blockchain network 20 have not confirmed a certain fork chain, both fork chain E1 and fork chain E2 here can be used as the aforementioned to-be-confirmed fork chains. Therefore, the server 22 can store the business data on fork chain E1 and the business data on fork chain E2 in the database 22a. The business data here can include block header information, transaction data, contract data, account information, or other derivative data. The specific content of the business data is not restricted here.

[0079] Among them, the data indexes corresponding to the business data on the aforementioned two fork chains in the database 22a can be determined by the branch identifier and the block height. For example, as Figure 2As shown, assuming that the branch identifier of the fork chain E1 is 1 and the branch identifier of the fork chain E2 is 2, in the database 22a, the data index corresponding to the service data 2a synchronized from the block 3a (block height is 2) on the fork chain E1 can be configured as 2_…_1, that is, this data index can include the branch identifier of the fork chain E1 (i.e., 1) and the block height of the block 3a (i.e., 2). In addition, optionally, it can also include other information related to the service data 2a (i.e., the content represented by the ellipsis “…”), for example, when the service data 2a is transaction data, the corresponding data index can also include the transaction index of the service data 2a in the block 3a. Similarly, the data index corresponding to the service data 2b synchronized from the block 4a (block height is 3) on the fork chain E1 can be configured as 3_…_1, that is, this data index can include the branch identifier of the fork chain E1 (i.e., 1) and the block height of the block 4a (i.e., 3); the data index corresponding to the service data 2c synchronized from the block 5a (block height is 4) on the fork chain E1 can be configured as 4_…_1, that is, this data index can include the branch identifier of the fork chain E1 (i.e., 1) and the block height of the block 5a (i.e., 4); the data index corresponding to the service data 2d synchronized from the block 3b (block height is 2) on the fork chain E2 can be configured as 2_…_2, that is, this data index can include the branch identifier of the fork chain E2 (i.e., 2) and the block height of the block 3b (i.e., 2); the data index corresponding to the service data 2e synchronized from the block 4a (block height is 3) on the fork chain E2 can be configured as 3_…_2, that is, this data index can include the branch identifier of the fork chain E2 (i.e., 2) and the block height of the block 4b (i.e., 3).

[0080] It should be noted that different information included in the data index in the foregoing example (such as between the branch identifier and the block height) can be spliced through the underscore “_”. In practical applications, in addition to the underscore, other specified special characters or symbols (such as dash, long dash, middle dot, etc.) can also be used for splicing, so that the spliced result (i.e., the data index) will not be repeated with the normal service data, thereby constructing an effective data index. The specific form of the data index is not limited here.

[0081] Such as Figure 2As shown, when user 21a hopes to query the required business data in database 22a, the corresponding query information 21c can be sent to server 22 through client 21b on terminal device 21. The query information 21c carries the block height 21d specified by user 21a for query. This block height 21d can be used as the aforementioned block query height. For example, when the block height 21d is 3, it means that user 21a hopes to query the business data of the block with block height 3 (i.e., the aforementioned block 4a or block 4b). When server 22 receives the query information 21c sent by client 21b, based on the block height 21d carried in the query information 21c, it can be known that the current query of user 21a is a query based on the block height. Since the business data on the fork chain E1 and the fork chain E2 are stored in database 22a at the same time, in order to ensure the accuracy of data query, server 22 can obtain the global branch information 22b from database 22a. Through the global branch information 22b, the branch identifier 22d of the current fork main chain and the range of block heights to be confirmed 22e can be known.

[0082] For example, assume that the fork main chain jointly selected by each blockchain node (such as node 20a, node 20b, node 20c, and node 20d) in blockchain network 20 is the fork chain E1. Then, at this time, the branch identifier 22d in the global branch information 22b is the branch identifier of the fork chain E1 (i.e., 1). The range of block heights to be confirmed 22e is determined by the confirmed block height of blockchain 20e (such as 1, i.e., the block height of the aforementioned block 2) and the maximum block height (such as 4, i.e., the block height of the aforementioned block 5a); among them, the range of block heights to be confirmed 22e can be directly indicated in the global branch information 22b, that is, the global branch information 22b directly contains the confirmed block height and the maximum block height of blockchain 20e, so that the range of block heights to be confirmed can be obtained quickly; optionally, the range of block heights to be confirmed 22e can also be indirectly indicated through the global branch information 22b. For example, Figure 2As shown, the global branch information 22b may include the target block height 22f, which is the next block height of the confirmed block height, that is, the target block height 22f = the confirmed block height + 1, and is used to indicate that for the query of service data at block heights starting from the target block height 22f (including the target block height 22f) and going forward, the branch identifier of the forked main chain (i.e., the aforementioned branch identifier 22d) needs to be used, while for the query of service data before the target block height 22f, the branch identifier of the forked main chain does not need to be used. Based on this, the server 22 can derive the range of unconfirmed block heights through the target block height 22f. For example, assuming the target block height 22f is 2, the confirmed block height can be calculated as 2 - 1 = 1 (i.e., the block height of the aforementioned block 2), and the server 22 can detect the maximum block height of the blockchain 20e (which can be directly read by calling the relevant contract interface or can be judged based on the block height where the stored service data is located. For example, the maximum block height is 4, that is, the block height of the aforementioned block 5a), and thus the range of unconfirmed block heights 22e can be obtained as (1, 4], which can reduce the data storage volume. The indication method for the range of unconfirmed block heights in the embodiments of the present application is not limited.

[0083] Wherein, when the database 22a is the aforementioned KV database, the global branch information 22b can be used as the value, and the corresponding global branch index 22c can be used as the key, that is, the global branch index 22c and the global branch information 22b are a key-value pair in the database 22a, and the server 22 can access the global branch information 22b through the global branch index 22c. The content of the global branch index 22c is not limited here. For example, the global branch index 22c may include the text information "global_branch".

[0084] It can be understood that optionally, when the block height 21d specified by the user 21a for query is within the range of unconfirmed block heights 22e, it means that the user 21a hopes to query the service data on the unconfirmed forked chain. At this time, there are two unconfirmed forked chains, namely the forked chain E1 and the forked chain E2. Specifically, the service data on the valid forked chain (i.e., the current forked main chain) needs to be found, and only in this way can the obtained result be considered valid at present. Combining the foregoing, the data index of the service data on the forked chain in the database 22a includes the corresponding branch identifier and block height. In order to obtain a query index with the same form as this data index, the server 22 can determine the query index 22g based on the block height 21d and the branch identifier 22d of the forked main chain. For example, Figure 2As shown, when the block height 21d is 3, it can be known that the block height 21d is greater than the currently confirmed block height of the blockchain 20e (i.e., 1) and less than the maximum block height of the blockchain 20e currently (i.e., 4). Thus, it can be determined that the block height 21d is within the range of the block height to be confirmed 22e. At this time, the block height 21d and the branch identifier 22d can be concatenated using a specified special character or symbol (such as an underscore) to obtain the query index 22g, such as 3_…_1. Optionally, the content represented by the ellipsis "…" here can be other information specified by the user 21a for query. For example, when the business data that the user 21a hopes to query is transaction data, in addition to specifying the aforementioned block query height (such as the block height 21d), the transaction index of the transaction data that the user hopes to query in the block where it is located can also be specified, so as to be able to find the transaction data required by the user 21a among the large amount of transaction data contained in the block.

[0085] Further, after obtaining the aforementioned query index 22g, the server 22 can search for the business data that matches the query index 22g in the database 22a, that is, the block height included in the data index corresponding to the business data needs to be consistent with the block height 21d, and the branch identifier included in the data index corresponding to the business data needs to be consistent with the branch identifier 22d. As Figure 2 shown, assuming that the query index 22g is 3_…_1, then the business data that matches 3_…_1 can be found in the database 22a as the business data 2b. It can be seen that the found business data 2b is the business data synchronized from the block 4a (block height is 3) on the fork chain E1. Since the effective fork chain selected by the current blockchain node is the fork chain E1, the found business data 2b can be considered as valid and the latest business data. At this time, the business data 2b can be used as the aforementioned target business data, and the server 22 can send the business data 2b to the client 21b.

[0086] It can be understood that, optionally, if the block height 21d specified by the user 21a for querying is not within the range of the to-be-confirmed block heights 22e, specifically, if the block height 21d is less than or equal to the aforementioned confirmed block height, it means that the user 21a hopes to query the confirmed business data, such as the business data synchronized from block 1 (block height is 0) or block 2 (block height is 1). At this time, it is not necessary to use the branch identifier 22d of the forked main chain, and the query index can be determined based on the block height 21d, because the business data that has been confirmed on the chain is not on the to-be-confirmed forked chain. Correspondingly, the data index of these business data in the database 22 does not carry the branch identifier. Similarly, after a certain forked chain (such as forked chain E1) is confirmed by each blockchain node, the server 22 can asynchronously delete the old blockchain forked data (such as business data 2a, business data 2b, business data 2c, business data 2d, business data 2e) in the database 22, rewrite a new copy of the blockchain data (i.e., the business data on the forked chain that has been confirmed by the blockchain nodes), and the data index corresponding to the new data does not carry the branch identifier. For example, after forked chain E1 is confirmed, the data indexes corresponding to the rewritten business data 2a, business data 2b, and business data 2c will not carry the branch identifier (i.e., 1) of forked chain E1.

[0087] It can be understood that in the specific implementation of this application, the business object may need to log in to the business query client for data query only when the identity verification is passed, which involves data such as the login information of the business object (such as fingerprint information, login password, or face information entered when the business object logs in) and login configuration information (such as fingerprint information, login password, face information, etc. configured when the business object registers for identity). When the embodiments in this application are applied to specific products or technologies, the permission or consent of the business object needs to be obtained, and the collection, use, and processing of relevant data need to comply with the relevant regulations and standards in the relevant region. For example, a prompt interface or pop-up window can be displayed, which is used to prompt that the entity object is currently collecting data such as login information or login configuration information. Only after obtaining the confirmation operation of the business object on the prompt interface or pop-up window, the relevant steps for data acquisition are started, otherwise it ends.

[0088] It should be noted that the method provided in the embodiments of this application is applicable to various external systems (such as KV storage systems) that provide blockchain data query services, involving fields such as finance, payment, gaming, and office work. It can quickly update the blockchain forked data in the external system and ensure the consistency of the external display throughout the process. Using the method provided in the embodiments of this application helps to improve the accuracy and reliability of the external system and enhance the user's query experience. In addition, the external system can enrich the query dimensions of the business by constructing various indexes.

[0089] Further, please refer to Figure 3 , Figure 3 , which is a schematic flow chart of a data processing method provided by an embodiment of the present application Figure 1 . As Figure 3 shown, this method can be executed by a business server, which is used to synchronize business data on the blockchain to the business database. For example, the business server can be the server 22 shown above Figure 2 . Specifically, this method can include the following steps S101-S103

[0090] Step S101, when query information sent by a business object through a business query client is obtained, based on the query information, global branch information is obtained from the business database

[0091] It can be understood that when a fork occurs in the blockchain, the blockchain may include multiple pending fork chains to be confirmed, and the number of pending fork chains to be confirmed is not limited here. In this case, the business server can store the business data on all pending fork chains in the business database. The data index of the business database is determined by the branch identifier and the block height. Among them, for the business data that has not been confirmed by the blockchain nodes in the blockchain network (i.e., the business data on the pending fork chain, such as the business data 2a shown above Figure 2 ), there will be many under the same block height, and these business data are synchronized from different pending fork chains. For example, as Figure 2As shown below, taking the block header information on the synchronous fork chain E1 and the fork chain E2 as an example, the block header information synchronized to the database 22a may include: the block height is 2, the block header information on the fork chain E1 (i.e., the block header information of block 3a), the block height is 2, the block header information on the fork chain E2 (i.e., the block header information of block 3b), the block height is 3, the block header information on the fork chain E1 (i.e., the block header information of block 4a), the block height is 3, the block header information on the fork chain E2 (i.e., the block header information of block 4b), the block height is 4, the block header information on the fork chain E1 (i.e., the block header information of block 5a); for another example, taking the transaction data on the synchronous fork chain E1 and the fork chain E2 as an example, the transaction data synchronized to the database 22a may include: the block height is 2, the transaction index is 1, the transaction data on the fork chain E1 (i.e., the first transaction data in block 3a), the block height is 2, the transaction index is 2, the transaction data on the fork chain E1 (i.e., the second transaction data in block 3a), …, the block height is 2, the transaction index is 1, the transaction data on the fork chain E2 (i.e., the first transaction data in block 3b), the block height is 2, the transaction index is 2, the transaction data on the fork chain E2 (i.e., the second transaction data in block 3b), …, and so on. Therefore, it is necessary to use branch identifiers for differentiation, that is, the data indexes of these business data in the business database may include branch identifiers and block heights. Here, the branch identifier can be used to identify the to-be-confirmed fork chain in the blockchain, and the block height can be used to indicate the block where the business data on the to-be-confirmed fork chain is located; for the business data that has been confirmed by the blockchain node, that is, the business data on the confirmed block main chain (the block main chain is the part of the blockchain other than the to-be-confirmed fork chain, such as the business data in block 1 and block 2 shown above), its data index in the business database may include the block height and does not include the branch identifier. Here, the block height can be used to indicate the block where the confirmed business data is located. By constructing the data index in the above manner, the confirmed business data and the unconfirmed business data can be distinguished. Figure 2 As shown above, the business data in block 1 and block 2

[0092] Among them, when the business server synchronizes the business data on the blockchain, it may involve contract calls. For example, when synchronizing the contract data related to a certain business contract, the business server can send a data synchronization request to the blockchain node. This data synchronization request is used to instruct the blockchain node to call this business contract and send the contract data related to this business contract to the business server. After the business server receives these contract data, it can store them as business data in the business database.

[0093] Optionally, the service server may synchronize service data from the blockchain at regular intervals; or, optionally, the service server may synchronize service data from a new block when it detects that a new block has been generated on the blockchain. The embodiments of the present application do not limit the data synchronization method.

[0094] It can be understood that when a service object (such as the aforementioned user 21a) wishes to query service data in the service database, it may send a query message (such as the aforementioned query message 21c) to the service server (such as the aforementioned server 22) through a service query client (such as the aforementioned client 21b). For example, the service query client may obtain the query information specified by the service object in response to a query operation on a relevant interface (such as a query interface), and then send the query information to the service server. The method for specifying the query information is not limited here. For example, the service object may enter the query information in a search box on the query interface. The embodiments of the present application will be described by taking data query based on block height as an example. At this time, the query message carries the block query height specified by the service object (such as the aforementioned block height 21d). In addition, other information specified by the service object for query (such as a transaction index) may also be carried, which is not limited herein.

[0095] Among them, the aforementioned query operation may include, but is not limited to, a gesture operation, a voice signal input operation, etc.; among them, the gesture operation may include, but is not limited to: a click operation, a double-click operation (such as an operation of continuously clicking the same position on the interface twice within a short time (such as 3 seconds)), a long-press operation (such as a continuous pressing operation on any position on the interface), a sliding operation (such as a fast sliding operation in different directions, a sliding operation with a preset shape (such as a sliding trajectory in an "S" shape or an "L" shape, etc.)), a dragging operation, etc.; the voice signal input operation may refer to an operation of collecting a voice signal in the physical environment (i.e., the surrounding environment where the service object is located) for indicating the display of a certain interface through the microphone of the service terminal. The specific form of the query operation is not limited here.

[0096] Among them, it can be understood that when the service query client and the service server perform data interaction, a certain communication protocol (such as TCP (Transmission Control Protocol), UDP (User Data Protocol), etc.) can be adopted, and the specific communication protocol adopted here is not limited; based on the adopted communication protocol, a communication connection can be established between the service query client and the service server. Based on this, the service query client can send query information to the service server in the way of request reorganization or direct sending. For example, the service query client can reorganize the query information into a query request and then transmit the query request to the service server, that is, the service query client can access the service database through a network request. Subsequently, the service server can obtain the query information from the query request; optionally, the service query client can also directly transmit the query information to the service server, and the embodiments of the present application do not limit the specific way of query information transmission.

[0097] The embodiments of the present application adopt a method based on global branch information to process blockchain fork data. Correspondingly, when the service server obtains the query information sent by the service object through the service query client, it can obtain the global branch information (such as the aforementioned global branch information 22b) from the service database based on the query information. Here, the global branch information can be used to indicate the branch identifier of the fork main chain (such as the aforementioned branch identifier 22d) and the range of block heights to be confirmed (such as the aforementioned range of block heights to be confirmed 22e). In this way, when the service server reads service data from the service database, the service data within the range of block heights to be confirmed needs to use the branch identifier of the fork main chain, otherwise it does not need to use the branch identifier of the fork main chain. Among them, the range of block heights to be confirmed is determined by the confirmed block height and the maximum block height of the blockchain, and the service server will update the range of block heights to be confirmed accordingly as the blockchain develops, that is, when the confirmed block height is updated or the maximum block height is updated, the service server will update the range of block heights to be confirmed accordingly. Optionally, the range of block heights to be confirmed can be directly indicated in the global branch information, or, optionally, the range of block heights to be confirmed can also be indirectly indicated through the global branch information. For example, the global branch information can include the target block height, and the range of block heights to be confirmed can be derived from the target block height. The embodiments of the present application do not limit the indication method of the range of block heights to be confirmed, and the specific process can refer to the relevant description of the range of block heights to be confirmed 22e in the corresponding embodiments above. Figure 2 For details, please refer to the relevant description of the range of block heights to be confirmed 22e in the corresponding embodiments above, and will not be elaborated here.

[0098] Among them, the forked main chain is determined by blockchain nodes in the blockchain network where the blockchain is located in the to-be-confirmed forked chain. Specifically, each relevant blockchain node (such as a consensus node) can select a forked chain as the valid forked chain from multiple to-be-confirmed forked chains according to the specified main chain selection rule. If the valid forked chains selected by multiple blockchain nodes are the same, then this forked chain can be used as the current forked main chain, and the reading of blockchain data will be performed on this forked main chain. For example, optionally, a selection threshold can be set in the main chain selection rule to indicate that when the number of nodes selecting the same to-be-confirmed forked chain is greater than or equal to this selection threshold, the selected to-be-confirmed forked chain can be used as the forked main chain. There is no limitation on the value of the selection threshold here, and it can be set according to the specific situation of the blockchain network in practical applications. The embodiments of this application do not limit the main chain selection rule. For example, the longest forked chain can be selected from multiple to-be-confirmed forked chains as the forked main chain; if there are multiple forked chains with the same length, then one of them with the earliest generation timestamp can be selected as the forked main chain. For example, in combination with the Figure 2 corresponding embodiment described above, assume that 4 blockchain nodes (i.e., node 20a, node 20b, node 20c, and node 20d) in the blockchain network 20 select the longest forked chain (i.e., forked chain E1) from forked chain E1 and forked chain E2 according to the relevant main chain selection rule. Then, forked chain E1 can be used as the currently selected forked main chain. It can be understood that before the forked main chain is confirmed, the blockchain node can switch the forked main chain at any time. For example, assume that as the blockchain develops, at a certain moment, the length of forked chain E2 exceeds the length of forked chain E1. At this time, according to the relevant main chain selection rule, the forked main chain can be switched from forked chain E1 to forked chain E2.

[0099] It can be understood that for the convenience of accessing the global branch information, the global branch information may also have a corresponding index in the business database, which is called the global branch index (such as the aforementioned global branch index 22c). For example, when the business database is a KV database, the global branch index serves as the Key (i.e., the key), which will not change, and the global branch information serves as the Value (i.e., the value) corresponding to the Key, which can change. The two can form a key-value pair in the business database, and the business server can quickly obtain the global branch information through the global branch index. Specifically, when the business server obtains the query information sent by the business query client through the business object, it can determine that the business object adopts the data query method based on the block height based on the block query height carried in the query information. To ensure the accuracy of data query, the global branch index can be obtained from the business database; in the business database, the global branch information can be obtained through the global branch index. The specific content of the global branch index is not limited here. For example, the global branch index may include specified text information (such as "global_branch") or identification information. Thus, accessing the global branch information through the global branch index can improve the acquisition efficiency of the global branch information.

[0100] Step S102, when the block query height is within the range of the to-be-confirmed block height, determine the query index based on the block query height and the branch identifier of the forked main chain;

[0101] It can be understood that when the block query height is within the range of the to-be-confirmed block height, it means that the business data specified by the business object for query is the business data located on the to-be-confirmed forked chain (i.e., the business data not confirmed by the blockchain node). To ensure that the business data queried in the business database is consistent with the business data on the forked main chain, it is necessary to determine the query index (such as the aforementioned query index 22g) based on the block query height and the branch identifier of the forked main chain, that is, the query index with the same form as the data index corresponding to the business data on the forked main chain can be determined through the block query height and the branch identifier of the forked main chain.

[0102] Specifically, as can be seen from the foregoing, the range of the to-be-confirmed block height is determined by the confirmed block height and the maximum block height of the blockchain. When the block query height is greater than the confirmed block height and less than or equal to the maximum block height, it can be determined that the block query height is within the range of the to-be-confirmed block height. Furthermore, the query index can be determined by performing a splicing process on the block query height and the branch identifier of the forked main chain. An exemplary process can be seen in the relevant elaboration in the corresponding embodiment above Figure 2 corresponding to the embodiment.

[0103] It can be understood that in the business database, in addition to the block height and the branch identifier, the data index corresponding to different types of business data may also contain other information. For example, the data index corresponding to transaction data may also contain the transaction index in the block. Correspondingly, when a business object queries different types of business data, in addition to the block query height, the specified query information may also contain other relevant information. For example, when querying transaction data, the transaction index may be specified. The following takes the query of three types of business data, namely block header information, transaction data, and contract data, as examples for elaboration. The query of other types of business data can refer to the query of these three types of business data.

[0104] For example, when the block header information synchronized from the to-be-confirmed fork chain is stored in the business database, the corresponding data index may contain the block height of the block where the block header information is located and the branch identifier of the to-be-confirmed fork chain where it is located. Based on this, optionally, when the business data that the business object hopes to query is block header information, the business server can splice the block query height and the branch identifier of the main fork chain to obtain a query index for the target block header information (which can also be called the first type of query index). In this way, the subsequent business server can obtain the target block header information from the business database through this query index; where the target block header information is the block header information in the block with the block query height specified by the business object.

[0105] Another example is that when the transaction data synchronized from the to-be-confirmed fork chain is stored in the business database, the corresponding data index may contain the block height of the block where the transaction data is located, the transaction index of the transaction data in the block, and the branch identifier of the to-be-confirmed fork chain where the transaction data is located. Among them, the transaction index can be the transaction sequence number, transaction name, etc. of the transaction data in the block. A transaction index can uniquely locate a transaction data in a block. Here, the specific form of the transaction index is not restricted, and the transaction indexes of different transaction data can be the same or different. Based on this, optionally, when the business data that the business object hopes to query is transaction data, the query information may include a transaction query index, which is the transaction index of the target transaction data specified by the business object in the block with the block query height; the business server can splice the block query height, the transaction query index, and the branch identifier of the main fork chain to obtain a query index for the target transaction data (which can also be called the second type of query index). In this way, the subsequent business server can obtain the target transaction data from the business database through this query index.

[0106] For another example, when the contract data synchronized from the to-be-confirmed fork chain is stored in the business database, the corresponding data index may include the block height of the block where the contract data is located, the contract index of the contract data in the block, and the branch identifier of the to-be-confirmed fork chain where the contract data is located. Among them, the contract index may be the contract serial number of the contract data in the block, the contract data name, the contract identifier of the relevant business contract, etc. Here, the specific form of the contract index is not limited, and the contract indexes of different contract data may be the same or different. Based on this, optionally, when the business data that the business object hopes to query is contract data, the query information may include a contract query index, which is the contract index of the target contract data specified by the business object to be queried in the block with the block query height; the business server can perform splicing processing on the block query height, the contract query index, and the branch identifier of the main fork chain to obtain a query index for the target contract data (also referred to as the third type of query index). In this way, the subsequent business server can obtain the target contract data from the business database through this query index.

[0107] In addition, optionally, the business object can also query any two or three types of business data among the block header information, transaction data, and contract data. Correspondingly, the query index obtained by the business server may include any two or three of the three types of query indexes exemplified above, which will not be elaborated here.

[0108] Among them, the foregoing splicing processing can be implemented by connecting different information with specified special characters or symbols (such as underscores, dashes, long dashes, middle dots, etc.) to avoid duplication of the spliced query index with normal business data, thereby realizing effective data query. It can be seen that the embodiments of the present application can enrich the query dimension of the business by constructing various indexes.

[0109] Step S103, in the business database, search for business data that matches the query index, and when business data that matches the query index is found, use the found business data as the target business data and send the target business data to the business query client.

[0110] It can be understood that after obtaining the query index, the business server can search for business data matching the query index (such as the aforementioned query index 22g) in the business database. When business data matching the query index is found, the found business data can be used as the target business data (such as the aforementioned business data 2b), and then the target business data can be sent to the business query client. Among them, the target business data is consistent with the relevant business data on the fork main chain, thus realizing effective data query based on the block height. The business data matching the query index refers to that the information (such as block height, branch identifier, transaction index, contract index, etc.) contained in the data index corresponding to the business data is consistent with the information contained in the query index. An exemplary process can be seen in the relevant descriptions in the above Figure 2 corresponding embodiments.

[0111] It can be seen that the embodiments of the present application provide a blockchain data synchronization storage and acquisition scheme in a fork blockchain. When the blockchain forks, the business server can save all the fork chains that have not been confirmed by the blockchain nodes to the business database, and each fork chain can be marked with its own branch identifier during data synchronization. In this way, when synchronizing any business data on any fork chain, a corresponding data index can be constructed in the business database based on the branch identifier of the fork chain and the block height of the block where the business data is located for personalized queries by business objects, thus enriching the query dimensions of the business; in order to ensure the accuracy and reliability of business queries, global branch information can be added to the business database to indicate the branch identifier of the current fork main chain and the range of block heights to be confirmed. In this way, when a business object queries business data within the range of block heights to be confirmed in the business database, the query index can be determined based on the block height to be queried and the branch identifier of the fork main chain. It can be understood that the matching business data found in the business database through the query index is consistent with the relevant business data on the fork main chain of the blockchain at this time, thus ensuring the consistency of the display of business data in the business database to the outside when the blockchain forks, and improving the query experience of business objects.

[0112] Furthermore, please refer to Figure 4 , Figure 4 which is a flowchart of a data processing method provided by the embodiments of the present application. Figure 2 . As Figure 4 shown, this method can be executed by the business server. The method can specifically include the following steps:

[0113] Step S201, when obtaining the query information sent by the business object through the business query client, obtain the global branch information from the business database based on the query information;

[0114] Among them, for the specific implementation process of this step, reference can be made to the description of step S101 in the corresponding embodiment above. Figure 3 Details will not be elaborated here.

[0115] Step S202: When the block query height is within the range of the block height to be confirmed, determine the query index based on the block query height and the branch identifier of the fork main chain.

[0116] Among them, for the specific implementation process of this step, reference can be made to the description of step S102 in the corresponding embodiment above. Figure 3 Details will not be elaborated here.

[0117] Step S203: When the block query height is less than or equal to the confirmed block height, determine the query index based on the block query height.

[0118] It can be understood that optionally, when the block query height is less than or equal to the confirmed block height, it means that the business data specified by the business object for query is not located on the fork chain to be confirmed, that is, the business data queried by the business object is the business data that has been confirmed by the blockchain node. At this time, the query index can be determined based on the block query height, without the need to splice the branch identifier of the fork main chain. That is to say, a query index in the same form as the data index corresponding to the confirmed business data can be determined through the block query height.

[0119] Among them, there is no difference in the execution order between step S203 and the foregoing step S202, and they can be considered as parallel steps.

[0120] In addition, optionally, when the block query height is greater than the maximum block height, it means that the business data specified by the business object for query has not been uploaded to the chain yet. At this time, the business server can send a query failure prompt message to the business query client to prompt the business object that a block with this block query height has not been generated yet. The specific content of the query failure prompt message is not limited here.

[0121] Step S204: In the business database, search for business data that matches the query index, and when the business data that matches the query index is found, use the found business data as the target business data and send the target business data to the business query client.

[0122] Among them, after obtaining the query index through the foregoing step S202 or the foregoing step S203, the business server can search for business data that matches the query index in the business database, and when the business data that matches the query index is found, the found business data can be used as the target business data and sent to the business query client. For the specific implementation process of this step, reference can be made to the above...Figure 3 The description of step S103 in the corresponding embodiment will not be elaborated here.

[0123] Step S205: When it is detected that the blockchain node switches the forked main chain from the first to-be-confirmed forked chain to the second to-be-confirmed forked chain, if all the business data on the second to-be-confirmed forked chain has been stored in the business database, or the block synchronization height of the second to-be-confirmed forked chain in the business database is greater than or equal to the block synchronization height of the first to-be-confirmed forked chain in the business database, then change the branch identifier of the forked main chain in the global branch information from the branch identifier of the first to-be-confirmed forked chain to the branch identifier of the second to-be-confirmed forked chain.

[0124] It can be understood that before confirming the forked main chain, the blockchain node can switch the forked main chain at any time. Correspondingly, to ensure external consistency, the business server also needs to complete the switch of the forked main chain in the business database. For the sake of illustration, assume that the foregoing multiple to-be-confirmed forked chains include the first to-be-confirmed forked chain (such as the forked chain E1 mentioned above) and the second to-be-confirmed forked chain (such as the forked chain E2 mentioned above), and the first to-be-confirmed forked chain is different from the second to-be-confirmed forked chain; and assume that the current forked main chain is the first to-be-confirmed forked chain selected by the blockchain node among these to-be-confirmed forked chains; when it is detected that the blockchain node switches the forked main chain from the first to-be-confirmed forked chain to the second to-be-confirmed forked chain, if all the business data on the second to-be-confirmed forked chain has been stored in the business database, or the block synchronization height of the second to-be-confirmed forked chain in the business database is greater than or equal to the block synchronization height of the first to-be-confirmed forked chain in the business database, then the branch identifier of the forked main chain in the global branch information can be changed from the branch identifier of the first to-be-confirmed forked chain to the branch identifier of the second to-be-confirmed forked chain, and subsequently, the new branch identifier (i.e., the branch identifier of the second to-be-confirmed forked chain) will be used to query the business data within the range of the to-be-confirmed block height. Such a convenient switching method can quickly update the business data on the forked main chain in the business database, and at the same time, it can ensure the consistency and correctness of the external display of the business data in the business database, improving the user query experience. Here, the block synchronization height refers to the maximum block height that the to-be-confirmed forked chain has been synchronized in the business database. Limited by the data synchronization speed, the block synchronization height is less than or equal to the maximum block height on the actual to-be-confirmed forked chain. For example, as Figure 2 shown, it can be seen that at this time, the block synchronization height of the forked chain E1 in the database 22a is 4, and the block synchronization height of the forked chain E2 in the database 22a is 3. If the server 22 wants to switch the forked main chain from the forked chain E1 to the forked chain E2, then the forked chain E2 in the database 22a must at least synchronize the business data up to the block height of 4 before the branch identifier of the forked main chain can be changed.

[0125] It should be noted that, in the embodiments of the present application, the premise for modifying the branch identifier of the fork main chain in the global branch information (for example, changing the branch identifier of the foregoing fork chain E1 to the branch identifier of the fork chain E2, that is, changing the branch identifier 22d shown in Figure 2 from 1 to 2) is that the business server has stored all the business data on the new fork main chain (such as the fork chain E2) in the business database, or at least synchronized to the latest block height recorded locally in the business database (such as the block synchronization height of the foregoing fork chain E1 in the database 22a, that is, 4). Only then can the branch identifier of the fork main chain in the global branch information be modified for switching. Otherwise, even if the branch identifier of the fork main chain is modified, the correct business data may not be queryable, which will cause a bad query experience for users (such as height rollback).

[0126] Based on this, when the business object subsequently queries through the block height, the business server obtains the global branch information through the global branch index. From the changed branch identifier (such as the branch identifier of the fork chain E2) included in the global branch information, it can be known which specific fork main chain it is currently. When the queried block height is within the range of the to-be-confirmed block height, the changed branch identifier needs to be appended. It can be understood that the business database is based on the data on the blockchain. The business server can determine whether the fork main chain has been switched by detecting the latest block (or the block hash value of the latest block) on the chain, and update the global branch information when it determines that the fork main chain has been switched. Because the blockchain nodes run consensus algorithms (such as POW (i.e., proof of work), POS (i.e., proof of stake), etc.), once the fork main chain is switched, the block hash values of the same height shown externally will be different. After the business server discovers the difference, it can find out which fork chain it has specifically switched to by looking up in the business database according to the new block hash value (because each block hash value has been marked with which fork chain it belongs to through the branch identifier in advance).

[0127] In an embodiment of this application, taking the detection of the block hash value of the latest block as an example, assume that the block hash value corresponding to the block with the maximum block height on the first fork chain to be confirmed is the first block hash value (such as hash value H1). Then, the service server can obtain the block hash value corresponding to the block with the maximum block height from the blockchain and use the obtained block hash value as the second block hash value (such as hash value H2). When the second block hash value is different from the first block hash value, the service server can search in the business database for the branch identifier of the fork chain to which the block corresponding to the second block hash value belongs. If the found branch identifier is the branch identifier of the second fork chain to be confirmed, it can be determined that the blockchain node has switched the fork main chain from the first fork chain to be confirmed to the second fork chain to be confirmed. Optionally, if the found branch identifier is the branch identifier of the first fork chain to be confirmed, it can be determined that the blockchain node has not switched the fork main chain, that is, the current fork main chain is still the first fork chain to be confirmed.

[0128] Step S206: Based on the communication connection between the service query client and the service server, send a fork switching prompt message to the service query client.

[0129] It can be understood that a communication connection (such as a long connection) can be established between the service query client and the service server based on a certain communication protocol. Based on this, the service server can send a fork switching prompt message to the service query client based on the communication connection between the service query client and the service server. This fork switching prompt message can be used to indicate that the fork main chain has switched from the first fork chain to be confirmed where the target business data is located to the second fork chain to be confirmed. Here, the specific content of the fork switching prompt message is not limited. After seeing the fork switching prompt message, the business object can choose whether to query again as needed (that is, the business data originally queried on the first fork chain to be confirmed is now invalid, and the business object can choose to query the business data on the second fork chain to be confirmed again).

[0130] Optionally, the business object can choose to enable a subscription interface related to the service query system (such as enabling it through the service query client). In this way, the service query system can notify the business object which business data has been rolled back, and the business object can choose whether to query again as needed.

[0131] Step S207: When it is detected that the blockchain node has taken the fork main chain as the confirmed fork chain in the blockchain, delete the business data on the fork chain to be confirmed stored in the business database, synchronize the business data on the confirmed fork chain to the business database, and configure the global branch information stored in the business database as a null value.

[0132] It can be understood that when it is detected that a blockchain node forks the main chain as a confirmed forked chain in the blockchain, it means that the forked main chain has been confirmed by the blockchain node (i.e., the blockchain node has completed the forking process and there is no forked chain in the blockchain). At this time, the business server can delete the business data on the to-be-confirmed forked chain stored in the business database. For example, these old data (i.e., the business data on the to-be-confirmed forked chain) can be deleted asynchronously, so as to reduce the occupation of data storage space. And the business data on the confirmed forked chain can be synchronized to the business database. At this time, the data index in the business database is determined by the block height associated with the blockchain, that is, the data index of the re-written business data on the confirmed forked chain in the business database does not carry a branch identifier. That is to say, a new copy of the data (i.e., the business data on the confirmed forked chain) can be re-written, but its data index does not carry a branch identifier, which is equivalent to the local database only retaining a branch that has been confirmed on the chain. At this time, there is no such thing as a branch identifier. In this way, it can be ensured that after the forking process is completed, the data index corresponding to the business data returns to the original state, and subsequently, data can be directly queried through the specified block height without splicing the branch identifier. Correspondingly, the business server can configure the global branch information stored in the business database as a null value, which means that the forking process has been completed, and the business server can continue to query data normally. For example, it can directly query using the block height without the need to splice the branch identifier anymore.

[0133] As described above, the embodiments of the present application provide a solution for quickly updating the blockchain fork data in an external system (i.e., the business query system) and ensuring the consistency of external display. Taking the data storage method as KV storage (i.e., the business query system is a KV storage system) as an example, the business query system can directly access the corresponding data (i.e., Value) through the Key. In the business query system, all unconfirmed fork chains can be saved, and each fork chain is marked with its own branch identifier. When synchronizing any business data on the fork chain, its branch identifier and the block height of the corresponding block are written on the corresponding Key to construct the corresponding data index. Therefore, a global branch information can be added to the business query system, and this global branch information can indicate the branch identifier of the current fork main chain and the range of block heights to be confirmed. When the business object queries the business data within the range of block heights to be confirmed, the business query system needs to query by concatenating the block query height with the branch identifier of the fork main chain. Otherwise, it does not need to concatenate the branch identifier of the fork main chain and can directly query according to the block query height. When the blockchain node switches to another fork chain, the business query system only needs to modify the branch identifier of the fork main chain in the global branch information, which is equivalent to switching to another fork chain as a whole. The business query system will use the branch identifier of the new fork main chain to query the business data within the range of block heights to be confirmed. By adopting the present application, the blockchain fork data in the business query system can be quickly updated, and the consistency of external display can be ensured throughout the process, thereby improving the query experience of business objects. It should be noted that the internal work of the system (such as concatenating the branch identifier) is not perceptible to external users.

[0134] For ease of understanding, please also refer to Figure 5 , Figure 5 which is a schematic diagram of a business data query scenario provided by the embodiments of the present application. As Figure 5 shown, the user 50 can be the aforementioned business object, and the system 51 can be the aforementioned business query system. The user 50 can query any type of business data through the system 51. The embodiments of the present application will be described by taking the query of transaction data as an example. As Figure 5As shown, the system 51 stores multiple pieces of confirmed transaction data and unconfirmed transaction data synchronized from the blockchain. For example, the confirmed transaction data may specifically include transaction data a, transaction data b, transaction data c, etc. Among them, the data index corresponding to transaction data a is 3_1, which can indicate that transaction data a is the transaction data with a block height of 3 and a transaction index of 1; the data index corresponding to transaction data b is 3_2, which can indicate that transaction data b is the transaction data with a block height of 3 and a transaction index of 2; the data index corresponding to transaction data c is 3_3, which can indicate that transaction data c is the transaction data with a block height of 3 and a transaction index of 3. Similarly, the unconfirmed transaction data may specifically include transaction data d, …, transaction data e, transaction data f, transaction data g, …, transaction data h, transaction data i, transaction data j, etc. Among them, the data index corresponding to transaction data d is 5_1_1, which can indicate that transaction data d is the transaction data on fork chain 1 with a block height of 5 and a transaction index of 1; the data index corresponding to transaction data e is 10_1_2, which can indicate that transaction data e is the transaction data on fork chain 2 with a block height of 10 and a transaction index of 1; the data index corresponding to transaction data f is 10_2_2, which can indicate that transaction data f is the transaction data on fork chain 2 with a block height of 10 and a transaction index of 2; the data index corresponding to transaction data g is 10_3_2, which can indicate that transaction data g is the transaction data on fork chain 2 with a block height of 10 and a transaction index of 3; the data index corresponding to transaction data h is 10_1_3, which can indicate that transaction data h is the transaction data on fork chain 3 with a block height of 10 and a transaction index of 1; the data index corresponding to transaction data i is 10_2_3, which can indicate that transaction data i is the transaction data on fork chain 3 with a block height of 10 and a transaction index of 2; the data index corresponding to transaction data j is 10_3_3, which can indicate that transaction data j is the transaction data on fork chain 3 with a block height of 10 and a transaction index of 3.

[0135] Suppose at time T1, user 50 hopes to query the transaction data with a block height of 3 (which can be used as the aforementioned block query height) and a transaction index of 2 (i.e., index, which can be used as the aforementioned transaction query index) through system 51. At this time, the global branch information 51b obtained by system 51 through the global branch index 51a (such as global_branch) is "version:2,height:5", indicating that the current fork main chain is fork chain 2 and the target block height is 5. System 51 can determine that the block height (i.e., 3) queried by user 50 is less than the target block height, indicating that the transaction data queried by user 50 is confirmed transaction data. Therefore, system 51 can directly determine the query index 51c (i.e., 3_2) based on the block height and transaction index that user 50 hopes to query, and then can find the transaction data matching query index 51c as transaction data b (which can be used as the aforementioned target transaction data), and can return transaction data b to user 50.

[0136] For another example, suppose at time T1, user 50 hopes to query the transaction data with a height of 10 (which can be used as the aforementioned block query height) and a transaction index of 1 (which can be used as the aforementioned transaction query index) through system 51. At this time, system 51 can determine that the block height (i.e., 10) queried by user 50 is greater than the target block height. Therefore, it is necessary to additionally splice the branch identifier of the current fork main chain (i.e., 2), that is, splice the block height, transaction index that user 50 hopes to query and the branch identifier of the fork main chain into query index 51d (i.e., 10_1_2). Then, the transaction data matching query index 51d can be found as transaction data e (which can be used as the aforementioned target transaction data), and transaction data e can be returned to user 50.

[0137] Assume that at time T2, the blockchain node switches the forked main chain from forked chain 2 to forked chain 3. Correspondingly, the system 51 does not need to change the aforementioned global branch index 51a, but needs to change the global branch information 51b. For example, it is changed to global branch information 51e. For example, the global branch information 51e can be "version:3,height:5", indicating that the current forked main chain is forked chain 3 and the target block height is 5. If at this time the user 50 hopes to query the transaction data with a height of 10 (which can be used as the aforementioned block query height) and a transaction index of 1 (which can be used as the aforementioned transaction query index) through the system 51, the system 51 can determine that the block height (i.e., 10) queried by the user 50 is greater than the target block height. Therefore, it is necessary to additionally splice the branch identifier of the current forked main chain (i.e., 3), that is, splice the block height, transaction index, and the branch identifier of the forked main chain that the user 50 hopes to query into the query index 51f (i.e., 10_1_3). Furthermore, the transaction data h (which can be used as the aforementioned target transaction data) that matches the query index 51f can be found, and the transaction data h can be returned to the user 50.

[0138] It can be seen that the embodiments of the present application can quickly update the blockchain fork data in the business query system in the business database and ensure the consistency of the external display throughout the process. This helps to improve the accuracy and reliability of the business query system and provides a better query experience for business objects. In addition, the business query system provided by the embodiments of the present application can enrich the query dimensions of the business by constructing various indexes.

[0139] Please refer to Figure 6 , Figure 6 is a schematic structural diagram of a data processing device provided by an embodiment of the present application. The data processing device 1 can be applied to a business server, and the business server is used to synchronize the business data on the blockchain to the business database. For example, the business server can be the server 22 in the corresponding embodiment above; the data index of the business database here is determined by the branch identifier and the block height; the branch identifier is used to identify the to-be-confirmed forked chain in the blockchain; the block height is used to indicate the block where the business data on the to-be-confirmed forked chain is located. It should be understood that the data processing device 1 can be a computer program (including program code) running on the business server (such as the aforementioned server 22). For example, the data processing device 1 is an application software; the device can be used to execute the corresponding steps in the data processing method provided by the embodiments of the present application. As Figure 2 shown, the data processing device 1 can include: an information acquisition module 11, a first determination module 12, a data search module 13, a second determination module 14, an identifier change module 15, a fork switch module 16, a switch prompt module 17, and a fork confirmation module 18; Figure 6 As shown, the data processing device 1 may include: an information acquisition module 11, a first determination module 12, a data search module 13, a second determination module 14, an identification change module 15, a fork switching module 16, a switching prompt module 17, and a fork confirmation module 18;

[0140] An information acquisition module 11, configured to, when acquiring query information sent by a service object through a service query client, acquire global branch information from a service database based on the query information; the query information carries a block query height specified by the service object; the global branch information is used to indicate a branch identifier of a forked main chain and a range of heights of blocks to be confirmed; the range of heights of blocks to be confirmed is determined by the height of the confirmed blocks and the maximum block height of the blockchain; the forked main chain is determined by blockchain nodes in the blockchain network where the blockchain is located in the to-be-confirmed forked chain;

[0141] Specifically, the information acquisition module 11 is configured to, when acquiring query information sent by a service object through a service query client, acquire a global branch index based on the block query height carried in the query information; in the service database, acquire the global branch information through the global branch index.

[0142] A first determination module 12, configured to, when the block query height is within the range of heights of blocks to be confirmed, determine a query index based on the block query height and the branch identifier of the forked main chain;

[0143] Specifically, the first determination module 12 is configured to, when the block query height is greater than the height of the confirmed blocks and less than or equal to the maximum block height, determine that the block query height is within the range of heights of blocks to be confirmed, and determine the query index by performing a splicing process on the block query height and the branch identifier of the forked main chain.

[0144] Specifically, the first determination module 12 may include: a first splicing unit 121;

[0145] The first splicing unit 121 is configured to perform a splicing process on the block query height and the branch identifier of the forked main chain to obtain a query index for the target block header information; the target block header information is the block header information in the block with the block query height specified by the service object for query.

[0146] Specifically, the query information includes a transaction query index; the transaction query index is the transaction index of the target transaction data specified by the service object for query in the block with the block query height.

[0147] Specifically, the first determination module 12 may include: a second splicing unit 122;

[0148] The second splicing unit 122 is configured to perform a splicing process on the block query height, the transaction query index, and the branch identifier of the forked main chain to obtain a query index for the target transaction data.

[0149] Among them, the query information includes a contract query index; the contract query index is the contract index of the target contract data specified for query by the business object in the block with the block query height.

[0150] The first determination module 12 may include: a third splicing unit 123.

[0151] The third splicing unit 123 is configured to splice the block query height, the contract query index, and the branch identifier of the forked main chain to obtain a query index for the target contract data.

[0152] Among them, for the specific functional implementation manners of the first splicing unit 121, the second splicing unit 122, and the third splicing unit 123, reference may be made to the description of step S102 in the corresponding embodiment above, and details will not be elaborated here. Figure 3 The description of step S102 in the corresponding embodiment above will not be repeated here.

[0153] The data search module 13 is configured to search for business data matching the query index in the business database, and when business data matching the query index is found, use the found business data as the target business data and send the target business data to the business query client.

[0154] Among them, the apparatus further includes:

[0155] The second determination module 14 is configured to determine the query index based on the block query height when the block query height is less than or equal to the confirmed block height.

[0156] Among them, the to-be-confirmed forked chain includes a first to-be-confirmed forked chain and a second to-be-confirmed forked chain, and the first to-be-confirmed forked chain is different from the second to-be-confirmed forked chain; the forked main chain is the first to-be-confirmed forked chain selected by the blockchain node from the to-be-confirmed forked chains.

[0157] The identifier change module 15 is configured to, when it is detected that the blockchain node switches the forked main chain from the first to-be-confirmed forked chain to the second to-be-confirmed forked chain, if all the business data on the second to-be-confirmed forked chain has been stored in the business database, or the block synchronization height of the second to-be-confirmed forked chain in the business database is greater than or equal to the block synchronization height of the first to-be-confirmed forked chain in the business database, change the branch identifier of the forked main chain in the global branch information from the branch identifier of the first to-be-confirmed forked chain to the branch identifier of the second to-be-confirmed forked chain.

[0158] Among them, the block hash value corresponding to the block with the maximum block height on the first to-be-confirmed forked chain is the first block hash value.

[0159] The forking switch module 16 is configured to obtain the block hash value corresponding to the block with the maximum block height from the blockchain, and use the obtained block hash value as the second block hash value; when the second block hash value is different from the first block hash value, look up the branch identifier of the to-be-confirmed fork chain where the block corresponding to the second block hash value is located in the service database. If the found branch identifier is the branch identifier of the second to-be-confirmed fork chain, it is determined that the blockchain node switches the forking main chain from the first to-be-confirmed fork chain to the second to-be-confirmed fork chain.

[0160] The switching prompt module 17 is configured to send a forking switch prompt message to the service query client based on the communication connection between the service query client and the service server; the forking switch prompt message is used to indicate that the forking main chain is switched from the first to-be-confirmed fork chain where the target service data is located to the second to-be-confirmed fork chain.

[0161] The forking confirmation module 18 is configured to, when detecting that the forking main chain of the blockchain node is used as the confirmed fork chain in the blockchain, delete the service data on the to-be-confirmed fork chain stored in the service database; synchronize the service data on the confirmed fork chain to the service database; the data index of the service database is determined by the block height associated with the blockchain; configure the global branch information stored in the service database as a null value.

[0162] Among them, for the specific function implementation manners of the information acquisition module 11, the first determination module 12, the data search module 13, the second determination module 14, the identifier change module 15, the forking switch module 16, the switching prompt module 17, and the forking confirmation module 18, reference can be made to the descriptions of steps S101 - S103 in the corresponding embodiments above, or reference can be made to the descriptions of steps S201 - S207 in the corresponding embodiments above. Details will not be elaborated here. It should be understood that the descriptions of the beneficial effects obtained by using the same method will not be elaborated either. Figure 3 For the descriptions of steps S101 - S103 in the corresponding embodiments above, or reference can be made to the descriptions of steps S201 - S207 in the corresponding embodiments above. Details will not be elaborated here. It should be understood that the descriptions of the beneficial effects obtained by using the same method will not be elaborated either. Figure 4 Here, the descriptions will not be continued. It should be understood that the descriptions of the beneficial effects obtained by using the same method will not be elaborated either.

[0163] Please refer to Figure 7 , Figure 7 which is a schematic structural diagram of a computer device provided by an embodiment of the present application. As Figure 7As shown in the figure, the computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. In addition, the computer device 1000 may further include: a user interface 1003 and at least one communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. Among them, the user interface 1003 may include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk memory. The memory 1005 may optionally also be at least one storage device located far from the aforementioned processor 1001. As Figure 7 shown, the memory 1005, as a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0164] In the computer device 1000 as Figure 7 shown, the network interface 1004 can provide network communication functions; while the user interface 1003 is mainly used to provide an input interface for users; and the processor 1001 can be used to call the device control application program stored in the memory 1005 to execute the Figure 3 , Figure 4 description of the data processing method in any of the corresponding embodiments mentioned above, which will not be elaborated here. In addition, the description of the beneficial effects of using the same method will not be elaborated either.

[0165] In addition, it should be pointed out here that: the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores the computer program executed by the aforementioned data processing device 1, and the computer program includes computer instructions. When the processor executes the computer instructions, it can execute the Figure 3 , Figure 4 description of the data processing method in any of the corresponding embodiments mentioned above. Therefore, it will not be elaborated here. In addition, the description of the beneficial effects of using the same method will not be elaborated either. For the technical details not disclosed in the embodiment of the computer-readable storage medium involved in the present application, please refer to the description of the method embodiment of the present application.

[0166] The above computer-readable storage medium may be the data processing device provided in any of the foregoing embodiments or the internal storage unit of the above computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device. Further, the computer-readable storage medium may also include both the internal storage unit and the external storage device of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

[0167] In addition, it should be noted here that: The embodiments of the present application also provide a computer program product, which includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided in any one of the foregoing Figure 3 , Figure 4 corresponding embodiments. In addition, the description of the beneficial effects of the same method will not be repeated. For the technical details not disclosed in the embodiments of the computer program product involved in the present application, please refer to the description of the method embodiments of the present application.

[0168] In the embodiments of the present application, the terms "first", "second", etc. in the specification, claims and drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the term "including" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, device, product or equipment that includes a series of steps or units is not limited to the listed steps or modules, but optionally further includes steps or modules not listed, or optionally further includes other step units inherent to these processes, methods, devices, products or equipment.

[0169] In the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works with other related parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one 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 a part of the overall module or unit that includes the function of the module or unit.

[0170] Those of ordinary skill in the art will appreciate that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of the examples have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0171] It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that this application is not limited by the described action sequence, because according to this application, some steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0172] The steps in the method embodiments of this application can be adjusted, combined, and deleted according to actual needs.

[0173] The modules in the device embodiments of this application can be combined, divided, and deleted according to actual needs.

[0174] Those of ordinary skill in the art can understand that to implement all or part of the processes in the above method embodiments, it can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above method embodiments. Among them, the storage medium can be a magnetic disk, an optical disc, a read-only memory (ROM), or a random access memory (RAM), etc.

[0175] The foregoing disclosure is only for the preferred embodiments of this application, and of course cannot be used to limit the scope of rights of this application. Therefore, equivalent changes made according to the claims of this application still fall within the scope covered by this application.

Claims

1. A data processing method, characterized in that, The method is executed by a business server, which is used to synchronize business data on a blockchain to a business database; the data index of the business database is determined by a branch identifier and a block height; the branch identifier is used to identify an unconfirmed fork chain in the blockchain; the block height is used to indicate the block where the business data on the unconfirmed fork chain is located; the method includes: When query information sent by a business object through a business query client is obtained, based on the query information, global branch information is obtained from the business database; the query information carries a block query height specified by the business object; the global branch information is used to indicate the branch identifier of the main fork chain and the range of unconfirmed block heights; the range of unconfirmed block heights is determined by the confirmed block height and the maximum block height of the blockchain; the main fork chain is determined by blockchain nodes in the blockchain network where the blockchain is located in the unconfirmed fork chain; When the block query height is within the range of unconfirmed block heights, a query index is determined based on the block query height and the branch identifier of the main fork chain; In the business database, business data matching the query index is searched for, and when business data matching the query index is found, the found business data is used as target business data, and the target business data is sent to the business query client.

2. The method according to claim 1, characterized in that The step of, when query information sent by a business object through a business query client is obtained, obtaining global branch information from the business database based on the query information includes: When query information sent by a business object through a business query client is obtained, a global branch index is obtained based on the block query height carried in the query information; In the business database, global branch information is obtained through the global branch index.

3. The method according to claim 1, wherein The step of, when the block query height is within the range of unconfirmed block heights, determining a query index based on the block query height and the branch identifier of the main fork chain includes: When the block query height is greater than the confirmed block height and the block query height is less than or equal to the maximum block height, it is determined that the block query height is within the range of unconfirmed block heights, and a query index is determined by performing a splicing process on the block query height and the branch identifier of the main fork chain.

4. The method according to claim 3, characterized in that, The step of determining a query index by performing a splicing process on the block query height and the branch identifier of the main fork chain includes: Performing a splicing process on the block query height and the branch identifier of the main fork chain to obtain a query index for target block header information; the target block header information is the block header information in the block with the block query height specified by the business object for query.

5. The method according to claim 3, wherein The query information includes a transaction query index; the transaction query index is the transaction index of target transaction data specified by the business object for query in the block with the block query height. Determining a query index by performing a splicing process on the block query height and the branch identifier of the forked main chain includes: Performing a splicing process on the block query height, the transaction query index, and the branch identifier of the forked main chain to obtain a query index for the target transaction data.

6. The method according to claim 3, wherein The query information includes a contract query index; the contract query index is the contract index of the target contract data specified by the business object to be queried in the block with the block query height. Determining a query index by performing a splicing process on the block query height and the branch identifier of the forked main chain includes: Performing a splicing process on the block query height, the contract query index, and the branch identifier of the forked main chain to obtain a query index for the target contract data.

7. The method according to claim 1, wherein It further includes: When the block query height is less than or equal to the confirmed block height, determining a query index based on the block query height.

8. The method according to claim 1, wherein The to-be-confirmed forked chain includes a first to-be-confirmed forked chain and a second to-be-confirmed forked chain, and the first to-be-confirmed forked chain is different from the second to-be-confirmed forked chain. The forked main chain is the first to-be-confirmed forked chain selected by the blockchain node from the to-be-confirmed forked chains. The method further includes: When it is detected that the blockchain node switches the forked main chain from the first to-be-confirmed forked chain to the second to-be-confirmed forked chain, if all the business data on the second to-be-confirmed forked chain has been stored in the business database, or the block synchronization height of the second to-be-confirmed forked chain in the business database is greater than or equal to the block synchronization height of the first to-be-confirmed forked chain in the business database, then change the branch identifier of the forked main chain in the global branch information from the branch identifier of the first to-be-confirmed forked chain to the branch identifier of the second to-be-confirmed forked chain.

9. The method according to claim 8, wherein The block hash value of the block with the maximum block height on the first to-be-confirmed forked chain is the first block hash value. The method further includes: Obtaining the block hash value corresponding to the block with the maximum block height from the blockchain, and using the obtained block hash value as the second block hash value. When the second block hash value is different from the first block hash value, searching in the business database for the branch identifier of the to-be-confirmed forked chain where the block corresponding to the second block hash value is located. If the found branch identifier is the branch identifier of the second to-be-confirmed forked chain, then determine that the blockchain node switches the forked main chain from the first to-be-confirmed forked chain to the second to-be-confirmed forked chain.

10. The method according to claim 8, wherein It further includes: Sending a forked chain switching prompt message to the business query client based on the communication connection between the business query client and the business server; the forked chain switching prompt message is used to indicate that the forked main chain switches from the first to-be-confirmed forked chain where the target business data is located to the second to-be-confirmed forked chain.

11. The method according to claim 1 or 8, characterized in that, It further includes: When it is detected that the blockchain node takes the forked main chain as the confirmed forked chain in the blockchain, delete the business data on the to-be-confirmed forked chain stored in the business database; Synchronize the business data on the confirmed forked chain to the business database; the data index of the business database is determined by the block height associated with the blockchain; Configure the global branch information stored in the business database as a null value.

12. A data processing device, characterized in that, The device runs on a business server, and the business server is used to synchronize the business data on the blockchain to the business database; the data index of the business database is determined by the branch identifier and the block height; the branch identifier is used to identify the to-be-confirmed forked chain in the blockchain; The block height is used to indicate the block where the business data on the to-be-confirmed forked chain is located; the device includes: An information acquisition module, configured to, when acquiring query information sent by a business object through a business query client, based on the query information, acquire global branch information from the business database; the query information carries the block query height specified by the business object; the global branch information is used to indicate the branch identifier of the forked main chain and the range of to-be-confirmed block heights; the range of to-be-confirmed block heights is determined by the confirmed block height and the maximum block height of the blockchain; the forked main chain is determined by the blockchain nodes in the blockchain network where the blockchain is located in the to-be-confirmed forked chain; A first determination module, configured to, when the block query height is within the range of to-be-confirmed block heights, determine a query index based on the block query height and the branch identifier of the forked main chain; A data search module, configured to search for business data matching the query index in the business database, and when business data matching the query index is found, use the found business data as target business data and send the target business data to the business query client.

13. A computer device, characterized in that, Including: A processor and a memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method according to any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, and the computer program is suitable for being loaded and executed by a processor so that a computer device having the processor executes the method according to any one of claims 1-11.

15. A computer program product, characterized in that, The computer program product includes computer instructions, and the computer instructions are stored in the computer-readable storage medium. The computer instructions are suitable for being read and executed by a processor so that a computer device having the processor executes the method according to any one of claims 1-11.

Images