A blockchain-based data processing method and related products

Abstract

Embodiments of the present application disclose a data processing method based on a blockchain and related products. The data processing method based on the blockchain comprises: synchronizing blockchain data in a blockchain system, the blockchain system being connected to a target business system that has registered a push service, and a push commitment contract being deployed in the blockchain system, the push commitment contract containing a callback commitment of the target business system; obtaining target business data associated with the target business system based on the callback commitment; and pushing the target business data to the target business system. According to the embodiments of the present application, the target business data can be actively pushed to the target business system that has registered the push service based on the push commitment contract, so that the system performance consumption is effectively reduced, and the real-time performance of the business system in obtaining the business data is improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain-based data processing method, a blockchain-based data processing device, a computer device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Blockchain is characterized by decentralization, immutability, transparency and openness. Through technologies such as distributed ledgers, encryption algorithms, peer-to-peer transmission and consensus mechanisms, blockchain technology can solve the problem of information asymmetry and has wide applications in fields such as digital asset trading, supply chain, and smart manufacturing.

[0003] Business systems and blockchain systems can jointly provide services to business stakeholders. Typically, when using a business system to process business transactions, stakeholders may need to access information stored in the blockchain system. In practical applications, determining the appropriate processing mechanism to enable the business system to obtain the necessary business data is a question that requires further research. Summary of the Invention

[0004] This application provides a blockchain-based data processing method and related products, which can proactively push target business data to target business systems that have registered push services based on push commitment contracts, thereby effectively reducing system performance consumption and improving the real-time acquisition of business data by business systems.

[0005] One embodiment of this application provides a blockchain-based data processing method, including:

[0006] Synchronize blockchain data in the blockchain system. The blockchain system is connected to the target business system that has registered push services. The blockchain system has a push commitment contract deployed, which contains a callback commitment from the target business system.

[0007] Retrieve target business data associated with the target business system based on callback commitments; and

[0008] Push the target business data to the target business system.

[0009] One embodiment of this application provides a blockchain-based data processing device, including:

[0010] The synchronization module is used to synchronize blockchain data in the blockchain system. The blockchain system is connected to the target business system that has registered push services. The blockchain system has a push commitment contract deployed, which contains the callback commitment of the target business system.

[0011] The acquisition module is used to acquire target business data associated with the target business system based on callback commitments; and,

[0012] The push module is used to push target business data to the target business system.

[0013] One embodiment of this application provides a computer device, including: a processor and a memory; the processor is connected to the memory and a network interface, wherein the network interface is used to provide network communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the blockchain-based data processing method in this embodiment of the application.

[0014] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it performs the blockchain-based data processing method described in this application.

[0015] This application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the steps of the blockchain-based data processing method of this application.

[0016] In this embodiment, the blockchain system can access target business systems that have registered push services. The callback commitments of the target business systems can be managed by push commitment contracts deployed within the blockchain system. By synchronizing blockchain data within the blockchain system, the push commitment contract can be synchronized. This contract contains callback commitments agreed upon between the blockchain system and the target business system. Based on these callback commitments, business data associated with the target business system can be obtained and proactively pushed to it. In this way, external target business systems do not need to actively access the blockchain system. Instead, they register for push services and agree on callback commitments with the blockchain system. The blockchain system then proactively and in real-time pushes target business data associated with the target business system to the target business system, thus avoiding polling and synchronization of data between various business systems. This proactive push service not only effectively reduces system performance consumption but also enables rapid integration between blockchain data and business systems, improving the real-time availability of business data for the business systems. Attached Figure Description

[0017] Figure 1a This is a schematic diagram of a data sharing system provided in an embodiment of this application;

[0018] Figure 1b This is a schematic diagram of a block composition structure provided in an embodiment of this application;

[0019] Figure 1c This is a flowchart illustrating the generation of a new block according to an embodiment of this application;

[0020] Figure 2aThis is an architecture diagram of a blockchain system provided in an embodiment of this application;

[0021] Figure 2b This is a schematic diagram illustrating an exemplary layered deployment of a blockchain-based data processing system provided in an embodiment of this application;

[0022] Figure 3 This is a schematic flowchart of a blockchain-based data processing method provided in an exemplary embodiment of this application;

[0023] Figure 4 This is a schematic diagram of a data processing method based on blockchain provided in an exemplary embodiment of this application;

[0024] Figure 5 This is an interactive schematic diagram of a blockchain-based data processing method provided in an exemplary embodiment of this application;

[0025] Figure 6 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an exemplary embodiment of this application;

[0026] Figure 7 This is a schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application. Detailed Implementation

[0027] To better understand the solutions of the embodiments of this application, the relevant terms and concepts that may be involved in the embodiments of this application will be introduced below.

[0028] PKI stands for Public Key Infrastructure, which is a public key certificate system. It mainly includes public and private key cryptography, x509 certificates, and Certificate Authorities (CAs). The core of PKI is the issuance of identity certificates, enabling trusted network communication.

[0029] Certificate: In this embodiment, the term refers to a Public Key Infrastructure (PKI) system. In a certificate system, a certificate is proof of identity for the owner of a public key, issued by an authoritative authority (CA). Asymmetric encryption and digital signatures for information can be achieved based on a public key certificate system.

[0030] P2P network: A peer-to-peer network based on a specific network protocol. Instead of a central node to maintain the network state, each node maintains the overall network state or the connection state of its neighboring nodes through broadcast interactions with neighboring nodes.

[0031] SPV node: Simplified Payment Verification, a type of simple payment verification node. SPV nodes do not store the entire blockchain data, but they do store all block headers.

[0032] KA: Key Account, key customer.

[0033] Smart contracts: A smart contract is a computer protocol that can be used for transactions and / or any exchange between two or more parties. A smart contract is computer-generated code that contains conditions that trigger the automatic execution of the contract. As one of the core technologies of blockchain, smart contracts allow for trusted transactions without the need for a third party.

[0034] This application relates to blockchain, a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0035] A blockchain system can generally be viewed as a data-sharing system. See also... Figure 1a The data sharing system shown, data sharing system 100, refers to a system for data sharing between nodes. This data sharing system may include multiple nodes 101, which can refer to various clients within the data sharing system. Each node 101, during normal operation, can receive input information and maintain shared data within the data sharing system based on the received input information. To ensure information interoperability within the data sharing system, information connections can exist between each node, allowing information transmission between nodes. For example, when any node in the data sharing system receives input information, other nodes in the system obtain this input information according to a consensus algorithm and store it as data in the shared data, ensuring consistency of data stored on all nodes in the data sharing system.

[0036] Each node in the data sharing system has a corresponding node identifier, and each node can also store the node identifiers of other nodes in the data sharing system. This allows for the subsequent broadcasting of generated blocks to other nodes in the data sharing system based on their node identifiers. Each node can maintain a node identifier list as shown in the table below, storing the node name and node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 only uses IP addresses as an example.

[0037] Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0038] For a schematic diagram of the data sharing system related to the embodiments of this application, please refer to the following. Figure 2a The blockchain system shown is a data-sharing system comprising a sharing network and a witness network. Each node in the data-sharing system stores an identical copy of the blockchain. The blockchain consists of multiple blocks; see [link to relevant documentation]. Figure 1b A blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores input information feature values, version number, timestamp, and difficulty value, while the block body stores the input information. The next block after the genesis block takes the genesis block as its parent block. The next block also includes a block header and a block body. The block header stores the input information feature values ​​of the current block, the block header feature values ​​of the parent block, version number, timestamp, and difficulty value, and so on. This ensures that the block data stored in each block is related to the block data stored in the parent block, guaranteeing the security of the input information in the blocks.

