A blockchain-based data processing method and related products
By deploying a target-local injection contract in the blockchain system, business data is actively output to the business system, solving the performance consumption problem caused by the business system frequently polling the blockchain system and achieving efficient data processing.
Patent Information
- Application Number
- CN202210460335.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-04-28
- Publication Date
- 2026-08-25
- Estimated Expiration
- 2042-04-28
AI Technical Summary
During data transmission between the business system and the blockchain system, existing technologies have failed to effectively reduce performance consumption, causing the business system to frequently poll the blockchain system, resulting in a waste of network and system performance.
By deploying a target local injection contract in the blockchain system, and proactively reading business data from the target business contract and outputting it to the target business system when a triggering event meets the triggering rules, the business system avoids frequently polling the blockchain system.
It enables rapid integration of blockchain data with business systems, reduces the network and system performance consumption of business systems on the blockchain system, and improves data processing efficiency.
Smart Images

Figure CN117014452B_ABST
Abstract
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] With the development of blockchain technology, it has found wide application in many fields such as the Internet of Things, smart manufacturing, supply chain, and digital asset trading. As an important component of the next generation of information technology, blockchain technology can handle various business transactions.
[0003] Business systems and blockchain systems can jointly provide services to business users. Typically, when business users process transactions using the business system, they may need to access information stored in the blockchain system, resulting in data transmission between the two systems. In practical applications, determining the appropriate processing mechanism to minimize the performance overhead caused by data transmission remains a subject of further research. Summary of the Invention
[0004] This application provides a blockchain-based data processing method and related products, which can proactively output business data of the blockchain system to the business system based on a deployed local injection contract, thereby effectively reducing the system's performance consumption.
[0005] One embodiment of this application provides a blockchain-based data processing method, including:
[0006] Synchronize blockchain data in a blockchain system. The blockchain system is connected to a target business system. The blockchain system deploys a target business contract related to the target business system and a target local injection contract associated with the target business contract. The target local injection contract has corresponding triggering rules.
[0007] During synchronization, if a triggering event satisfying the triggering rules is detected, the target local injection contract is executed to read business data from the target business contract; and,
[0008] The business data is output to the target business system.
[0009] One embodiment of this application provides a blockchain-based data processing device, including:
[0010] A synchronization module is used to synchronize blockchain data in a blockchain system. The blockchain system is connected to a target business system, and a target business contract related to the target business system is deployed in the blockchain system. A target local injection contract associated with the target business contract is also deployed in the blockchain system. The target local injection contract has corresponding triggering rules.
[0011] The reading module is used to, during the synchronization process, if a triggering event satisfying the triggering rules is detected, execute the target local injection contract and read business data from the target business contract; and,
[0012] The output module is used to output the 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 storing blockchain data can be connected to a target business system. Within the blockchain system, target business contracts related to the target business system and target local injection contracts associated with those contracts can be deployed. During blockchain data synchronization, these target business contracts, target local injection contracts, and corresponding triggering rules deployed in the blockchain system can all be synchronized. When a triggering event satisfying the triggering rule of the target local injection contract is detected, the target local injection contract can be executed, actively outputting the business data read from the target business contract to the target business system outside the blockchain system. Therefore, by using target local injection contracts to achieve rapid connection between blockchain data and the target business system, and by executing the local injection contracts deployed in the blockchain system, business data from the blockchain system can be actively output to external business systems. This eliminates the need for external business systems to poll the blockchain system, thereby avoiding network and system performance consumption caused by a large number of business systems polling business data. 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 2a This 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 exemplary embodiment of the present application providing an interactive diagram of blockchain-based data processing;
[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] Block height: Block height refers to the block number. In other words, it's the number of blocks between a given block and the genesis block. The genesis block, also known as the originating block, is the first block on a blockchain, and its height is 0. Block height is one of the identifiers of a block (the other being the hash value of the block header), and information about a specific block can be queried using its height.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] KA: Key Account, key customer.
[0034] 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 may contain conditions that trigger the contract's automatic execution. As one of the core technologies of blockchain, smart contracts allow for trusted transactions without the need for a third party.
[0035] Smart contract auditing involves developers thoroughly examining the smart contract code. This audit allows developers to identify any potential flaws or vulnerabilities before deploying the smart contract. Smart contract audits are typically conducted by third parties to ensure the code is analyzed as thoroughly as possible.
[0036] SQL: Structured Query Language.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258
[0041] 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 1bA 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.
[0042] 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:
[0043] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] like Figure 2a As 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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 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 shown in 2a. 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 provides 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).
[0053] Taking e-invoice business nodes as an example, specifically, the business nodes in business layer 10 are located in the tax intranet, public cloud, and private cloud. 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.
[0054] 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.
[0055] Core consensus layer 12 can be a tax-specific network containing M core chains, where M 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., consensus node), and each trusted node includes blocks, permission contracts, and a cache. Optionally, the permission contract can include one or more of the following: local injection contracts, trigger management contracts, and business contracts. Optionally, the trusted nodes can be various terminal devices of the State Taxation Administration.
[0056] In this embodiment, the blockchain system 210 can connect to different business systems. Specifically, it is achieved by business nodes interfacing with different business systems. For any one of the multiple business systems (i.e., the target business system), during the process of synchronizing blockchain data in the blockchain system—specifically, during the process of any business node in the witness network 201 synchronizing blockchain data in the consensus network 202—when the target local injection contract deployed on the blockchain is triggered, the target local injection contract is executed. Since the target local injection contract is associated with the target business contract, the specific execution process is as follows: read business data from the target business contract related to the target business system and output the business data to the target business system. In this way, the blockchain system actively outputs business data to the target business system, enabling rapid integration of blockchain data with the business system. By actively outputting data, the system avoids extensive polling of the blockchain system by the business system, reducing the performance consumption of the entire blockchain-based data processing system.
[0057] It is understood that in the specific implementation of this application, data such as object information, business data, and transaction data are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the object (e.g., the 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.
[0058] 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 a blockchain system can access at least one business system, and the witness network in the blockchain system includes one or more business nodes, in this application embodiment, any one of the at least one business system is taken as the target business system accessed by the blockchain system, and any one of the business nodes in the witness network that connects to the target business system is taken as the target business node. The detailed content of this solution will be explained using the target business node as the execution entity.
[0059] Please see Figure 3 , Figure 3 This is a schematic flowchart illustrating 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 blockchain-based data processing method, executed by the target business node in the witness network shown, includes:
[0060] S301 synchronizes blockchain data within the blockchain system.
[0061] The blockchain system is connected to the target business system, and the blockchain system deploys the target business contract related to the target business system, as well as the target local injection contract associated with the target business contract; the target local injection contract has corresponding triggering rules.
[0062] The target business system refers to any one of the multiple business systems connected to the blockchain system. This target business system and the blockchain system jointly provide corresponding services to the business party. The target business system connects to different business entities; that is, the users or business parties differ. For example, if the target business system is a local tax system, the target entity is the electronic tax bureau; if it's an invoicing service system, the target entity is a collective organization; and if it's a payment system, the target entity is the consumer.
[0063] 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. The blockchain-based data processing method provided in this application is executed by a target business node, which is any business node in the witness network. The target business node can be an SPV node. Taking a local tax system as an example, the SPV node can specifically be a provincial-level SPV node. For a detailed introduction to the blockchain system, please refer to the foregoing. Figure 2a and Figure 2b The content shown will not be repeated here.
[0064] The blockchain system deploys the following smart contracts: the target business contract and the target local injection contract. See also Figure 2b The consensus network comprises multiple core chains (i.e., blockchains located at the core consensus layer). Smart contracts can be deployed on these core chains, specifically within the various consensus nodes of the blockchain system's consensus network (stored on the core chains). The target business contract is related to the target business system, while the target local injection contract is associated with the target business contract. The triggering rule for the target local injection contract refers to the conditions that must be met for the target local injection contract to be executed.
[0065] Optionally, "related to the target business contract and the target business system" means that the target business contract contains the business processing logic of the target business system. Specifically, the business processing logic of the target business system refers to the logic by which the business provided by the target business system is executed. Since the target business contract is a smart contract deployed in the blockchain system and related to the target business system, and smart contracts typically explain the executor's obligations through code, this business processing logic can exist in the target business contract in the form of code, thus making the target business contract related to the target business system. For example, if the target business system is a tax system, and the business provided by the tax system is tax-related business, then the target business contract is a smart contract that executes tax-related business and contains the business processing logic for tax-related business.
[0066] Optionally, the association between the target business contract and the target local injection contract means that the target local injection contract is configured with implementation logic for reading business data from the target business contract. The business data read from the target business contract can be the result data corresponding to the transactions contained in the business contract. The target local injection contract is a smart contract deployed in the blockchain system that is associated with the target business contract. Specifically, it is a local injection contract that the target business node has the authority to execute. The relevant implementation logic configured in the contract can be presented in the form of code.
[0067] Optionally, the target local injection contract is executed locally on the target business node, and the local execution result is stored in the local storage space of the target business node. Since the target local injection contract is a local injection contract that the target business node has execution permissions for, it can be executed locally on the target business node. This local execution is a local operation, and the local execution result can be stored locally. Specifically, the local execution result generated by the local execution of the target local injection contract can be stored in the local storage space of the target business node, for example, in the terminal device executing the business. This local execution result does not need to be stored on the blockchain; in this embodiment, "not stored on the blockchain" specifically means not storing it in the consensus node of the consensus network.
[0068] Synchronizing blockchain data from a blockchain system can specifically mean synchronizing the blockchain data stored in the consensus network of the blockchain system, such as... Figure 2b The data shown includes blocks, caches, and permission contracts from trusted nodes in each core chain (i.e., the blockchain located in the core consensus layer). Specifically, the target business node can synchronize blockchain data by synchronizing blocks, such as the block header containing the version number, timestamp, difficulty value, and input information feature values. It can also synchronize smart contracts deployed on the blockchain, such as the target local injection contract and the target business contract, which are associated with each other. By synchronizing the target business contract to the target business node, business data from the target business contract can be quickly read from the business node when needed, without accessing the consensus node, thus improving efficiency.
[0069] S302, during the synchronization process, if a triggering event that meets the triggering rules is detected, the target local injection contract is executed to read business data from the target business contract.
[0070] In one embodiment, the target local injection contract is stored on the consensus node. Before executing step S302, the following may also be included: synchronizing the target local injection contract from the consensus node.
[0071] The target business node has execution authority over the target local injection contract synchronized to its local machine; that is, the target local injection contract is a local injection contract that can be executed by the target business node. For the consensus node, active synchronization of the target local injection contract can be achieved by distributing the contract code of the target local injection contract to the target business node. It should be noted that the contract code of the target local injection contract can be distributed to at least one business node with execution authority. In other words, among one or more business nodes in the witness network included in the blockchain system, at least one business node can execute the target local injection contract, and any one of these at least one business node can serve as the target business node. Furthermore, it should be noted that the step of synchronizing the target local injection contract from the consensus node can be performed before synchronizing blockchain data or during the process of synchronizing blockchain data. When performed during the process of synchronizing blockchain data, the synchronized blockchain data can include the target local injection contract, and step S302 can be executed after the target local injection contract synchronization is completed.
[0072] Optionally, the consensus node stores N local injection contracts, with each local injection contract associated with a business contract; the consensus node also stores a trigger management contract, which sets the trigger rules for each local injection contract and the permission information for each local injection contract. The permission information includes the identifier of the business node that has the execution permission for the local injection contract.
[0073] Specifically, the blockchain system deploys local injection contracts and business contracts, which are stored on consensus nodes in the consensus network. Since each local injection contract is associated with a business contract—that is, each local injection contract is configured with implementation logic to read business data from a business contract—different local injection contracts handle different business contracts. Therefore, the N local injection contracts stored in the consensus node are different, and the consensus node also stores N business contracts. In this embodiment, the target local injection contract can be the local injection contract associated with the target business contract among the N local injection contracts.
[0074] In addition, the consensus node also stores a trigger management contract, which manages the triggering rules and permission information for each of the N local injection contracts. The triggering rules refer to the conditions that must be met for a local injection contract to be executed. For example, when a target business node synchronizes to the transaction corresponding to business contract A, the target local injection contract AL is triggered. Since the permission information includes the identifiers of business nodes with execution permissions for the local injection contracts, it can indicate which business nodes in the witness network have execution permissions for the local injection contracts. For example, the permission information may specify that local injection contract AL can only be executed on the SPV node with SPVID GD0001. From the permission information of each local injection contract, it can be determined which local injection contracts each business node can execute; a business node may have execution permissions for one or more local injection contracts. Optionally, the trigger management contract can be synchronized to the target business node during the blockchain data synchronization process, or it can be synchronized to the target business node before the blockchain data synchronization, or it may not be synchronized to the target business node.
[0075] As shown above, combining trigger rules and permission information allows us to specify on which business node a local injection contract should be triggered and executed, and under what rules, thus enabling the setting of conditions for triggering the execution of local injection contracts. By using a trigger management contract, the trigger rules and permission information for each local injection contract can be configured uniformly, making it easy to manage the trigger execution settings of different local injection contracts in a unified manner.
[0076] There are two ways to synchronize the target local injection contract from the consensus node.
[0077] Method 1: 1) Send a data synchronization request to the consensus node, so that the consensus node selects the target local injection contract that the target business node has the execution permission from N local injection contracts based on the identifier of the target business node carried in the trigger management contract and the data synchronization request, and synchronizes the target local injection contract to the target business node; 2) Receive the target local injection contract synchronized by the consensus node.
[0078] The target business node can send a data synchronization request to the consensus node. This request carries the target business node's identifier, such as the SPVID of an SPV node. The data synchronization request is used to request the consensus node to synchronize a target local injection contract that matches the target business node's identifier. Matching the target business node's identifier means that the permission information set in the trigger management contract, including the identifier of the business node with execution rights to the local injection contract, is the same as the identifier of the target business node initiating the data synchronization request. Specifically, after receiving the data synchronization request, the consensus node can, based on the permission information set in the trigger management contract and the target business node's identifier, select at least one local injection contract from N local injection contracts stored in the consensus node that the target business node has execution rights for. Each of these at least one local injection contract can be executed locally on the target business node. The local injection contract associated with the target business contract among these at least one local injection contracts can be used as the target local injection contract with execution rights for the target business node and synchronized to the target business node. It should be noted that the triggering rules set for the target local injection contract in the trigger management contract can also be synchronized to the target business node along with the target local injection contract. In other words, the target business node can receive the target local injection contract synchronized by the consensus node, as well as the triggering rules set for the target local injection contract in the trigger management contract. In this way, on the target business node side, the triggering execution of the target local injection contract can be implemented according to these triggering rules.
[0079] In this approach, the consensus node can accurately select the target local injection contract from N local injection contracts based on the permission information set for the local injection contract in the trigger management contract, and then synchronize it to the target business node with execution permissions. This permission-based selection ensures precise synchronization of the target local injection contract to the target business node with execution permissions, thereby saving resources required for synchronization.
[0080] Method 2: 1) Send a data synchronization request to the consensus node, so that the consensus node responds to the data synchronization request and returns N local injection contracts and a trigger management contract; 2) Receive the N local injection contracts and the trigger management contract returned by the consensus node; 3) Set the target local injection contracts among the N local injection contracts that the target business node has the execution permission to take effect according to the trigger management contract.
[0081] In this approach, the target business node can also send a data synchronization request to the consensus node. Upon receiving the data synchronization request, the consensus node can respond by returning the trigger management contract and N local injection contracts stored in the consensus node to the target business node. Here, "responding to" refers to the computer device's response when a processing request exists. In this embodiment, the processing request can be a data synchronization request. The computer device, in response to (the stated condition or event), can perform the actions required for processing. This can be the consensus node responding to the data synchronization request by returning the trigger management contract and N local injection contracts to the target business node. Optionally, the trigger management contract returned to the target business node specifically includes: permission information related to the target business node, and triggering rules for the local injection contracts that the target business node has the execution permission for. From the consensus node's perspective, the trigger management contract can synchronize the local injection contracts and their corresponding triggering rules to the corresponding business node based on the permission information. For example, if the permission information stipulates that the local injection contract AL1 can only be executed on the SPV node with SPVID GD0001, then the local injection contract AL1 and the corresponding triggering rules can be synchronized to the SPV node with node identifier GD0001.
[0082] The target business node can determine at least one local injection contract from N local injection contracts, based on the permission information set in the trigger management contract. Each of these at least one local injection contract can be executed locally on the target business node. The local injection contract associated with the target business contract among the at least one local injection contract can serve as the target local injection contract, and thus, the target local injection contract can be set to be active, i.e., set as an active local injection contract. Optionally, once the target local injection contract is set to be active, it means that the target local injection contract can be executed locally on the target business node. In other words, in practical applications, the target business node can execute the target local injection contract locally.
[0083] In this approach, the trigger management contract and all local injection contracts stored in the consensus node can be synchronized to the target business node. The target business node then applies the execution permissions to the target local injection contracts based on the permission information included in the trigger management contract. Thus, the selection of target local injection contracts with execution permissions from N local injection contracts is implemented within the target business node. When multiple target business nodes concurrently access the consensus node, since the consensus node does not need to perform the selection process but simply returns the data it possesses, the selection of target local injection contracts is handled by each target business node itself, effectively reducing the processing load on the consensus node.
[0084] It should be noted that, for ease of understanding, the above description uses the target local injection contract associated with the target business contract as an example. Since the target business node has execution permissions for at least one local injection contract, the implementation of local injection contracts associated with other business contracts can also refer to the above example, and will not be elaborated here.
[0085] As described above, before performing this step, the target business node has synchronized with the target local injection contract and the corresponding triggering rules. Therefore, during the synchronization of blockchain data from the blockchain system, if a triggering event satisfying the triggering rules is detected, the target local injection contract can be executed locally on the target business node to read the business data within the target business contract. Here, a triggering event refers to an event that triggers the execution of code contained in the target local injection contract, which can be generated manually or automatically. After determining that a triggering event satisfying the triggering rules has been detected, the code contained in the target local injection contract can be executed, and the business data in the target business contract can be read according to the code's implementation logic, such as reading the business data specified by the target local injection contract. Since different business contracts have different business logic, the business data included in different business contracts also differs. The read business data can be transaction result data generated by a transaction, such as information about a successful or failed transaction, or transaction content data, such as transaction volume, etc. Furthermore, for how to determine the detection of a triggering event satisfying the triggering rules, please refer to the description in the following embodiments, which will not be detailed here.
[0086] S303 outputs business data to the target business system.
[0087] Since the target local injection contract includes the implementation logic for reading business data from the target business contract and outputting that business data to the target business system, executing the target local injection contract, after reading the business data from the target business contract, can also output that business data to the target business system associated with the target business contract. For example, the read business data can be written to the local database service (i.e., DB service, DataBase service) of the target business node using SQL statements configured in the target local injection contract.
[0088] The blockchain-based data processing solution provided in this application allows the blockchain system to access a target business system. The blockchain system deploys a target local injection contract with data reading and output capabilities, as well as target business contracts related to the target business system. Since only the target local injection contract needs to be deployed in the consensus network, and this contract includes a local execution strategy (meaning it executes locally and the results are not posted on the blockchain), the triggering rules and implementation logic of the local injection contract can be flexibly configured and reviewed on the blockchain. Synchronization allows the local injection contract to be synchronized to the target business node. When the target local injection contract meets the triggering rules, it executes locally, enabling the reading of business data from the target business contract and the proactive output of this data to business systems outside the blockchain system. This avoids the network and system performance overhead caused by a large number of external business systems simultaneously polling the blockchain system.
[0089] Furthermore, this application provides two methods for synchronizing the target local injection contract: one is that the target business node can synchronize the target local injection contract actively selected by the consensus node from all stored local injection contracts based on the trigger management contract; the other is that the target business node synchronizes all local injection contracts stored by the consensus node and applies the settings locally based on the trigger management contract. The former can accurately synchronize the target local injection contract from the consensus node, saving the resources required for synchronization, while the latter effectively reduces the processing pressure on the consensus node at the cost of the resources required for synchronization.
[0090] 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 blockchain-based data processing method, which is executed by the target business node in the witness network shown, includes, but is not limited to, the following steps.
[0091] S401 synchronizes blockchain data within the blockchain system.
[0092] This step can be found in the following example. Figure 3 The description of S301 in the corresponding embodiment will not be repeated here.
[0093] Before executing the target local injection contract, the following methods are included to determine whether a triggering event that meets the triggering rules has been detected, specifically S402, S403, and S404. It should be noted that the sequence numbers such as S402 and S403 in this embodiment do not constitute a limitation on the execution order, and each step is not necessarily required to be executed. For example, in this embodiment, either S402 or S403 can be executed.
[0094] The triggering rules corresponding to the target local injection contract are set by the trigger management contract, which is deployed in the blockchain system, specifically in a location such as... Figure 2b The consensus network shown is located on the core chain (i.e., the blockchain at the core consensus layer). The trigger management contract can synchronize the triggering rules corresponding to the target local injection contract to the target business node. In one embodiment, the triggering rules include a first triggering rule, which defines the target local injection contract's execution based on the associated target business contract. That is, when the triggering rule corresponding to the target local injection contract is the first triggering rule, the target local injection contract can be executed based on the associated target business contract, as detailed in section S402.
[0095] S402, During the synchronization process, when the synchronized blockchain data contains transaction data corresponding to the target business contract, it is determined that a triggering event satisfying the first triggering rule has been detected.
[0096] In other words, during the process of synchronizing blockchain data from the blockchain system, if transaction data corresponding to the target business contract is synchronized, it can be determined that the target business node has detected a trigger event that satisfies the first triggering rule. This allows the execution of the target local injection contract to be triggered. Therefore, the target local injection contract can be triggered once when the target business node locally synchronizes the transaction data corresponding to the target business contract. Under the first triggering rule, the target local injection contract is set to automatic triggering mode, meaning it can be automatically executed without manual intervention.
[0097] In another embodiment, the triggering rule includes a second triggering rule, which defines that the target local injection contract is triggered to execute based on a request sent by the target business system. That is, when the triggering rule corresponding to the target local injection contract is the second triggering rule, the target local injection contract can be triggered to execute based on a request sent by the target business system, which can be a data acquisition request. See the description in S403 for details.
[0098] S403, during the synchronization process, if a data acquisition request is received from the target business system, it is determined that a triggering event satisfying the second triggering rule has been detected.
[0099] In other words, during the synchronization process, the request sent by the target business system can be a data retrieval request. This request instructs the retrieval of business data from the target business contract associated with the target local injection contract. For example, when the target business system is a tax business system, the data retrieval request could be an invoice information query request, an invoice information issuance request, or an invoice reimbursement request, etc. During the process of the target business node synchronizing blockchain data from the blockchain system, if the target business node receives a data retrieval request from the target business system, then it can be determined that a triggering event satisfying the second triggering rule has been detected.
[0100] Optionally, the data retrieval request carries information about the required business data. The target business node executes the target local injection contract locally and can retrieve the required business data from the target business contract. Therefore, this method eliminates the need to retrieve all business data from the target business contract; the data retrieval request allows for on-demand retrieval of the business data, achieving "use as needed." Furthermore, it should be noted that under the second triggering rule, the target local injection contract is set to be manually triggered, not automatically triggered. The target business node receives manually initiated data retrieval requests and executes the target injection contract.
[0101] In another embodiment, the triggering rule includes a third triggering rule, which defines the execution of the target local injection contract based on an indicated block height and the associated target business contract. The indicated block height refers to the block height included in the content defined by the third triggering rule, specifically a range of block heights, such as blocks with heights between 1000 and 5000. The consensus nodes containing these blocks store the target business contracts associated with the target local injection contract. When the triggering rule corresponding to the target local injection contract is the third triggering rule, the target local injection contract can be executed based on the indicated block height and the associated target business contract, as detailed in section S404.
[0102] S404, during the synchronization process, if a block height indication message is received from the target business system, then when the synchronized blockchain data contains a block of the indicated block height, and the block of the indicated block height contains transaction data corresponding to the target business contract, it is determined that a trigger event satisfying the third triggering rule has been detected.
[0103] The block height indication information sent by the target business system is used to indicate the block height required to trigger the execution of the target local injection contract. Optionally, this block height indication information can be automatically initiated or manually initiated, for example, the block height indication information can be carried in a data retrieval request.
[0104] If the target business node receives the block height indication information, it can be determined that a triggering event satisfying the third triggering rule has been detected if the following two conditions are met: Condition 1: The synchronized blockchain data contains a block with the block height indicated by the block height indication information; Condition 2: The synchronized block with the block height indicated by the block height indication information contains transaction data corresponding to the target business contract. If both Condition 1 and Condition 2 are met, the target local injection contract can be triggered for execution. For example, if the block height indication information indicates a block height of 1000-5000, and the target business node synchronizes to a block with a block height of 1000-5000, and this block contains transaction data related to the target business contract A, then the target local injection contract can be triggered for execution. It should be noted that under the third triggering rule, the target local injection contract can be triggered manually or automatically.
[0105] S405 executes the target local injection contract, reads business data from the target business contract, and outputs business data to the target business system.
[0106] When a triggering event that meets the triggering rules is detected, the target local injection contract can be executed to read business data from the target business contract and output the business data to the business system.
[0107] In one embodiment, before outputting business data to the target business system, the following may also be included: obtaining the type of business data read from the target business contract; if the type of business data is business data to be updated, then outputting business data to the target business system.
[0108] The types of business data read from the target business contract include either business data to be updated or updated business data. Business data to be updated includes business data that has not been output to the target business system. That is, business data that has never appeared in the target business system and has no related records. Business data to be updated is new business data for the target business system and can be updated and stored in the target business system's database. Updated business data refers to business data that has been output to the target business system; that is, business data that has already appeared in the target business system and has related records. This updated business data can be data already recorded in the target business system's database and can be queried in the target business system's local database.
[0109] When the type of business data is business data to be updated, the business data to be updated can be further output to the target business system. For example, it can be output to the database of the target business system, or pushed to the target business system for display, etc. Optionally, outputting business data to the target business system can include the following two implementation methods.
[0110] In one implementation, the target business system opens a database interaction interface to the blockchain system. This database interaction interface can be an interface opened by the target business system's database (DB) or other data source according to the successful setting of the triggering rules on the blockchain after the triggering management contract successfully sets the triggering rules for the target local injection contract. The target business system's database may be an SQL database used for storing and processing data; the storage, modification, and deletion of object information are all handled within the SQL database. Through this database interaction interface, the target business system can provide insertable access permissions to the `user` in the SQL set in the target local injection contract, and to the information of the target business node corresponding to the target local injection contract contained in the triggering management contract, such as the domain name or URL (Uniform Resource Locator) of the target business node. In other words, data sources such as databases can provide insertable access permissions to the target business node (e.g., an SPV node) executing the target local injection contract.
[0111] Optionally, outputting business data to the target business system includes: calling a database interaction interface to write the business data into the database of the target business system. Optionally, the database interaction interface can be a write interface for writing business data into the database. By calling the write interface, the target business node can write the business data read from the target business contract into the database of the target business system, thereby realizing the updating and storage of business data.
[0112] In another implementation, the target business system and the blockchain system negotiate the data interaction method. By negotiating the data interaction method, the target business system and the blockchain system can determine the conditions and methods for business data transmission.
[0113] Optionally, business data may be output to the target business system, including: pushing business data to the target business system according to the agreed data interaction method.
[0114] The agreed-upon data interaction methods include any of the following: periodic push, real-time push, and push when the data volume reaches a threshold. Correspondingly, pushing business data to the target business system according to the agreed-upon data interaction methods can include: ① Periodic push of business data to the target business system. Periodic push can be achieved by setting a push period, for example, pushing business data to the target business system every 10 seconds. This method can save the resources required for pushing business data. ② Real-time push of business data to the target business system. Real-time push means that once the target business node reads business data from the target business contract, it can immediately push the business data to the target business system. Real-time push can proactively and promptly update the target business system with the business data acquired in real time, without requiring the business party to actively refresh the target business system to pull business data. ③ Pushing business data to the target business system when the data volume reaches a threshold. In this method, when the business data read from the target business contract accumulates to a certain amount, the accumulated business data is pushed to the target business system all at once. This method can reduce the frequency of data interaction and effectively save the resources required for data interaction.
[0115] It is evident that by using a pre-agreed data interaction method, business data can be proactively pushed to the target business system in accordance with the specified data interaction method, thereby avoiding frequent access to the blockchain system by the target business system, reducing the access pressure on the blockchain system, and reducing the performance consumed by the entire system in data transmission.
[0116] It should be noted that after business data is pushed to the target business system, the data can be displayed on the push interface provided by the target business system, or stored in local storage. Furthermore, even if the business data is updated, it can still be pushed to the target business system; that is, regardless of the data type, the retrieved business data can be pushed to the target business system.
[0117] The blockchain-based data processing solution provided in this application can utilize trigger management rules to set trigger rules for the target local injection contract. These trigger rules can be either automatically or manually triggered. Under different trigger modes, the target business node can determine the trigger event that satisfies the corresponding trigger rule based on the different data content received, and then execute the target local injection contract. The execution of the target local injection contract enables rapid integration between blockchain data in the blockchain system and the business system. Business data read from the target business contract can be actively output to the business system, for example, by writing it into the business system's database through a data interaction interface to achieve proactive data updates, or by pushing business data to the business system in real time. In this approach, since the external business system does not need to poll the blockchain system, but instead executes the local injection contract in the target business node, it can read the business data in the target business contract and actively output the business data from the blockchain system to the business system, thereby effectively reducing system performance consumption.
[0118] Regarding the content described in the foregoing embodiments, assuming the target business node is a provincial-level SPV node, the target business is tax-related business, the target business contract is a tax-related business contract, the target local injection contract is a local injection contract associated with the tax-related business contract, and the trigger management contract contains the trigger rules and permission information for the target local injection contract. This can be provided as follows: Figure 5 The diagram shows an interactive representation of data processing based on blockchain.
[0119] like Figure 5 As shown, multiple provincial SPV nodes (including provincial SPV node 1 and provincial SPV node 2) can access consensus nodes in the consensus network through the core consensus network entry point. The core consensus network entry point can be the aforementioned... Figure 2b The routing proxy layer is shown. For ease of understanding, taking the target business node as provincial SPV node 1 as an example, the interaction flow of data processing based on the blockchain system is illustrated. The interaction flow involving provincial SPV node 2 can be found in the relevant description of provincial SPV node 1, and will not be repeated here. The interaction flow between the various terminals is as follows:
[0120] 1) Provincial SPV Node 1 synchronizes blockchain data in the consensus network through the core consensus network entry point. Specifically, it can synchronize block data in the consensus node, and also synchronize at least one smart contract stored in the consensus node: local injection contract AL1, tax business contract A, and trigger management contract X. Provincial SPV Node 1 includes the local injection contract AL and tax business contract A1 synchronized from the consensus node. The same applies to Provincial SPV Node 2, which can include tax business contracts and local injection contracts (not shown in the figure) that are different from or the same as those in Provincial SPV Node 1.
[0121] For ease of description, the local injection contract AL1 will be referred to as the AL1 contract, the tax business contract A1 as the A1 contract, and the trigger management contract X as the X contract. The AL1 contract is a local injection contract that provincial SPV node 1 has execution authority over. The AL1 contract is configured to read business data (such as transaction result data) from the A1 contract and output the business data to the target business system of the SPV through the SQL statements configured in the AL1 contract. The trigger management contract X can manage the triggering rules and permission information of the local injection contract AL1. During the synchronization of the local injection contract, it can determine the AL1 contract that provincial SPV node 1 has execution authority based on the permission information and synchronize the triggering rules corresponding to that AL1 contract to provincial SPV node 1.
[0122] 2) When a trigger event satisfying the triggering rules of the local injection contract AL1 is detected, the matching SPVID (here, the node identifier of provincial SPV node 1) is triggered. Provincial SPV node 1 executes the local injection contract AL1, reads business data from the tax business contract locally, and outputs the business data to the business DB (i.e., the database of the target business system). In one embodiment, after the triggering rules of the local injection contract in contract X are successfully set, the database of the business system can provide a data interaction interface to the SPV node executing the AL1 contract based on the successful setting status, providing insertable access permissions, and then using the data interaction interface to implement the function of writing business data to the database. It should be noted that the business data that can be output to the database of the business system is the business data to be updated in the database, which has not been output to the database before. In another embodiment, the business data can also be pushed to the business system according to the data interaction method negotiated between the blockchain system and the business system, such as pushing the business data to the business system in real time or periodically.
[0123] As can be seen, since the local injection contract has configuration logic for proactive data output, the flexible deployment of local injection contracts that handle different business contracts on the blockchain can enable business nodes to synchronize to the local injection contract and execute the local injection contract synchronized from the blockchain when the triggering rules are met. This allows blockchain data in the blockchain system to be proactively output to database-based business systems outside the blockchain system, achieving rapid connection between blockchain data and business systems, avoiding external business systems polling the blockchain system, and reducing system performance consumption during data transmission.
[0124] Please see Figure 6 , Figure 6This 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, a reading module 602, an output module 603, a determination module 604, an acquisition module 605, and an execution module 606.
[0125] Synchronization module 601 is used to synchronize blockchain data in the blockchain system. The blockchain system is connected to a target business system, and a target business contract related to the target business system is deployed in the blockchain system, as well as a target local injection contract associated with the target business contract; the target local injection contract has corresponding triggering rules.
[0126] The reading module 602 is used to execute the target local injection contract and read business data from the target business contract if a triggering event that meets the triggering rules is detected during the synchronization process.
[0127] Output module 603 is used to output business data to the target business system.
[0128] 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. The method provided in this application is executed by a target business node, which is any business node in the witness network. The target business contract is related to the target business system in that the target business contract contains the business processing logic of the target business system. The target business contract is associated with the target local injection contract in that the target local injection contract is configured with the implementation logic for reading business data from the target business contract. The target local injection contract is executed locally on the target business node, and the local execution result is stored in the local storage space of the target business node.
[0129] In one embodiment, the target local injection contract is stored on the consensus node; the synchronization module 601 is also used to synchronize the target local injection contract from the consensus node.
[0130] In one embodiment, the consensus node stores N local injection contracts, each associated with a business contract; the consensus node also stores a trigger management contract, which sets the trigger rules for each local injection contract and the permission information for each local injection contract, the permission information including the identifier of the business node with execution permission for the local injection contract; the synchronization module 601 is specifically used to: send a data synchronization request to the consensus node, so that the consensus node, based on the trigger management contract and the identifier of the target business node carried in the data synchronization request, selects the target local injection contract with execution permission for the target business node from the N local injection contracts, and synchronizes the target local injection contract to the target business node; and receive the target local injection contract synchronized by the consensus node.
[0131] In another embodiment, N local injection contracts are deployed on the blockchain, and each local injection contract is associated with a business contract. The consensus node also stores a trigger management contract, which sets the trigger rules for each local injection contract and the permission information for each local injection contract. The permission information includes the identifier of the business node that has the execution permission to execute the local injection contract. The synchronization module 601 is specifically used for: sending a data synchronization request to the consensus node, causing the consensus node to respond to the data synchronization request and return N local injection contracts and the trigger management contract; receiving the N local injection contracts and the trigger management contract returned by the consensus node; and setting the target local injection contract among the N local injection contracts that the target business node has the execution permission to be effective according to the trigger management contract. Wherein, after the target local injection contract is set to be effective, it means that the target local injection contract can be executed locally on the target business node.
[0132] In one embodiment, the triggering rule includes a first triggering rule, which defines that the target local injection contract triggers execution based on the associated target business contract; the determining module 604 is used to: during the synchronization process, when the synchronized blockchain data contains transaction data corresponding to the target business contract, determine that a triggering event satisfying the first triggering rule has been detected.
[0133] In another embodiment, the triggering rule includes a second triggering rule, which defines the execution of the target local injection contract based on a request sent by the target business system; the determining module 604 is used to: during the synchronization process, if a data acquisition request sent by the target business system is received, determine that a triggering event satisfying the second triggering rule has been detected.
[0134] In another embodiment, the triggering rule includes a third triggering rule, which defines the target local injection contract to trigger execution based on the indicated block height and the associated target business contract; the determining module 604 is used to: during the synchronization process, if a block height indication information sent by the target business system is received, then when the synchronized blockchain data contains a block of the indicated block height, and the block of the indicated block height contains transaction data corresponding to the target business contract, determine that a triggering event satisfying the third triggering rule has been detected.
[0135] In one embodiment, the acquisition module 605 is used to: acquire the type of business data read from the target business contract; the execution module 606 is used to: if the type of business data is business data to be updated, then execute the output of business data to the target business system; wherein, the business data to be updated includes business data that has not been output to the target business system.
[0136] In one embodiment, the target business system opens a database interaction interface to the blockchain system; the output module 603 is specifically used to: call the database interaction interface to write business data into the database of the target business system.
[0137] In one embodiment, the target business system and the blockchain system negotiate a data interaction method; the output module 603 is specifically used to: push business data to the target business system according to the negotiated data interaction method; the negotiated data interaction method includes any of the following: periodic push, real-time push, and push when the data volume reaches a threshold.
[0138] 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.
[0139] 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.
[0140] 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).
[0141] 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.
[0142] 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).
[0143] 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.
[0144] 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 a blockchain system, wherein the blockchain system is connected to a target business system, a target business contract related to the target business system is deployed in the blockchain system, and a target local injection contract associated with the target business contract is deployed; the target local injection contract corresponds to a triggering rule; during the synchronization process, if a triggering event satisfying the triggering rule is detected, the target local injection contract is executed to read business data from the target business contract; and the business data is output to the target business system.
[0145] 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. The method provided in this application is executed by a target business node, which is any business node in the witness network. The target business contract is related to the target business system in that the target business contract contains the business processing logic of the target business system. The target business contract is associated with the target local injection contract in that the target local injection contract is configured with the implementation logic for reading business data from the target business contract. The target local injection contract is executed locally on the target business node, and the local execution result is stored in the local storage space of the target business node.
[0146] In one embodiment, the target local injection contract is stored on the consensus node; the processor 701 is also configured to: synchronize the target local injection contract from the consensus node.
[0147] In one embodiment, the consensus node stores N local injection contracts, each associated with a business contract; the consensus node also stores a trigger management contract, which sets the trigger rules for each local injection contract and the permission information for each local injection contract, the permission information including the identifier of the business node with execution permission for the local injection contract; the processor 701 is specifically used for: sending a data synchronization request to the consensus node, enabling the consensus node to select the target local injection contract with execution permission for the target business node from the N local injection contracts based on the trigger management contract and the identifier of the target business node carried in the data synchronization request, and synchronizing the target local injection contract to the target business node; and receiving the target local injection contract synchronized by the consensus node.
[0148] In another embodiment, N local injection contracts are deployed on the blockchain, and each local injection contract is associated with a business contract. The consensus node also stores a trigger management contract, which sets the trigger rules for each local injection contract and the permission information for each local injection contract. The permission information includes the identifier of the business node that has the execution permission to execute the local injection contract. The processor 701 is specifically used for: sending a data synchronization request to the consensus node, causing the consensus node to respond to the data synchronization request and return N local injection contracts and the trigger management contract; receiving the N local injection contracts and the trigger management contract returned by the consensus node; and setting the target local injection contract among the N local injection contracts that the target business node has the execution permission to activate according to the trigger management contract. Wherein, after the target local injection contract is activated, it means that the target local injection contract can be executed locally on the target business node.
[0149] In one embodiment, the triggering rule includes a first triggering rule, which defines that the target local injection contract triggers execution based on the associated target business contract; the processor 701 is configured to: during the synchronization process, when the synchronized blockchain data contains transaction data corresponding to the target business contract, determine that a triggering event satisfying the first triggering rule has been detected.
[0150] In one embodiment, the triggering rule includes a second triggering rule, which is used to define the target local injection contract to trigger execution based on a request sent by the target business system; the processor 701 is used to: during the synchronization process, if a data acquisition request sent by the target business system is received, determine that a triggering event satisfying the second triggering rule has been detected.
[0151] In one embodiment, the triggering rule includes a third triggering rule, which defines the target local injection contract to trigger execution based on the indicated block height and the associated target business contract; the processor 701 is configured to: during the synchronization process, if a block height indication information sent by the target business system is received, then when the synchronized blockchain data contains a block of the indicated block height and the block of the indicated block height contains transaction data corresponding to the target business contract, determine that a triggering event satisfying the third triggering rule has been detected.
[0152] In one embodiment, processor 701 is configured to: obtain the type of business data read from the target business contract; processor 701 is configured to: if the type of business data is business data to be updated, then execute the output of business data to the target business system; wherein, the business data to be updated includes business data that has not been output to the target business system.
[0153] In one embodiment, the target business system opens a database interaction interface to the blockchain system; the processor 701 is specifically used to: call the database interaction interface to write business data into the database of the target business system.
[0154] In one embodiment, the target business system and the blockchain system negotiate a data interaction method; the processor 701 is specifically used to: push business data to the target business system according to the negotiated data interaction method; the negotiated data interaction method includes any of the following: periodic push, real-time push, and push when the data volume reaches a threshold.
[0155] 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.
[0156] 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.
[0157] 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.
[0158] 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.
[0159] 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.
[0160] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.
[0161] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.
[0162] 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 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. Each consensus node stores N local injection contracts, and each local injection contract is associated with a business contract. The consensus node also stores a trigger management contract, which sets the trigger rules for each local injection contract and the permission information for each local injection contract. The permission information includes the identifier of the business node that has the execution permission to execute the local injection contract. The method is executed by a target service node, which is any service node in the witness network; the method includes: The blockchain data in the blockchain system is synchronized. The blockchain system is connected to a target business system, and a target business contract related to the target business system is deployed in the blockchain system. A target local injection contract associated with the target business contract is also deployed in the blockchain system. The target business contract being related to the target business system means that the target business contract contains the business processing logic of the target business system. The target business contract being associated with the target local injection contract means that the target local injection contract is configured with implementation logic for reading business data from the target business contract. The target local injection contract corresponds to triggering rules. Send a data synchronization request to the consensus node, and the consensus node responds to the data synchronization request by returning the N local injection contracts and the trigger management contract; Receive the N local injection contracts and the trigger management contract returned by the consensus node; According to the trigger management contract, the target local injection contract among the N local injection contracts that has execution permission of the target business node is enabled; wherein, after the target local injection contract is enabled, it means that the target local injection contract can be executed locally on the target business node; During the synchronization of blockchain data in the blockchain system, if a triggering event that satisfies the triggering rules corresponding to the target local injection contract is detected, the target local injection contract is executed to read business data from the target business contract; and, The business data is output to the target business system.
2. The method as described in claim 1, characterized in that, The target local injection contract is executed locally on the target business node, and the local execution result is stored in the local storage space of the target business node.
3. The method as described in claim 1, characterized in that, The triggering rule corresponding to the target local injection contract includes a first triggering rule, which defines that the target local injection contract is triggered to execute based on the associated target business contract. The method further includes: During the synchronization process, when the synchronized blockchain data contains transaction data corresponding to the target business contract, it is determined that a triggering event satisfying the first triggering rule has been detected.
4. The method as described in claim 1, characterized in that, The triggering rules corresponding to the target local injection contract include a second triggering rule, which is used to define the execution of the target local injection contract based on the request sent by the target business system; The method further includes: During the synchronization process, if a data acquisition request is received from the target business system, it is determined that a triggering event satisfying the second triggering rule has been detected.
5. The method as described in claim 1, characterized in that, The triggering rules corresponding to the target local injection contract include a third triggering rule, which is used to define the target local injection contract to trigger execution based on the indicated block height and the associated target business contract; The method further includes: During the synchronization process, if a block height indication information is received from the target business system, and the synchronized blockchain data contains a block at the indicated block height, and the block at that block height contains transaction data corresponding to the target business contract, then a trigger event satisfying the third triggering rule is detected.
6. The method as described in claim 1, characterized in that, Before outputting the business data to the target business system, the method further includes: Obtain the type of business data read from the target business contract; If the type of the business data is business data to be updated, then the step of outputting the business data to the target business system is executed; The business data to be updated includes business data that has not been output to the target business system.
7. The method according to any one of claims 1 to 6, characterized in that, The target business system opens a database interaction interface to the blockchain system; the output of the business data to the target business system includes: The database interaction interface is invoked to write the business data into the database of the target business system.
8. The method according to any one of claims 1 to 6, characterized in that, The target business system and the blockchain system negotiate the data interaction method; the step of outputting the business data to the target business system includes: According to the agreed data interaction method, the business data is pushed to the target business system; the agreed data interaction method includes any of the following: periodic push, real-time push, and push when the data volume reaches a threshold.
9. A data processing device based on blockchain, 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. Each consensus node stores N local injection contracts, and each local injection contract is associated with a business contract. The consensus node also stores a trigger management contract, which sets the trigger rules for each local injection contract and the permission information for each local injection contract. The permission information includes the identifier of the business node that has the execution permission to execute the local injection contract. The device is deployed in a target service node, which is any service node in the witness network; it includes: A synchronization module is used to synchronize blockchain data in the blockchain system. The blockchain system is connected to a target business system, and a target business contract related to the target business system is deployed in the blockchain system, along with a target local injection contract associated with the target business contract. The target business contract being related to the target business system means that the target business contract contains the business processing logic of the target business system; the target business contract being associated with the target local injection contract means that the target local injection contract is configured with implementation logic for reading business data from the target business contract; and the target local injection contract corresponds to triggering rules. The synchronization module is further configured to: send a data synchronization request to the consensus node, causing the consensus node to respond to the data synchronization request and return the N local injection contracts and the trigger management contract; receive the N local injection contracts and the trigger management contract returned by the consensus node; and, according to the trigger management contract, enable the target local injection contract among the N local injection contracts that the target business node has execution permission to execute; wherein, after the target local injection contract is enabled, it indicates that the target local injection contract can be executed locally on the target business node; The reading module is used to, during the process of synchronizing blockchain data in the blockchain system, if a trigger event that satisfies the triggering rules corresponding to the target local injection contract is detected, execute the target local injection contract and read business data from the target business contract; and, The output module is used to output the business data to the target business system.
10. 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 8.
11. 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 8.
12. 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 8.
Citation Information
Patent Citations
Block generation method and device, computer equipment and storage medium
CN111445333A
Power grid data sharing method and system based on block chain and data resource directory
CN112463843A
Data processing method and device based on smart contract and readable storage medium
CN113379422A