[0039] When generating the individual blocks in the blockchain, see Figure 1c When a node in the blockchain receives input information, it verifies the input information. After verification, it stores the input information in a memory pool and updates its hash tree used to record the input information. Then, it updates the timestamp to the time the input information was received and tries different random numbers multiple times to calculate the feature value, ensuring that the calculated feature value satisfies the following formula:

[0040] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0041] Wherein, SHA256 is the feature value algorithm used to calculate the feature value; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header feature value of the parent block of the current block; merkle_root is the feature value of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value for a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the feature value threshold, which can be determined based on nbits.

[0042] Thus, when a random number satisfying the above formula is calculated, the information can be stored accordingly, generating a block header and block body to obtain the current block. Subsequently, the node containing the blockchain sends the newly generated block to other nodes in its data sharing system based on the node identifiers of other nodes in the data sharing system. These other nodes then verify the newly generated block and, after verification, add it to their stored blockchain. Examples of this application are as follows. Figure 2b The diagram illustrates the layered deployment of a blockchain-based data processing system. The consensus network comprises multiple core chains (i.e., blockchains located in the core consensus layer), and each core chain contains multiple blocks. The generation of each block within the core chain can be implemented using the methods described above.

[0043] Based on the above terminology and related introduction to blockchain, the following is provided: Figure 2a The diagram shows the architecture of the blockchain system, and as follows: Figure 2b The diagram shows a layered deployment of a blockchain-based data processing system.

[0044] Typically, blockchain products use a single-layer, unified P2P architecture, where nodes are peer-to-peer and all nodes reside within the same network. However, in certain specific scenarios, not all blockchain execution nodes possess sufficient resources or the necessity to join the blockchain consensus mechanism. For data security reasons, when privacy or security-related data is involved in the blockchain system, a universal peer-to-peer blockchain deployment may not be necessary.

[0045] like Figure 2aAs shown, the blockchain system uses a two-layer network structure, including a witness network 201 and a consensus network 202. Witness network 201 and consensus network 202 are different data-sharing systems. Witness network 201 includes one or more business nodes, each responsible for business execution but not participating in the accounting consensus. Consensus network 202 includes one or more consensus nodes, each running the consensus protocol; these consensus nodes can also be called accounting nodes. Business nodes can obtain block header data and partially authorized visible block data from the consensus network through identity authentication. Therefore, because the business nodes in the witness network do not participate in the accounting consensus, this blockchain system is an asymmetrical blockchain deployment.

[0046] It should be noted that business nodes and consensus nodes can be computer devices, which can be terminal devices or servers. For example, business nodes can be terminal devices, and consensus nodes can be servers. Terminal devices can be smartphones, tablets, smart wearable devices, smart voice interaction devices, smart home appliances, laptops, in-vehicle terminals, etc., and this application does not impose any restrictions on this. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and intelligent platforms, but are not limited to these.

[0047] As can be seen, the blockchain-based data processing solution provided in this application uses a two-layer chain, namely a p2p network forming a "witness network - consensus network" separation, to improve the confidentiality and security of data on the blockchain, and can adapt to the specific network layout requirements of relevant industry blockchain production lines, such as the separation of internal and external networks, business networks, and office networks. This network layering ensures the efficient execution of core formula algorithms.

[0048] In one embodiment, the witness network 201 and the consensus network 202 reside in different network environments. Specifically, the witness network 201 is located in a public network, while the consensus network 202 is located in a private network. Thus, business nodes are deployed in the public witness network 201, while consensus nodes are deployed in the private consensus network 202. Optionally, the witness network 201 and the consensus network 202 interact via a routing boundary. This is because the consensus network 202 is located in a relatively secure private cloud, and the communication between consensus nodes in the consensus network 202 is secure due to a consensus mechanism, eliminating the need for additional identity management and network control. In contrast, business nodes are located in a public network and may be accessed by other unidentified network terminals. Therefore, the access behavior of business nodes and other potential nodes to the consensus network can be strictly controlled to ensure secure access.

[0049] Please see Figure 2b , Figure 2b This is a schematic diagram illustrating an exemplary layered deployment of a blockchain-based data processing system provided in an embodiment of this application. For example... Figure 2b As shown, the system includes a blockchain system 210 and at least one business system connected to the blockchain system 210. The at least one business system may include a business system that has registered for the push service. The blockchain system 210 includes a business layer 10, a routing proxy layer 11, and a core consensus layer 12. The business layer 10 corresponds to... Figure 2a The Witness Network 201 shown corresponds to the core consensus layer as follows: Figure 2a In the consensus network 202 shown, the business layer 10 can submit business operation interactions to the core consensus layer 12 through the routing proxy layer 11. The routing proxy layer 11 is used to isolate the business layer 10 and the core consensus layer 12, and to provide a secure access mechanism for the business nodes in the business layer 10 to access the consensus nodes in the core consensus layer 12, which are TrustSQL nodes (also known as trusted nodes).

[0050] Taking an e-invoice business node as an example, specifically, the business nodes in business layer 10 are located in the tax intranet, public cloud, and private cloud, respectively. The tax intranet includes local tax bureaus, the public cloud includes invoicing service providers, reimbursement service providers, and key account (KA) entities, and the private cloud includes payment service providers, circulation service providers, and KA entities. Each business node can be a terminal device, such as an invoicing service provider terminal. Different types of business nodes can correspond to different business systems. For example, local tax bureaus can correspond to the e-tax bureau business system, business nodes in the public cloud can correspond to service business systems, and business nodes in the private cloud can correspond to consumer business systems. Different business systems can belong to the application layer. In one embodiment, a business node in business layer 10 can register a push service with a push commitment contract deployed in the consensus network and be configured as a push service node after successful registration. Business systems can register push services with push commitment contracts deployed in the consensus network. In this way, push service nodes allocated by the push commitment contract can provide push services to them. For example, if the push service is an invoice push service, then the push service nodes can push the latest invoice data on the blockchain to the business systems that have registered push services in real time.

[0051] The routing proxy layer 11 includes at least one proxy node. Each proxy node can provide P2P services, as well as an access mechanism supported by routing services, certificate caching, and authentication services. Business nodes can use this access mechanism to achieve secure access to the consensus node.

[0052] Core consensus layer 12 can be a tax-specific network containing N core chains, where N is a positive integer. This tax-specific network is a consensus network. Here, the core chain refers to the blockchain located in core consensus layer 12. The core chain includes at least one trusted node (TrustSQL node, i.e., a consensus node). Optionally, the trusted node can be various terminal devices of the State Taxation Administration. Each trusted node can store the following: blocks, permission contracts, and cache. Blocks are used to construct the blockchain; see the above for details. Figure 1b and Figure 1c The introduction states that a permission contract is a smart contract that controls access to operations. Optionally, a permission contract may include a push commitment contract. This push commitment contract is used to maintain the registration of push services and to allocate push service nodes to business systems that have registered push services.

[0053] In this embodiment, the blockchain system 210 can connect to different business systems, specifically through business nodes interfacing with different business systems. These business systems may include those that have registered push services. The blockchain system 210 includes business nodes registered as push service nodes. For any business system (i.e., the target business system) connected to the blockchain system 210 and registered with push services, the push service node connecting to that target business system can synchronize blockchain data within the blockchain system. This blockchain data may include a push commitment contract deployed within the blockchain system. Based on the callback commitment to the target business system contained in the push commitment contract, target business data associated with the target business system can be obtained and pushed to that target business system. This achieves the function of the blockchain system proactively pushing business data to business systems that require push services. Proactive pushing avoids polling the blockchain system by business systems, reducing the performance consumption of the entire blockchain-based data processing system. Furthermore, proactive pushing enables rapid integration of blockchain data with business systems, improving the real-time availability of business data for business systems.

[0054] It is understood that in the specific implementation of this application, data such as business data and invoice data are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the target (e.g., business party) is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0055] The specific implementation of the blockchain-based data processing method proposed in this application embodiment will be described in detail below with reference to the accompanying drawings. It should be noted that, since the blockchain system can access at least one business system that has registered a push service, in this application embodiment, any one of the at least one registered push service business system is taken as the target business system for blockchain system access to illustrate the details of this solution.

[0056] Please see Figure 3 , Figure 3 This is a schematic flowchart of a blockchain-based data processing method provided in an exemplary embodiment of this application. This blockchain-based data processing method can be implemented using a computer device (such as...) Figure 2a The data processing method, which is executed by the business nodes that have registered the push service in the witness network shown, includes, but is not limited to, the following steps.

[0057] S301 synchronizes blockchain data within the blockchain system.

[0058] The blockchain system connects to target business systems that have registered push services, and a push commitment contract is deployed in the blockchain system. The push commitment contract contains a callback commitment from the target business system.

[0059] A blockchain system can connect to one or more business systems that have registered push services. A push service refers to a service where the blockchain system actively pushes business data to a business system, such as an invoice push service. A business system connecting to the blockchain system means that the business system has established a connection with the blockchain system. Optionally, the target business system can be any business system that has connected to the blockchain system and has registered for a push service. That is, the target business system can be any of the one or more business systems that have registered push services connected to the blockchain system. Before implementing this solution, the target business system must meet the following conditions: it must have established a connection with the blockchain system and have registered for a push service.

[0060] In one embodiment, the blockchain system includes a witness network and a consensus network, wherein the witness network contains one or more business nodes, and the consensus network contains one or more consensus nodes. For an introduction to the witness network and the consensus network, please refer to [link to relevant documentation]. Figure 2a and Figure 2b The corresponding content is described below. A push promise contract (i.e., a Promise contract) deployed in a blockchain system is a smart contract responsible for maintaining the registration of push services and the allocation of push service nodes. Push service nodes are business nodes that can be used to execute push services. This push promise contract can be deployed on, for example,... Figure 2a In the consensus network shown, more specifically, it can be deployed on, for example... Figure 2b The core chain shown is the blockchain located in the core consensus layer.

[0061] Optionally, the blockchain-based data processing method provided in this application is executed by the target push service node corresponding to the target business system; the target push service node is any one of one or more push service nodes corresponding to the target business system; the push commitment contract also contains the identifiers of M push service nodes that have registered push services; the push commitment contract is used to allocate one or more push service nodes to the target business system from the M push service nodes; M is a positive integer.

[0062] In addition to callback promises, the push commitment contract may also contain identifiers of M push service nodes that have registered with the push service. These M push service nodes can be business nodes of the registered push service. The push commitment contract can allocate one or more push service nodes to the target business system, and these nodes can be selected from the M registered push service nodes. Since the push commitment contract can allocate one or more push service nodes to the target business system, the target business system can have one or more corresponding push service nodes providing push services. Specifically, the target push service node can be any one of the one or more push service nodes allocated by the push commitment contract to the target business system. The push service node can be an SPV node used to execute the push service.

[0063] After any of the M push service nodes is assigned to the corresponding business system by the push commitment contract, the identifier of the push service node can be mapped to the identifier of the target business system. The identifier of the target business system is, for example, the Uniform Resource Locator (URL) of the business system. For example, if the target business system is business system B1, and the push service nodes assigned to business system B1 are SPV1 and SPV2, then B1 establishes a mapping relationship with SPV1 and SPV2. Through this mapping relationship, when executing the push service, the target business system to be connected can be quickly determined based on the identifier of the target push service node, so as to obtain the associated target business data and actively push the obtained target business data to the target business system.

[0064] In one embodiment, the push commitment contract is deployed on the consensus node; when any business node registers a push service with the push commitment contract, the registered business node is configured as a push service node; the business node configured as a push service node is used to perform push services exclusively; or, it is used to perform push services and business processing simultaneously.

[0065] For an introduction to blockchain systems, please refer to the aforementioned text. Figure 2aAlternatively, as shown in 2b, the push commitment contract deployed in the blockchain system is specifically deployed within the consensus nodes of the consensus network. Any business node in the witness network can register a push service with the push commitment contract in the consensus network. After successful registration, the business node can be configured as a push service node. This process is also the process by which the business node registers its identity as a push service node with the push commitment contract. A business node configured as a push service node can be used to: exclusively execute push services, or simultaneously execute push services and business processing. That is, a push service node can be a newly added business node in the witness network specifically for executing push services. In this case, the business node does not have the ability to perform other business processing. By adding a new business node specifically for handling push services, the overall processing performance of the system for simultaneously performing business processing and push services can be improved. A push service node can also be a business node in the witness network that handles push services on top of handling other business processes. That is, the push service node simultaneously undertakes the functions of executing push services and handling other business processes. For example, a push service node can not only push invoice data, but also return query data to the business system in response to query requests. In this way, a business node can maximize its utilization by handling different business processes, thereby improving the utilization rate of the business node.

[0066] It should be noted that any business node that registers its push service with the push commitment contract can be configured as a push service node, resulting in M ​​push service nodes. A node configured as a push service node is a node that can be used to execute push services; it can only be actually used after the push commitment contract assigns it to the corresponding business system.

[0067] In one implementation, the allocation rules followed by the push commitment contract when allocating one or more push service nodes from M push service nodes to the target business system include any one or more of the following: ① Based on the load of the M push service nodes, select one or more push service nodes with loads below a threshold and allocate them to the target business system. ② Based on the processing capacity reported by the M push service nodes, select push service nodes from the M push service nodes that match the amount of push service data registered in the callback commitment and allocate them to the target business system.

[0068] For the first allocation rule: The load of a push service node refers to the amount of business currently carried by the push service node. The load of each push service node varies depending on the amount of business it carries. Among the M push service nodes, some may be dedicated to performing push services and not responsible for other business processing, resulting in a smaller load, while others are responsible for both business processing and push services for other business systems, resulting in a larger load.

[0069] After the push commitment contract assigns push service nodes to different business systems, these nodes will also carry push services corresponding to those systems. To ensure load balancing across business nodes, one or more push service nodes with loads below a threshold can be assigned to the target business system. This threshold specifically refers to a load threshold, which filters out push service nodes with lower loads and assigns them to the target business system. For example, a push service node serving a preset number (e.g., 3) of business systems will not be assigned to the target business system, while a push service node specifically dedicated to executing push service and currently serving a business system within the preset threshold (e.g., 2) can be assigned to the target business system.

[0070] In this way, push service nodes can be scientifically allocated to target business systems based on their load, thereby enhancing network processing capabilities, reducing the processing and resource pressure on individual business nodes, and improving overall push performance.

[0071] For the second allocation rule: During the registration process of a business node as a push service node, it reports its processing capacity to the push commitment contract. This processing capacity can be estimated using the hardware resources filled in during registration, such as CPU resources, memory resources, and I / O port addresses. For example, the strength of its processing capacity can be measured by the number of standard transactions it can process per minute. The amount of push service data registered in the callback commitment refers to the amount of business data pushes that the target business system reports it can receive when registering the push service. Since the push service node is used by the business node to execute the callback commitment, one or more push service nodes whose processing capacity matches the amount of push service data can be selected from the M push service nodes and allocated to the target business system. Here, "matching" means that the processing capacity of the push service node can support processing the corresponding amount of data and pushing it to the target business system. From the perspective of the push service node, the stronger the processing capacity, the more push services it can handle, and the more callback commitments it can execute for different business systems, simultaneously connecting with multiple business systems to execute push services.

[0072] In this way, based on the processing capabilities reported by each push service node, push service nodes that match the amount of push service data required by the target business system can be adapted, and push service nodes can be reasonably allocated to each business system, thereby improving the smoothness of push service nodes in executing push services and enhancing the overall execution capability and efficiency of push services.

[0073] It's important to note that the push commitment contract allocates one or more push service nodes to the target business system, which can be categorized as primary and backup nodes. The primary node can serve as the target push service node. The push commitment contract's configuration preference for push service nodes typically involves configuring the higher-performing push service node as the primary node to be used, while the lower-performing push service node serves as the backup node. Performance can be evaluated using data such as load and processing capacity; higher performance refers to a lower current workload and stronger processing capacity. By configuring primary and backup nodes, if the primary node fails (e.g., due to network connectivity issues) and push service data cannot be pushed, the backup node can be used to quickly ensure the normal push of business data.

[0074] Optionally, when the target business system registers the push service with the push commitment contract, it submits the callback address of the target business system; the callback commitment is generated by the push commitment contract based on the callback address; the target push service node and the target business system establish a connection based on the callback commitment.

[0075] Business systems requiring push services can register for push services with the push commitment contract. When a target business system registers for push services, it can submit its callback address to the push commitment contract, allowing the contract to generate a callback commitment based on that address. The callback address can be a URL (Uniform Resource Locator) used to redirect back to the target business system, enabling the system to be located. A callback commitment is a promise agreed upon between the target business system and the blockchain system based on the push commitment contract. This commitment can be executed by the target push service node to retrieve and push target business data.

[0076] The generated callback promise contains a callback address, which identifies the target business system requiring push services, thus facilitating the push of target business data associated with that system. Each callback promise can initiate a connection to a push service node; that is, a business system can establish a connection with a push service node based on a callback promise. Establishing a connection before pushing target business data ensures the data is successfully delivered to the target business system. Specifically, because the push promise contract contains a callback promise, the synchronization of the push promise contract by the push service node allows it to obtain the callback promise. Based on the callback address contained in the callback promise, the target push service node can establish a connection with the target business system.

[0077] As can be seen, the push commitment contract deployed in the blockchain system can be used not only to maintain the registration of push services but also to allocate push service nodes for target business systems. Push service registration specifically includes the functional registration of the push service of the business system and the identity registration of the push service executor of the push service node. The registration of push services for business systems can be maintained through callback commitments. It should be noted that the push commitment contract contains callback commitments not only for the target business system but also for other business systems that have registered push services. Each business system's callback commitment can be used to initiate a connection to a push service node.

[0078] Based on the above, it can be seen that the synchronized blockchain data may include push commitment contracts deployed in the blockchain system, and the callback commitments of the target business system will also be synchronized to the target push service node. Optionally, the synchronized blockchain data may also include business data from various business systems connected to the target push service node. (Corresponding to the aforementioned...) Figure 2b The blockchain system shown can have blockchain data as follows: Figure 2b The data shown on the core chain (the blockchain located in the core consensus layer) includes at least one of the consensus nodes: permission contracts (such as push commitment contracts), caches, and blocks.

[0079] S302, obtain target business data associated with the target business system based on callback commitment.

[0080] The target business data is the latest business data associated with the target business system within the blockchain system. For example, the target business data might be the latest invoice data on the blockchain required by the target business system. Since the target push service node is the business node that executes the callback commitment of the target business system, it can obtain the target business data from the blockchain system or from synchronized blockchain data by executing the callback commitment. The acquisition of the target business data can be found in the following embodiments and will not be elaborated upon here.

[0081] S303 pushes the target business data to the target business system.

[0082] After obtaining the target business data associated with the target business system, the target push service node can push the target business data to the target business system. For a detailed description of the push process, please refer to the following embodiments; it will not be repeated here.

[0083] It should be noted that, since the blockchain system can connect to at least one business system that has registered a push service, for each business system that has registered a push service, the target push service node corresponding to that business system can execute the above-described process to achieve proactive push of business data. Each push service node serving each business system that has registered a push service can concurrently execute the push service in the manner described above. For example, push service node A and push service node B can concurrently push business data associated with business system S1 to business system S1 and business data associated with business system S2 to business system S2, respectively, in the manner described above. Optionally, since the target push service node can serve multiple business systems that have registered push services, to improve the overall efficiency of the push service, concurrent threads can be used within the target push service node to execute the push service for each business system. For example, push service node A can use concurrent threads to push the corresponding associated business data to business systems S1 and S2, respectively, in the manner described above.

[0084] The blockchain-based data processing solution provided in this application can synchronize blockchain data within a blockchain system. Based on the callback commitment in the synchronized push commitment contract, it can obtain the latest business data from the blockchain system and proactively push it to the associated target business system. This enables the blockchain system to proactively push business data to external business systems, eliminating the need for external business systems to poll or synchronize business data. This avoids the processing pressure and performance consumption on the blockchain system caused by a large number of proactive accesses from business systems. Furthermore, based on the target push service node, it can achieve rapid connection between business data and business systems, allowing the target business system to receive the latest business data in real time. Appropriate strategies are adopted for the allocation of push service nodes to the target business system (e.g., allocation based on the load or processing capacity of the push service nodes) to achieve scientific allocation of push service nodes, thereby improving the processing capacity of the push service and enhancing system performance.

[0085] Please see Figure 4 , Figure 4 This is a schematic flowchart of a blockchain-based data processing method provided in an exemplary embodiment of this application. This blockchain-based data processing method can be implemented using a computer device (such as...). Figure 2a The data processing method is executed by the registered push service business nodes in the witness network shown, and includes, but is not limited to, the following steps.

[0086] S401 synchronizes blockchain data within the blockchain system.

[0087] S402, retrieve target business data associated with the target business system based on callback commitment.

[0088] In one embodiment, the consensus node in the blockchain system stores push commitment contracts and business data. S401 specifically includes: synchronizing the push commitment contracts and business data from the consensus node. That is, the blockchain data synchronized from the consensus node includes the push commitment contracts. Since the push commitment contracts can be used to allocate one or more push service nodes to various registered push service business systems, and a target push service node may interface with one or more business systems, the synchronized blockchain data may also include the business data stored in the consensus node. Here, the synchronized business data can be the latest business data of one or more business systems served by the target push service node. Specifically, during the synchronization process, the identifier of the target push service node can be sent to the consensus node, and the consensus node synchronizes the latest business data of one or more business systems served by the target push service node to the target push service node based on the identifier of the target push service node. In another implementation, the synchronized business data can also refer to the latest business data of all business systems interfaced with each push service node in the blockchain system.

[0089] In this embodiment, the acquisition of target business data by the target push service node, i.e., S402, may specifically include the following implementation: based on callback commitment, filtering target business data associated with the target business system from the synchronized business data.

[0090] Optionally, the callback commitment includes a callback address, which can be used to uniquely identify the target business system. The target push service node can execute the callback commitment in the synchronized push commitment contract, filtering out the target business data associated with the callback address included in the callback commitment from the synchronized business data. This target business data is the latest business data associated with the target business system identified by the callback address. Different business systems connected to the target push service node have different callback commitments, and the filtered business data may also be different. The filtering of business data associated with different business systems can all be achieved based on the callback commitment. In one implementation, when the synchronized business data is the latest business data of one or more business systems served by the target push service node, the acquisition of the target business data includes the following: the target push service node filters out the target business data from the synchronized business data according to the callback address in the callback commitment. This applies when the synchronized business data is the latest business data of all business systems connected to the blockchain system. In another implementation, the acquisition of the target business data may include the following: the target push service node, based on the identifier of the target push service node and the callback address included in the callback commitment, obtains the business data associated with the target business system from the latest business data associated with all business systems. By allowing target push service nodes to independently filter target business data without requiring consensus nodes to do so, the processing pressure on the consensus network can be effectively reduced.

[0091] In another embodiment, S401 specifically includes: synchronously pushing a commitment contract from the consensus node. The blockchain data synchronized from the consensus node includes the pushed commitment contract, which contains a callback commitment returned to the target business system.

[0092] The push service node then retrieves the target business data based on the synchronized callback commitment. Specifically, S402 may include the following implementation: sending a data synchronization request to the consensus node, the data synchronization request carrying the identifier of the target push service node and the callback commitment; enabling the consensus node to filter out the target business data associated with the target business system based on the data synchronization request and return it; and receiving the target business data returned by the consensus node.

[0093] In this approach, after synchronizing with the push commitment contract, the target push service node can send a data synchronization request to the consensus node, carrying a callback commitment and its own identifier. The consensus node, based on the callback commitment and the target push service node's identifier in the data synchronization request, filters the target business data associated with the target business system from the stored business data and returns this target business data to the target push service node. It should be noted that the target business data is the latest business data of the target business system. Thus, the target push service node receives the latest business data associated with the target business system returned by the consensus node. In this embodiment, target business data can be retrieved from the blockchain system on demand in real time for the currently executed callback commitment, thereby avoiding the need to retrieve the latest business data associated with other business systems that have not registered push services, saving resources required for data transmission.

[0094] When the target business system registers for the push service with the push commitment contract, it provides its own callback address to obtain the callback commitment generated and returned by the push commitment contract in the blockchain system. Optionally, the callback commitment generated based on this callback address contains the callback address of the target business system. The callback address is, for example, the URL of the target business system. For the push process of the target business data, please refer to the descriptions in S403 and S404 below.

[0095] S403 invokes the callback interface of the target business system based on the callback address contained in the callback commitment.

[0096] Optionally, the callback interface of the target business system is set based on the interface specification of the callback commitment promised when registering the push service with the push commitment contract. The callback address contained in the synchronized callback commitment can be used to locate the target business system, and further call the callback interface provided by the target business system to push target business data through the callback interface. In this way, the target business system can also receive and process target business data pushed by the blockchain system based on the callback interface, such as receiving the latest invoice data on the push blockchain, thereby realizing the push of target business data from the blockchain system to external business systems.

[0097] S404 If the callback interface call is successful, the target business data will be pushed to the target business system based on the callback interface.

[0098] Under the condition that the callback interface call to the target business system is successful, the target business data can be pushed to the target business system through the callback interface. In one embodiment, pushing the target business data to the target business system based on the callback interface can include the following implementation: pushing the target business data to the target business system in a streaming manner based on the callback interface. Streaming processing here refers to pushing the target business data to the target business system in a streaming manner. In streaming processing, data can arrive continuously, and the target push service node can process the newly arrived data in a timely manner and continuously generate output. Thus, through streaming processing, based on the successfully called callback interface, the business data arriving at the target push service node can be asynchronously pushed to the target business system as quickly as possible.

[0099] In one implementation, pushing target business data to the target business system based on a callback interface in a streaming manner may include: establishing a memory queue, sequentially writing the synchronized target business data into the memory queue; reading data from the memory queue sequentially according to a first-in-first-out principle, and pushing the read data to the target business system based on the callback interface; and deleting the pushed data from the memory queue.

[0100] Since the target push service node can connect to one or more business systems, it can establish separate memory queues for each business system to maintain the latest business data associated with those systems. For example, the target push service node can maintain different memory queues for business system S1 and business system S2, denoted as Q1 and Q2 respectively. For ease of description, in this step, the target push service node establishes the memory queue for the target business system, which can be used to maintain the target business data of the target business system. Specifically, the synchronized target business data can be written into the memory queue in the order it is synchronized to the push service node. This achieves the function of the memory queue caching target business data. Next, the data in the memory queue (i.e., business data) can be processed according to the first-in, first-out (FIFO) principle, which means that data written to the memory queue first will be read from the memory queue first. Specifically, the data written to the memory queue first is read out first, and the read data is pushed to the target business system based on the callback interface. Overall, the business data written to the memory queue first will be pushed to the target business system first. Specifically, after the callback interface call is successful, the data read can be pushed to the target business system. At this time, the data pushed to the target business system can be deleted from the memory queue.

[0101] It should be noted that when the target business data is maintained through the memory queue, the callback interface can be called when the memory queue is not empty. Since the data in the memory queue will be deleted as it is pushed to the target business system, when the memory queue is empty, it means that there is no target business data (i.e., the latest business data) to push to the target business system. At this time, the callback interface of the target business system can be stopped. By monitoring whether the callback interface needs to be called to push business data in real time through the memory queue, call resources can be saved.

[0102] Step S404 described above is implemented under the condition that the callback interface call is successful. In one embodiment, due to various reasons, such as network connection interruption or deterioration of connection quality, the callback interface call may fail. Therefore, based on the callback interface call status, the following can also be performed: if the callback interface call fails and the retry conditions are met, then the callback interface is called again; if the retry conditions are not met, then the callback interface call is stopped, and the callback interface call failure result information is uploaded to the blockchain system.

[0103] In other words, if a callback interface call fails, and the retry conditions are met, the callback interface can be called again. If the retry call succeeds, the target business data will be pushed to the target business system. The retry conditions refer to the conditions under which the callback interface can be called again. Meeting the retry conditions could be, for example, the number of failed callback interface calls being less than or equal to a preset threshold, or the number of failed calls within a preset time being within a preset threshold. For example, the callback interface can be called again if the number of failed callback interface calls is 5 times or less, or if the number of failed calls within one minute is 3 times or less. Conversely, failing the retry conditions could be, for example, the number of failed callback interface calls exceeding a preset threshold. For example, if the number of failed callback interface calls has reached 6 times, then the callback interface call can be stopped.

[0104] For callback interface call failures, relevant failure data can be statistically analyzed to obtain failure result information. This failure result information describes the outcome of the callback interface call failure and belongs to the same dimension as the content required for retry conditions; for example, the failure result information might be the cumulative number of call failures. If the retry conditions are not met, the failure result information can be uploaded to the blockchain system, specifically to the blockchain's consensus network. For example, the number of callback interface call failures can be counted; each time a callback interface call fails, the failure count is incremented by 1. When the failure count reaches a threshold, the final count of failures can be reported to the blockchain system.

[0105] Optionally, the call failure result information is stored on the blockchain. This call failure result information can be shared by various consensus nodes in the consensus network. In one embodiment, the push commitment contract in the blockchain system selects a new push service node from the push service nodes already allocated to the target business system based on the call failure result information; or, the push commitment contract reallocates a new push service node to the target business system from M push service nodes based on the call failure result information.

[0106] After the failure call result information is uploaded to the blockchain system, the push commitment contract deployed in the blockchain system (specifically, the push commitment contract deployed in the consensus node) can adjust the target push service node for the target business system based on the feedback of the failure call result information. This adjustment can be achieved in one of the following ways: 1) Selecting a new push service node from the push service nodes already allocated to the target business system by the push commitment contract. 2) Reallocating a new push service node to the target business system from M push service nodes.

[0107] In Method 1), the push commitment contract can assign multiple push service nodes to the target business system. The target push service node is the push service node executing this solution and can be any of the push service nodes. Since the target push service node may have network connectivity issues with the target business system, multiple calls to the callback interface by the target push service node may fail, rendering the currently used push service node unavailable. In this case, a new push service node can be selected from the multiple push service nodes. This new push service node becomes the target push service node, establishes a connection with the target business system, and implements the push service as described above. For example, push service node A is the target push service node. Assuming the retry condition is that the callback interface can be called again if the number of failed calls is within 5, when the callback interface fails on the 6th call, push service node A can be changed to push service node B, and push service node B will execute the push service. In this method, when the currently used push service node becomes unavailable, a new push service node can be directly selected from the already assigned push service nodes without requiring a reassignment of the push commitment contract, allowing for faster and more efficient execution of business pushes.

[0108] Optionally, the target business data obtained by the target push service node can be shared with other push service nodes of the target business system. Thus, during the execution of the push service, if the current push service node becomes unavailable due to network issues and a new push service node is selected, the data sharing among the push service nodes of the target business system allows the new push service node to quickly connect to the push service execution process and push the target business data that has not yet been pushed to the target business system.

[0109] In method 2), the push commitment contract allocates a push service node to the target business system. When the target push service node is determined to be unavailable based on the feedback call failure results, a new push service node can be selected from the M push service nodes and allocated to the target business system. In other words, a new push service node is reassigned to the target business system. For example, if the number of failed calls to the callback interface by push service node a of business system S1 reaches a threshold, after the blockchain system receives the feedback on the number of failures, the push commitment contract can allocate push service node b to business system S1, and push service node b will perform the push service. It should be noted that since there is no backup push service node to replace the currently used target push service node, whenever a push service node becomes unavailable, the push commitment contract can reassign it according to the allocation rules. Therefore, the push commitment contract will also be updated and synchronized with the new push service node. In this method, information related to the load and configuration of the M push service nodes can be obtained in real time, allowing for the selection of a suitable push service node for the target business system.

[0110] The blockchain-based data processing solution provided in this application can continuously synchronize blockchain data in the blockchain system, synchronize callback commitments in the push commitment contract, and obtain the latest business data in the blockchain system in real time. Based on the callback commitment, it can actively call the callback interface of the target business system that has registered the push service. After the callback interface call is successful, the latest business data obtained is promptly pushed to the business system, thereby avoiding a large number of external business systems polling the blockchain system and effectively reducing network and system performance consumption. In addition, by calling the callback interface and actively pushing business data when the call is successful, the blockchain data and the business system can be quickly connected, improving the real-time reception of the latest data on the chain by the business system. If the callback interface call fails, the callback interface can be called again under the condition of retry. In this way, when the push service is briefly interrupted and then restored due to some unexpected factors (such as connection timeout), the normal push of business data can be guaranteed by calling the callback interface again. If the retry condition is not met, the push service node executing the push service can also be adjusted, for example, by selecting a new backup node or by reallocating a new push service node by the push commitment contract, thereby ensuring the normal execution of the push service.

[0111] Based on the content described in the above embodiments, please refer to, for example... Figure 5 This diagram illustrates an interaction of a blockchain-based data processing method. The push service nodes include push service node a and push service node b. The business systems include two business systems served by push service node a and three business systems served by push service node b. The consensus network includes multiple consensus nodes. Due to data sharing among consensus nodes, the push commitment contracts deployed on each consensus node are identical. The following example uses push service node a as the target push service node and business system S1 as the target business system to illustrate the interaction flow between the various endpoints.

[0112] First, business system S1 can register a push service with the push commitment contract in the consensus network, providing its own callback address. Any consensus node's push commitment contract can generate a callback commitment based on the received callback address and return it to business system S1. At this point, business system S1, after obtaining approval, receives a callback commitment from the blockchain system. Upon receiving the callback commitment, business system S1 can set up a callback interface based on the interface specifications required by the callback commitment. This callback interface is used to receive and process the target business data pushed by the blockchain system. It should be noted that, as... Figure 5 Each of the business systems shown can perform the above steps to register the push service and set up the callback interface.

[0113] Furthermore, business nodes in the witness network can also register push services with the push smart contract in the consensus node, thereby obtaining the identity of the push service node, such as... Figure 5 The two business nodes shown are registered as push service nodes. Push service node a can synchronize the push commitment contract in the consensus network. The push commitment contract contains a callback commitment. Based on the callback commitment, it can obtain business data associated with business system S1 and push this business data to business system S1. Specifically, the push service node can call the callback interface of business system S1 based on the callback address of business system S1 contained in the synchronized callback commitment, and push the business data to business system S1 when the callback interface call is successful. Pushing business data from push service node b to business system S2 can also be implemented as described above. Further details are omitted here.

[0114] As can be seen, the push commitment contract provided in this application embodiment can provide business systems that need push services with the function of registering push services. For example, a group that needs invoice push can apply for push services through the corresponding business system to the push commitment contract on the blockchain. After obtaining approval, it can obtain a callback commitment returned on the blockchain. Since business nodes can also register their own push service node identity with the push commitment contract, there are multiple push service nodes in the blockchain system. Push service nodes can push commitment contracts synchronously, and push service nodes and business systems that have registered push services can establish connections based on callback commitments. When a push service node obtains the latest business data according to the callback commitment, it can push the obtained latest business data to the corresponding business system in real time. The push commitment contract associates the data push capability on the blockchain. By using the function of push service nodes to push business data on the blockchain through callback commitments, the network and system performance consumption caused by a large number of polling and synchronizing data by external business systems can be avoided, while improving the real-time performance of business systems receiving the latest business data on the blockchain.

[0115] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating the structure of a blockchain-based data processing apparatus according to an exemplary embodiment of this application. The aforementioned blockchain-based data processing apparatus can be a computer program (including program code) running on a computer device; for example, the blockchain-based data processing apparatus is an application software. The blockchain-based data processing apparatus can be used to execute corresponding steps in the methods provided in the embodiments of this application. Figure 6 As shown, the blockchain-based data processing device 600 may include: a synchronization module 601, an acquisition module 602, a push module 603, and a processing module 604.

[0116] Synchronization module 601 is used to synchronize blockchain data in the blockchain system. The blockchain system is connected to a target business system that has registered push services. The blockchain system has a push commitment contract deployed, which contains a callback commitment from the target business system.

[0117] Module 602 is used to obtain target business data associated with the target business system based on callback commitment;

[0118] The push module 603 is used to push target business data to the target business system.

[0119] In one embodiment, the target business system is any business system that has been connected to the blockchain system and registered for push services; the method provided in this application is executed by the target push service node corresponding to the target business system; the push commitment contract also contains the identifiers of M push service nodes that have registered for push services; the push commitment contract is used to allocate one or more push service nodes to the target business system from the M push service nodes; the target push service node is any one of the one or more push service nodes corresponding to the target business system; M is a positive integer; when the target business system registers for push services with the push commitment contract, it submits the callback address of the target business system; the callback commitment is generated by the push commitment contract based on the callback address; the target push service node and the target business system establish a connection based on the callback commitment.

[0120] In one embodiment, the blockchain system includes a witness network and a consensus network. The witness network contains one or more business nodes, and the consensus network contains one or more consensus nodes. A push commitment contract is deployed on the consensus nodes. When any business node registers a push service with the push commitment contract, the registered business node is configured as a push service node. The business node configured as a push service node is used to specifically perform the push service; or, it is used to perform both the push service and business processing simultaneously.

[0121] In one embodiment, the allocation rules followed by the push commitment contract when allocating one or more push service nodes from M push service nodes to the target business system include any one or more of the following: based on the load of the M push service nodes, selecting one or more push service nodes with loads below a threshold from the M push service nodes and allocating them to the target business system; based on the processing capacity reported by the M push service nodes, selecting push service nodes from the M push service nodes that match the amount of push service data registered in the callback commitment and allocating them to the target business system.

[0122] In one embodiment, the consensus nodes in the blockchain system store push commitment contracts and business data; the synchronization module 601 is specifically used for: synchronizing push commitment contracts and business data from the consensus nodes; and obtaining target business data associated with the target business system based on callback commitments, including: filtering target business data associated with the target business system from the synchronized business data based on callback commitments.

[0123] In another embodiment, the consensus node in the blockchain system stores push commitment contracts and business data; the synchronization module 601 is specifically used to: synchronize the push commitment contracts from the consensus node; the acquisition module 602 is specifically used to: send a data synchronization request to the consensus node, the data synchronization request carrying the identifier of the target push service node and a callback commitment; enable the consensus node to filter out the target business data associated with the target business system based on the data synchronization request and return it; and receive the target business data returned by the consensus node.

[0124] In one embodiment, the callback commitment includes the callback address of the target business system. The push module 603 is specifically used to: call the callback interface of the target business system based on the callback address included in the callback commitment; if the callback interface call is successful, push the target business data to the target business system based on the callback interface; wherein, the callback interface of the target business system is set based on the interface specification of the callback commitment returned by the blockchain system.

[0125] In one embodiment, the push module 603 is specifically used to: push target business data to the target business system based on the callback interface and in a streaming processing manner.

[0126] In one embodiment, the push module 603 is specifically used to: establish a memory queue, sequentially write the synchronized target business data into the memory queue; read data from the memory queue sequentially according to the first-in-first-out principle, and push the read data to the target business system based on the callback interface; and delete the pushed data from the memory queue.

[0127] In one embodiment, the processing module 604 is further configured to: if the callback interface call fails and the retry condition is met, then re-call the callback interface; if the retry condition is not met, then stop calling the callback interface and upload the callback interface call failure result information to the blockchain system.

[0128] In one embodiment, the call failure result information is stored on the blockchain; the push commitment contract in the blockchain system selects a new push service node from the push service nodes already allocated to the target business system based on the call failure result information; or, the push commitment contract reallocates a new push service node to the target business system from M push service nodes based on the call failure result information.

[0129] It is understood that the functions of each functional module of the blockchain-based data processing device described in the embodiments of this application can be specifically implemented according to the methods in the above method embodiments, and the specific implementation process can be referred to the relevant descriptions in the above method embodiments, which will not be repeated here. In addition, the beneficial effects of using the same method will not be repeated here either.

[0130] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device 700 may include one or more independent devices (such as servers, nodes, terminals, etc.), or it may include components within independent devices (such as chips, software modules, or hardware modules). The computer device 700 may include at least one processor 701 and a communication interface 702. Optionally, the computer device 700 may also include at least one memory 703 and a bus 704. The processor 701, communication interface 702, and memory 703 are connected via the bus 704.

[0131] The processor 701 is a module that performs arithmetic and / or logical operations. Specifically, it can be one or a combination of processing modules such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor unit (MPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), a coprocessor (to assist the central processing unit in completing corresponding processing and applications), and a microcontroller unit (MCU).

[0132] The communication interface 702 can be used to provide information input or output to at least one processor. And / or, the communication interface 702 can be used to receive data sent externally and / or send data externally, and can be a wired link interface including an Ethernet cable, or a wireless link interface (Wi-Fi, Bluetooth, general wireless transmission, vehicular short-range communication technology, and other short-range wireless communication technologies, etc.). In embodiments of this application, the communication interface may include a network interface.

[0133] The memory 703 provides storage space, in which data such as the operating system and computer programs can be stored. The memory 703 can be one or a combination of several of the following: random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM).

[0134] At least one processor 701 in the computer device 700 is used to invoke a computer program stored in at least one memory 703 to execute the aforementioned blockchain-based data processing method, such as the one described above. Figure 3 and Figure 4 The illustrated embodiment describes a blockchain-based data processing method.

[0135] In one possible implementation, the processor 701 in the computer device 700 is used to call a computer program stored in at least one memory 703 to perform the following operations: synchronizing blockchain data in the blockchain system, the blockchain system being connected to a target business system with a registered push service, the blockchain system having a push commitment contract deployed, the push commitment contract containing a callback commitment of the target business system; obtaining target business data associated with the target business system based on the callback commitment; and pushing the target business data to the target business system.

[0136] In one embodiment, the target business system is any business system that has been connected to the blockchain system and registered for push services; the method provided in this application is executed by the target push service node corresponding to the target business system; the push commitment contract also contains the identifiers of M push service nodes that have registered for push services; the push commitment contract is used to allocate one or more push service nodes to the target business system from the M push service nodes; the target push service node is any one of the one or more push service nodes corresponding to the target business system; M is a positive integer; when the target business system registers for push services with the push commitment contract, it submits the callback address of the target business system; the callback commitment is generated by the push commitment contract based on the callback address; the target push service node and the target business system establish a connection based on the callback commitment.

[0137] In one embodiment, the blockchain system includes a witness network and a consensus network. The witness network contains one or more business nodes, and the consensus network contains one or more consensus nodes. A push commitment contract is deployed on the consensus nodes. When any business node registers a push service with the push commitment contract, the registered business node is configured as a push service node. The business node configured as a push service node is used to specifically perform the push service; or, it is used to perform both the push service and business processing simultaneously.

[0138] In one embodiment, the allocation rules followed by the push commitment contract when allocating one or more push service nodes from M push service nodes to the target business system include any one or more of the following: based on the load of the M push service nodes, selecting one or more push service nodes with loads below a threshold from the M push service nodes and allocating them to the target business system; based on the processing capacity reported by the M push service nodes, selecting push service nodes from the M push service nodes that match the amount of push service data registered in the callback commitment and allocating them to the target business system.

[0139] In one embodiment, the consensus node in the blockchain system stores push commitment contracts and business data; the processor 701 is specifically used for: synchronously pushing commitment contracts and business data from the consensus node; and obtaining target business data associated with the target business system based on callback commitments, including: filtering target business data associated with the target business system from the synchronized business data based on callback commitments.

[0140] In another embodiment, the consensus node in the blockchain system stores push commitment contracts and business data; the processor 701 is specifically used for: synchronizing push commitment contracts from the consensus node; the processor 701 is specifically used for: sending a data synchronization request to the consensus node, the data synchronization request carrying the identifier of the target push service node and a callback commitment; enabling the consensus node to filter out the target business data associated with the target business system based on the data synchronization request and return it; and receiving the target business data returned by the consensus node.

[0141] In one embodiment, the callback commitment includes the callback address of the target business system. The processor 701 is specifically used to: call the callback interface of the target business system based on the callback address included in the callback commitment; if the callback interface call is successful, push the target business data to the target business system based on the callback interface; wherein, the callback interface of the target business system is set according to the interface specification of the callback commitment returned by the blockchain system.

[0142] In one embodiment, the processor 701 is specifically used to: push target business data to the target business system based on a callback interface and in a streaming processing manner.

[0143] In one embodiment, the processor 701 is specifically configured to: establish a memory queue, sequentially write synchronized target business data into the memory queue; read data from the memory queue sequentially according to the first-in-first-out principle, and push the read data to the target business system based on the callback interface; and delete the pushed data from the memory queue.

[0144] In one embodiment, the processor 701 is further configured to: if the callback interface call fails and the retry condition is met, then re-call the callback interface; the processor 701 is further configured to: if the retry condition is not met, then stop calling the callback interface and upload the callback interface call failure result information to the blockchain system.

[0145] In one embodiment, the call failure result information is stored on the blockchain; the push commitment contract in the blockchain system selects a new push service node from the push service nodes already allocated to the target business system based on the call failure result information; or, the push commitment contract reallocates a new push service node to the target business system from M push service nodes based on the call failure result information.

[0146] It should be understood that the computer device 700 described in the embodiments of this application can execute the blockchain-based data processing method described in the corresponding embodiments above, and can also execute the methods described above. Figure 6 The description of the blockchain-based data processing device 600 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0147] Furthermore, it should be noted that an exemplary embodiment of this application also provides a computer-readable storage medium storing a computer program for the aforementioned blockchain-based data processing method. When executed by a processor, the computer program performs the blockchain-based data processing method described in the embodiments of this application. That is, when one or more processors load and execute the computer program, the blockchain-based data processing method described in the embodiments can be implemented, which will not be repeated here. The beneficial effects of using the same method will also not be repeated here.

[0148] The aforementioned computer-readable storage medium can be the internal storage unit of the blockchain-based data processing apparatus provided in any of the foregoing embodiments or the computer device, such as the hard drive or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units 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 can also be used to temporarily store data that has been output or will be output.

[0149] One aspect of this application provides a computer program product or computer program. A processor of a computer device reads the computer program from a computer-readable storage medium and executes the computer program, causing the computer device to perform a blockchain-based data processing method provided in one aspect of the embodiments of this application.

[0150] In one aspect of this application, another computer program product or computer program is provided, which includes a computer program that, when executed by a processor, implements the steps of the blockchain-based data processing method provided in the embodiments of this application.

[0151] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0152] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0153] The above-disclosed embodiments are only some of the embodiments of this application, and should not be construed as limiting the scope of this application. Therefore, any equivalent changes made to the claims of this application are still within the scope of this application.

Claims

1. A data processing method based on blockchain, characterized in that, The method is executed by the target push service node corresponding to the target business system; The target push service node is any one of one or more push service nodes corresponding to the target business system; the method includes: Synchronizing blockchain data within a blockchain system, wherein the blockchain system is connected to a target business system that has registered a push service, the target business system being any business system connected to the blockchain system and registered for a push service; a push commitment contract is deployed in the blockchain system, the push commitment contract containing a callback commitment from the target business system and identifiers of M push service nodes that have registered for the push service; the push commitment contract is used to allocate one or more push service nodes to the target business system from the M push service nodes; when registering a push service with the push commitment contract, the target business system submits its callback address; the callback commitment is generated by the push commitment contract based on the callback address; a connection is established between the target push service node and the target business system based on the callback commitment; M is a positive integer; Based on the callback commitment, obtain the target business data associated with the target business system; and The target business data is pushed to the target business system.

2. The method as described in claim 1, characterized in that, The blockchain system includes a witness network and a consensus network. The witness network contains one or more business nodes, and the consensus network contains one or more consensus nodes. The push commitment contract is deployed on the consensus nodes. Once any business node registers for push service with the push commitment contract, the registered business node is configured as a push service node. A business node configured as a push service node is used to perform push services exclusively; or, it is used to perform push services and business processing simultaneously.

3. The method as described in claim 1 or 2, characterized in that, The allocation rules followed by the push commitment contract when allocating one or more push service nodes to the target business system from the M push service nodes include any one or more of the following: Based on the load of the M push service nodes, select one or more push service nodes with loads below a threshold from the M push service nodes and assign them to the target business system; Based on the processing capacity reported by the M push service nodes, a push service node that matches the amount of push service data registered in the callback commitment is selected from the M push service nodes and assigned to the target business system.

4. The method as described in claim 1 or 2, characterized in that, The consensus nodes in the blockchain system store the push commitment contract and business data; The synchronization of blockchain data in the blockchain system includes: synchronizing the push commitment contract and the business data from the consensus node; The step of obtaining target business data associated with the target business system based on the callback commitment includes: filtering target business data associated with the target business system from the synchronized business data based on the callback commitment.

5. The method as described in claim 1 or 2, characterized in that, The consensus nodes in the blockchain system store the push commitment contract and business data; The synchronization of blockchain data in the blockchain system includes: synchronizing the push commitment contract from the consensus node; The step of obtaining target business data associated with the target business system based on the callback commitment includes: A data synchronization request is sent to the consensus node, the data synchronization request carrying the identifier of the target push service node and the callback commitment; the consensus node then filters out the target business data associated with the target business system based on the data synchronization request and returns it. Receive the target service data returned by the consensus node.

6. The method as described in claim 1, characterized in that, The callback commitment includes the callback address of the target business system, and the step of pushing the target business data to the target business system includes: Based on the callback address contained in the callback commitment, the callback interface of the target business system is invoked; If the callback interface call is successful, the target business data will be pushed to the target business system based on the callback interface; The callback interface of the target business system is set based on the interface specification of the callback commitment returned by the blockchain system.

7. The method as described in claim 6, characterized in that, The step of pushing the target business data to the target business system based on the callback interface includes: Based on the callback interface, the target business data is pushed to the target business system in a streaming manner.

8. The method as described in claim 7, characterized in that, The step of pushing the target business data to the target business system based on the callback interface and in a streaming processing manner includes: Establish a memory queue and sequentially write the synchronized target business data into the memory queue; Following the first-in-first-out principle, data is read sequentially from the memory queue, and the read data is pushed to the target business system based on the callback interface; Delete the pushed data from the memory queue.

9. The method according to any one of claims 6 to 8, characterized in that, The method further includes: If the callback interface call fails and the retry conditions are met, the callback interface will be called again. If the retry conditions are not met, the callback interface will be stopped from being called, and the failure result information of the callback interface will be uploaded to the blockchain system.

10. The method as described in claim 9, characterized in that, The call failure result information is stored on the blockchain; the push commitment contract in the blockchain system selects a new push service node from the push service nodes already allocated to the target business system based on the call failure result information; or, the push commitment contract reallocates a new push service node to the target business system from the M push service nodes based on the call failure result information.

11. A data processing device based on blockchain, characterized in that, The device is deployed in the target push service node corresponding to the target business system; The target push service node is any one of one or more push service nodes corresponding to the target business system; the device includes: A synchronization module is used to synchronize blockchain data in a blockchain system. The blockchain system is connected to a target business system that has registered a push service. The target business system is any business system connected to the blockchain system and registered for a push service. A push commitment contract is deployed in the blockchain system. This contract includes a callback commitment from the target business system and identifiers of M push service nodes that have registered for the push service. The push commitment contract is used to allocate one or more push service nodes to the target business system from the M push service nodes. When registering for a push service with the push commitment contract, the target business system submits its callback address. The callback commitment is generated by the push commitment contract based on the callback address. A connection is established between the target push service node and the target business system based on the callback commitment. M is a positive integer. The acquisition module is used to acquire target business data associated with the target business system based on the callback commitment; and, The push module is used to push the target business data to the target business system.

12. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide network communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the blockchain-based data processing method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the blockchain-based data processing method according to any one of claims 1 to 10.

14. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the blockchain-based data processing method as described in any one of claims 1 to 10.

Images