Data processing method and device based on layered blockchain and readable storage medium

Abstract

The application discloses a layered blockchain-based data processing method and device and a readable storage medium. The method comprises the following steps: when a business flow processor obtains a to-be-verified block with the maximum block height from a consensus node based on an association relationship, performing block verification on the to-be-verified block to obtain a block verification result; if the block verification result indicates that the verification is successful, sending business data associated with the to-be-verified block to a flow processing queue in the business flow processor in the form of a data stream, performing flow loss processing on the business data stream in the flow processing queue to obtain a flow loss processing result corresponding to the business data, performing business logic analysis on the flow loss processing result to obtain a logic analysis result corresponding to the business data, and feeding back the business to the consensus node based on the logic analysis result. The application can realize seamless connection between a real-time data stream-based business mode and a blockchain, and improve the performance of real-time business stream analysis and real-time business feedback.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a data processing method, apparatus, and readable storage medium based on a layered blockchain. Background Technology

[0002] Currently, real-time data stream analysis related to blockchain systems is typically performed by external business systems. For example, after the blockchain system generates its ledger, external business systems can proactively retrieve the ledger data for business logic analysis and related business feedback. However, due to the probabilistic determinism of blockchain (e.g., the longest chain mechanism), there is a certain delay in the general state activation and transaction submission within the blockchain system. Therefore, external business systems often use asynchronous reading to obtain the required ledger data. However, this reading method actually conflicts with the original real-time data stream-based business model. As a result, when the real-time data stream-based business model is integrated with the blockchain, the data interaction between the two is poor, leading to a decrease in the performance of related real-time business streaming analysis and real-time business feedback. Summary of the Invention

[0003] This application provides a data processing method, apparatus, and readable storage medium based on hierarchical blockchain, which can achieve seamless integration between real-time data stream-based business models and blockchain, and improve the performance of real-time business streaming analysis and real-time business feedback.

[0004] This application provides a data processing method based on a layered blockchain. This method is executed by a business flow processor. The layered blockchain includes a blockchain within a core consensus network, and the consensus nodes in the core consensus network are associated with the business flow processor. The method includes:

[0005] When the business flow processor obtains the block to be verified with the maximum block height from the consensus node based on the association relationship, it performs block verification on the block to be verified and obtains the block verification result.

[0006] If the block verification result indicates that the verification is successful, the business data associated with the block to be verified will be sent to the stream processing queue in the business stream processor as a data stream. The business data stream in the stream processing queue will be processed to obtain the churn processing result corresponding to the business data.

[0007] The business logic analysis results of the churn handling are analyzed to obtain the logical analysis results corresponding to the business data, and the business feedback is sent to the consensus node based on the logical analysis results.

[0008] This application provides a data processing method based on a layered blockchain. This method is executed by consensus nodes in a core consensus network. The layered blockchain includes blockchains within the core consensus network. The business flow processors in the core consensus network are associated with the consensus nodes. The method includes:

[0009] When a consensus node receives a data read request from a business flow processor based on the association relationship, it returns the block to be verified with the highest block height in the consensus node to the business flow processor according to the data read request. This allows the business flow processor to perform block verification on the block and obtain the block verification result. When the block verification result indicates successful verification, the business flow processor sends the business data associated with the block to be verified to the flow processing queue in the business flow processor as a data stream. It also performs churn processing on the business data stream in the flow processing queue to obtain the churn processing result corresponding to the business data. The business flow processor then performs business logic analysis on the churn processing result to obtain the logic analysis result corresponding to the business data. The logic analysis result is used to instruct the business flow processor to provide business feedback to the consensus node.

[0010] Obtain the feedback business transaction returned by the business flow processor; the feedback business transaction is generated by the business flow processor based on the results of logical analysis.

[0011] The feedback business transaction is verified. When the feedback business transaction is successfully verified, the contract state of the business contract associated with the feedback business deployed on the consensus node is changed based on the feedback business transaction.

[0012] One embodiment of this application provides a data processing device based on a layered blockchain. This device operates within a business flow processor, wherein the layered blockchain includes a blockchain in a core consensus network, and the consensus nodes in the core consensus network are associated with the business flow processor. The device includes:

[0013] The block verification module is used to perform block verification on the block to be verified when the business flow processor obtains the block to be verified with the maximum block height from the consensus node based on the association relationship, and obtain the block verification result.

[0014] The churn handling module is used to send the business data associated with the block to be verified to the stream processing queue in the business stream processor in the form of a data stream if the block verification result indicates that the verification is successful. The module then performs churn handling on the business data stream in the stream processing queue to obtain the churn handling result corresponding to the business data.

[0015] The business feedback module is used to perform business logic analysis on the churn handling results, obtain the logical analysis results corresponding to the business data, and provide business feedback to the consensus node based on the logical analysis results.

[0016] The aforementioned business flow processor includes a consensus node proxy, and the associated relationships include the data interaction relationships between the consensus node proxy and the consensus node; the device also includes:

[0017] The data request module is used to send data read requests to the consensus node through the consensus node proxy based on the data interaction relationship, so that the consensus node can return the block storage status of the consensus node and the unprocessed block with the maximum block height in the core consensus network according to the data read request;

[0018] The block determination module is used to perform block deterministic verification on the block to be processed based on the block storage state of the consensus node, and obtain the block deterministic verification result; when the block deterministic verification result is a deterministic success verification result, the block to be processed with the first block state indicated by the deterministic success verification result is taken as the block to be verified.

[0019] The consensus node consists of N nodes, where N is a positive integer; each consensus node corresponds to a block storage state; the block determination module includes:

[0020] The node determination unit is used to determine the target consensus node based on the block storage status of the N consensus nodes; the number of target consensus nodes is less than or equal to N.

[0021] The first verification unit is used to determine the block state of the block to be processed as the first block state if the number of nodes of the target consensus node is greater than the node number threshold, and to take the block to be processed with the first block state as the deterministic success verification result.

[0022] The second verification unit is used to determine the block state of the block to be processed as the second block state if the number of nodes of the target consensus node is less than or equal to the node number threshold, and to take the block to be processed with the second block state as the deterministic failure verification result.

[0023] The verification result determination unit is used to take the deterministic successful verification result or the deterministic failed verification result as the block deterministic verification result.

[0024] The aforementioned block verification module includes:

[0025] The node signature verification unit is used to obtain the set of node signatures associated with the block to be verified and the public keys of the N consensus nodes through the consensus node proxy. Based on the obtained public keys of the N nodes, the node signature set is verified to obtain the node signature verification result. The node signature set includes the node signature information obtained by each of the N consensus nodes signing the block to be verified.

[0026] The root verification unit is used to perform root verification on the Merkel root in the block to be verified if the node verification result indicates that the verification was successful, and obtain the root verification result.

[0027] The transaction verification unit is used to perform transaction verification on the transaction data associated with the Merkel root in the block to be verified if the root verification result indicates that the root verification is successful, and to obtain the transaction verification result.

[0028] The verification success unit is used to determine that the block to be verified has been successfully verified if the transaction verification result indicates that the transaction verification has been successful, and to take the successfully verified block to be verified as the block verification success result.

[0029] The verification result determination unit is used to determine the block verification result based on the node signature verification result, the root verification result, the transaction verification result, and the block verification success result.

[0030] Specifically, the verification result determination unit is used to determine that the block to be verified has failed if the node verification result indicates that the verification has failed, or the root verification result indicates that the root verification has failed, or the transaction verification result indicates that the transaction verification has failed. The block to be verified that has failed is taken as the block verification failure result; and the block verification success result or the block verification failure result is taken as the block verification result.

[0031] The aforementioned churn handling module includes:

[0032] The business data acquisition unit is used to read the transaction data of the block to be verified and the contract data associated with the transaction data from the node memory of the consensus node where the block to be verified is located through the consensus node proxy in the business flow processor, and use the read transaction data and contract data as business data associated with the block to be verified.

[0033] The data stream storage unit is used to send business data as a data stream to the stream processing queue in the business stream processor for storage, and to use the business data stored in the stream processing queue as a business data stream.

[0034] The churn handling unit is used to perform churn handling on the business data stream through the churn handling component in the business flow processor and the transformation processing engine associated with the churn handling component, and to obtain the churn handling result corresponding to the business data.

[0035] The aforementioned loss handling unit includes:

[0036] The data stream splitting sub-unit is used to pull business data streams from the stream processing queue through the churn handling component in the business stream processor, and split the pulled business data streams based on the splitting time interval to obtain at least two sub-business data streams;

[0037] The data transformation subunit is used to transmit at least two sub-business data streams to the transformation processing engine associated with the churn handling component for data transformation processing, obtain the transformation processing result corresponding to each sub-business data stream, and use the obtained at least two transformation processing results as the churn handling result corresponding to the business data.

[0038] The stream processing queue is built upon a stream proxy component. Business contracts associated with the feedback service are deployed on the consensus nodes, and these contracts register the proxy public keys of the consensus node proxies included in the business stream processors. The device also includes:

[0039] The first signature module is used to generate a data push request when the consensus node proxy obtains the first public key certificate containing the proxy public key, and to sign the data push request based on the proxy private key corresponding to the proxy public key to obtain the first signature information.

[0040] The first sending module is used to send the data push request and the first signature information to the consensus node, so that after the consensus node successfully verifies the first signature information, it performs certificate verification on the first public key certificate based on the data push request and obtains the first certificate verification result.

[0041] The first communication module is used to determine that the consensus node agent has data push permissions if the first certificate verification result indicates successful verification, and to establish a first communication connection between the consensus node agent and the stream agent component; the first communication connection is used to transmit the business data obtained by the consensus node agent to the stream agent component.

[0042] The stream processing queue is built upon a stream broker component. Business contracts associated with the feedback service are deployed on the consensus nodes, and these contracts register the public keys of the flow processing components included in the stream processor. The device also includes:

[0043] The second signature module is used to generate a data retrieval request when the churn handling component obtains a second public key certificate containing the component's public key, and to sign the data retrieval request based on the component's private key corresponding to the component's public key to obtain the second signature information.

[0044] The second sending module is used to send the data pull request and the second signature information to the consensus node, so that after the consensus node successfully verifies the second signature information, it can perform certificate verification on the second public key certificate based on the data pull request and obtain the second certificate verification result.

[0045] The second communication module is used to determine that the churn handling component has data retrieval permission if the second certificate verification result indicates successful verification, and to establish a second communication connection between the churn handling component and the stream proxy component; the second communication connection is used to transmit the business data stream stored in the stream proxy component to the churn handling component.

[0046] The business flow processor also includes a consensus node proxy and a business control component. The business control component contains a business processing engine associated with the target business logic. A business contract associated with the feedback business is deployed on the consensus node. The business contract registers the engine private key of the business processing engine.

[0047] The aforementioned business feedback module includes:

[0048] The logic analysis unit is used to call the business processing engine to perform business logic analysis on the churn handling results based on the target business logic, and obtain the logic analysis results corresponding to the business data.

[0049] The feedback signature unit is used to generate business feedback messages based on the logical analysis results, sign the business feedback messages based on the engine private key to obtain engine signature information, and return the engine signature information and business feedback messages to the consensus node proxy through the component interface of the business control component.

[0050] The engine signature verification unit is used to verify the engine signature information through the consensus node proxy and obtain the engine signature verification result.

[0051] The message forwarding unit is used to forward the business feedback message to the consensus node if the engine's signature verification result indicates that the signature verification was successful.

[0052] The aforementioned message forwarding unit includes:

[0053] The assembly signature subunit is used to process the business feedback message into a transaction if the engine verification result indicates that the verification is successful, and to obtain the feedback business transaction. The feedback business transaction is then signed based on the proxy private key of the consensus node proxy to obtain the proxy signature information.

[0054] The transaction forwarding subunit is used to forward the proxy signature information and feedback business transactions to the consensus node, so that the consensus node can reach a consensus on the proxy signature information and engine signature information. When both the proxy signature information and engine signature information have passed consensus, the contract state of the business contract is changed based on the feedback business transaction.

[0055] This application provides a data processing device based on a layered blockchain. The device operates within a consensus node in a core consensus network. The layered blockchain includes the blockchain within the core consensus network, and the business flow processors in the core consensus network are associated with the consensus nodes. The device includes:

[0056] The block acquisition module is used to, when a consensus node receives a data read request from a business flow processor based on an association relationship, return the block to be verified with the highest block height in the consensus node to the business flow processor, so that the business flow processor can perform block verification and obtain a block verification result. When the block verification result indicates successful verification, the business flow processor sends the business data associated with the block to be verified to the flow processing queue in the business flow processor as a data stream, and performs churn processing on the business data stream in the flow processing queue to obtain the churn processing result corresponding to the business data. The business flow processor performs business logic analysis on the churn processing result to obtain the logic analysis result corresponding to the business data. The logic analysis result is used to instruct the business flow processor to provide business feedback to the consensus node.

[0057] The feedback acquisition module is used to acquire feedback business transactions returned by the business flow processor; the feedback business transactions are generated by the business flow processor based on the results of logical analysis.

[0058] The state change module is used to verify feedback business transactions. When the feedback business transaction is successfully verified, the contract state of the business contract associated with the feedback business deployed on the consensus node is changed based on the feedback business transaction.

[0059] The aforementioned status change module includes:

[0060] The signature acquisition unit is used to acquire the proxy signature information and engine signature information associated with the feedback business transaction. The feedback business transaction is obtained by the consensus node proxy in the business flow processor after assembling and processing the business feedback message. The proxy signature information is obtained by the consensus node proxy signing the feedback business transaction based on the proxy private key. The business feedback message is a message generated by the business processing engine contained in the business control component in the business flow processor based on the logical analysis results. The engine signature information is obtained by the business processing engine signing the business feedback message based on the engine private key.

[0061] The first consensus unit is used to reach a consensus on the proxy signature information and obtain the first consensus result.

[0062] The second consensus unit is used to reach consensus on the engine signature information when the first consensus result indicates that the consensus on the proxy signature information has passed, and to obtain the second consensus result.

[0063] The successful verification unit is used to confirm and provide feedback that the business transaction has been successfully verified when the second consensus result indicates that the engine signature information consensus has been passed.

[0064] One embodiment of this application provides a computer device, including: a processor and a memory;

[0065] The processor is connected to a memory, which stores a computer program. When the computer program is executed by the processor, it causes the computer device to perform the method provided in the embodiments of this application.

[0066] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided in this application.

[0067] One embodiment of this application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in this application embodiment.

[0068] In this embodiment, the layered blockchain includes a blockchain within a core consensus network. This core consensus network contains consensus nodes and business flow processors with associated relationships. When a business flow processor obtains a block with the highest block height from a consensus node based on this association, it can perform block verification to obtain a verification result. Further, if the verification result indicates successful verification, the business data associated with the block to be verified can be sent as a data stream to the flow processing queue in the business flow processor. This allows for the handling of the business data stream in the flow processing queue, resulting in a loss processing result. Subsequently, business logic analysis can be performed on this loss processing result to obtain the corresponding logic analysis result, which can then be used to provide business feedback to the consensus node. Therefore, within the core consensus network, the business flow processor can instantly obtain real-time data streams (i.e., business data streams) from the blockchain for rapid business logic analysis and corresponding business feedback, while ensuring consistency and reliability of on-chain and off-chain data. This enables seamless integration between real-time data stream-based business models and the blockchain. Furthermore, since the business data stream is processed for churn before the business logic analysis, and the churn results are processed and analyzed with low latency, the performance of real-time business streaming analysis and real-time business feedback can be further improved. Attached Figure Description

[0069] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0070] Figure 1 This is a schematic diagram of a layered structure of a blockchain network provided in an embodiment of this application;

[0071] Figure 2 This is a schematic diagram of a data processing scenario based on a layered blockchain provided in an embodiment of this application;

[0072] Figure 3 This is a flowchart illustrating a data processing method based on a layered blockchain provided in an embodiment of this application;

[0073] Figure 4 This is a schematic diagram illustrating the deployment logic of a stream processing queue provided in an embodiment of this application;

[0074] Figure 5 This is a flowchart illustrating a data processing method based on a layered blockchain provided in an embodiment of this application;

[0075] Figure 6 This is a schematic diagram of the interaction process of a data processing method based on a layered blockchain provided in an embodiment of this application;

[0076] Figure 7 This is a system architecture diagram of real-time business flow feedback in a tax blockchain provided in an embodiment of this application;

[0077] Figure 8 This is a system architecture diagram for a blockchain electronic invoice scenario provided in an embodiment of this application;

[0078] Figure 9 This is a schematic diagram of the structure of a data processing device based on a layered blockchain provided in an embodiment of this application;

[0079] Figure 10 This is a schematic diagram of the structure of a data processing device based on a layered blockchain provided in an embodiment of this application;

[0080] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0081] Figure 12 This is a schematic diagram of the structure of a data processing system provided in an embodiment of this application. Detailed Implementation

[0082] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0083] Please see Figure 1 , Figure 1 This is a schematic diagram of a layered structure of a blockchain network provided in an embodiment of this application. Figure 1 The illustrated layered blockchain network structure can be applied to blockchain systems. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is primarily used to organize data chronologically and encrypt it into a ledger, making it tamper-proof and forgery-proof, while also enabling data verification, storage, and updates. Essentially, a blockchain is a decentralized database where each node stores the same blockchain entry. The layered blockchain network structure in this embodiment can be found in [reference needed]. Figure 1 The blockchain network 1W shown represents a complete blockchain business system that can be developed by... Figure 1 It consists of the business network (i.e., the business layer), the core consensus network (i.e., the core consensus layer), and the routing network (i.e., the routing proxy layer).

[0084] It is understood that the embodiments of this application can isolate the business network and the core consensus network through the routing network in the blockchain network 1W. For example, the peer-to-peer (P2P) network can be layered through the routing nodes in the routing network to form a hierarchical structure such as "business network - core consensus network", thereby improving the confidentiality and security of data on the blockchain. The number of routing nodes in the routing network can be one or more, and is not limited here. For example, as... Figure 1 As shown, the routing network may specifically include node 120a, node 120b, node 120c, ..., node 120k.

[0085] It is understood that the business network (also known as the witness network) in this embodiment is independent of the core consensus network. The business network can consist of one or more nodes, and there is no limit to the number of nodes in the business network. For example, Figure 1As shown, the business network may specifically include nodes 110a, 110b, 110c, ..., 110n. In this embodiment, the nodes in the business network can be referred to as business nodes. These business nodes do not need to participate in the accounting consensus; they are mainly used to execute transaction business to obtain transaction data associated with the transaction business and to perform data clearing and synchronization in a timely manner. A business node can be a full node containing a complete blockchain database, or a lightweight node storing a portion of the data in the blockchain database. This type of node can complete transaction verification through "Simplified Payment Verification (SPV)," and therefore can also be called an SPV node. The type of business node is not limited here. For example, in some embodiments, to reduce the waste of storage space for business nodes, the business node can be a lightweight node. This business node does not need to store complete transaction data, but instead obtains block header data and partially authorized visible block data (e.g., transaction data associated with the business node itself) from the core consensus network through identity authentication.

[0086] It is understood that the core consensus network in this embodiment may also consist of one or more nodes, and the number of nodes in the core consensus network is not limited here. For example, Figure 1 As shown, the core consensus network may specifically include nodes 130a, 130b, 130c, ..., 130m. In this embodiment, the nodes in the core consensus network can be referred to as consensus nodes (i.e., accounting nodes), and these consensus nodes can run blockchain consensus protocols. Specifically, the consensus node in this embodiment can be a full node containing a complete blockchain database. This consensus node can participate in verifying and broadcasting transaction data and block information, and can discover and maintain connections with other nodes.

[0087] It should be understood that in this application embodiment, routing nodes, business nodes, and consensus nodes can be collectively referred to as blockchain nodes in the blockchain network. A blockchain node can be a server accessing the blockchain network or an object terminal accessing the blockchain network; the specific form of the blockchain node is not limited here. The server can be a single physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing 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 artificial intelligence platforms. The object terminal can be a smartphone, tablet, laptop, desktop computer, PDA, mobile internet device (MID), wearable device (e.g., smartwatch, smart bracelet), smart computer, smart vehicle, or other smart terminal associated with the business object. The business object refers to the participants in the blockchain business system, such as users requesting transaction execution, users requesting smart contract deployment, and relevant business management departments.

[0088] Understandable Figure 1 The business network and core consensus network shown can reside in different network environments. For example, in some embodiments, business nodes can be deployed in a public business network, while consensus nodes running the blockchain consensus protocol can be deployed in a private core consensus network. The two can interact through routing boundaries. In this case, since the core consensus network is located in a relatively secure private cloud, their mutual access is inherently secure due to the consensus mechanism, requiring no additional identity management or network control. However, business nodes are located in a public network and may be accessed by other uncertain network terminals. Therefore, the access of business nodes and other potential nodes to the core consensus network needs to be strictly controlled. Optionally, in other embodiments, business nodes and consensus nodes can also transmit data directly without going through routing nodes; this is not limited here.

[0089] Furthermore, it should be noted that smart contracts can be deployed in a blockchain system. A smart contract in a blockchain system can be understood as code that can be understood and executed by each node in the blockchain (e.g., a consensus node), capable of executing arbitrary logic and obtaining results. In this application embodiment, smart contracts deployed on consensus nodes and associated with feedback business are collectively referred to as business contracts. Business objects (e.g., users requesting transaction execution) can invoke the business contracts already deployed on the consensus node by initiating a contract call request (also known as a transaction request) through a client on their terminal. It should be understood that a blockchain system can include one or more smart contracts. These smart contracts (e.g., business contracts) can be distinguished by contract identifiers (e.g., identity document, ID, or name, and may also include contract address or contract function name). The contract call request initiated by the client can also carry the smart contract's identifier or name to specify the smart contract that the blockchain needs to run. If the smart contract specified by the client requires data to be read, the relevant nodes can access local storage to read the data. For transactions that need to be recorded on the blockchain, the consensus nodes will verify each other's execution results (that is, reach a consensus). If they are consistent, the execution results can be stored in their respective local ledgers and returned to the client.

[0090] For ease of understanding, this application embodiment refers to a blockchain maintained using a layered blockchain network structure as a layered blockchain. This layered blockchain may include a blockchain in the core consensus network (also known as the target blockchain) and a blockchain in the business network (also known as the local blockchain). Under this layered structure of "business network—core consensus network," to achieve seamless integration between the real-time data stream-based business model and the blockchain, this application embodiment adds a business flow processor (e.g., ...) to the core consensus network. Figure 1The business flow processor 130 shown can perform real-time business streaming analysis and provide real-time business feedback in the core consensus network. It should be noted that the business flow processor 130 in this embodiment has an association relationship with each consensus node in the core consensus network. For example, the business flow processor 130 is associated with node 130a, and the business flow processor 130 is associated with node 130m. Therefore, based on these association relationships, the business flow processor can uniformly read relevant business data from multiple consensus nodes for real-time processing. For example, the business flow processor 130 can obtain business data related to the latest block from consensus node 130a for real-time processing. It can be understood that the business flow processor here can be a single physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing 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 artificial intelligence platforms. No limitation is made here.

[0091] Specifically, the business flow processor can obtain the block to be verified with the highest block height from the consensus node based on its association with the consensus node. This block to be verified is the highest-height block in the core consensus network that has already been confirmed. Furthermore, the business flow processor can perform block verification on this block to obtain the corresponding verification result. If the verification result indicates successful verification, the business data associated with the block to be verified can be sent as a data stream to the flow processing queue in the business flow processor. This allows for churn processing of the business data stream in the flow processing queue to obtain the corresponding churn processing result. Subsequently, the churn processing result can be quickly and efficiently analyzed for business logic to obtain the corresponding logical analysis result. This logical analysis result can then be used to provide business feedback to the consensus node, enabling the consensus node to adjust the contract state of the relevant business contracts in real time based on this feedback. It is understood that the business flow processor in this application embodiment can instantly obtain real-time data streams (i.e. business data streams) on the blockchain to perform rapid business logic analysis and corresponding business feedback, while ensuring the consistency and reliability of on-chain and off-chain data. This can conveniently provide seamless integration with the blockchain for business models based on real-time data streams and improve the performance of real-time business streaming analysis and real-time business feedback.

[0092] For better understanding, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram of a data processing scenario based on a layered blockchain, provided in an embodiment of this application. For example... Figure 2 As shown, in this embodiment, consensus node 20A can be a consensus node with business contracts deployed in the core consensus network. This consensus node 20A can be the aforementioned... Figure 1 The core consensus network shown can be any consensus node, for example, consensus node 130a. In this embodiment, the service flow processor 20B is associated with consensus node 20A, and the service flow processor 20B can be the aforementioned... Figure 1 The service flow processor 130 in the core consensus network shown.

[0093] In this embodiment, each consensus node in the core consensus network can store the same blockchain. However, due to network transmission latency, differences in data processing capabilities, etc., there will be a time lag in data updates (e.g., the addition of new blocks) in the memory of each consensus node. Therefore, the latest block height read from different consensus nodes at the same time may also be inconsistent. To obtain reliable, real-time business data, the business flow processor 20B can first determine whether the block with the largest block height in the core consensus network has been confirmed by these consensus nodes by collecting the block storage status of each consensus node in the core consensus network. For example, taking consensus node 20 as an example, consensus node 20 can be a full node, which can store complete blocks. Assuming that consensus node 20 stores blockchain 20, such as... Figure 2 As shown, the blockchain 20 can include m blocks, namely block 1, block 2, ..., block m. The block storage status of consensus node 20 can indicate which blocks are stored in the blockchain 20 of consensus node 20. It can be understood that the maximum block height of the nodes on blockchain 20 at this time is m, that is, the block height of the latest block currently stored by consensus node 20 is m. Similarly, the block storage status of other consensus nodes in the core consensus network can also be obtained to determine the block with the maximum block height in the entire core consensus network. For ease of distinction, this embodiment of the application can use the block with the maximum block height as the block to be processed. Figure 2 As shown, assuming the current maximum block height in the core consensus network is m, the block m corresponding to this maximum block height can be taken as the block to be processed. Furthermore, to determine whether block m has been confirmed by consensus nodes in the core consensus network, the service flow processor 20B can perform block determinism verification on block m based on the acquired block storage status to obtain the block determinism verification result 201 corresponding to block m. For example, the block determinism verification result can be determined by judging whether the number of consensus nodes that have stored block m reaches a preset node number threshold.

[0094] It is understandable that when the block deterministic verification result 201 indicates successful verification, the successfully verified block m can be used as the block to be verified in the subsequent block verification. For ease of explanation, the block to be verified 202 will be used to represent the block m that has passed the block deterministic verification. In this embodiment of the application, in order to ensure the consistency of on-chain and off-chain data, the business flow processor 20B needs to further perform block verification on the block to be verified 202. Specifically, this may include the verification of the relevant node signature information, the verification of the Merkle root in the block to be verified 202, and the verification of the transaction data associated with the Merkle root in the block to be verified 202. Finally, the block verification result 203 corresponding to the block to be verified 202 can be obtained.

[0095] It is understood that when the block verification result 203 indicates successful verification, the business flow processor 20B can obtain the business data 204 associated with the block to be verified 202. This business data 204 may include transaction data from the block to be verified 202 and contract data associated with that transaction data. The transaction data can be generated by one or more business nodes in the business network executing transaction services. Correspondingly, the contract data may include the data status of each related business object after calling the corresponding business contract to execute the transaction service. This transaction service can be an asset transfer service, which can be used to transfer virtual assets such as electronic invoices, game coins, and game diamonds. The type of virtual asset is not limited here. Alternatively, this transaction service can be a file transfer service, which can be used to transfer various forms of electronic documents such as electronic contracts and electronic documents. Furthermore, this transaction service can also be a query service, a storage service, etc., which are not limited in this application. For example, the transaction data in the business data 204 may include transaction data A1 generated when business object 1 transfers virtual assets (e.g., electronic tickets, game coins, game diamonds, etc.) to business object 2. The contract data A2 related to the transaction data A1 may be the remaining asset amount of business object 1 and the remaining asset amount of business object 2 after business object 1 transfers a certain amount of virtual assets to business object 2.

[0096] Furthermore, the service flow processor 20B can send the service data 204 as a data stream to the flow processing queue 205 in the service flow processor 20B for storage. The flow processing queue 205 can be a message queue with characteristics such as distributed nature, high throughput, and high scalability. Since the flow processing queue 205 continuously receives real-time data (e.g., service data 204) from the consensus nodes, the service data in the flow processing queue 205 can be used as a service data stream (e.g., service data stream 206).

[0097] Furthermore, the business flow processor 20B can perform churn processing on the business data stream 206 in the flow processing queue 205. Specifically, it can perform data stream segmentation and data transformation on the business data stream 206, thereby converting the flow processing into a series of continuous micro-batch processing, and finally obtaining the corresponding churn processing results 207 in batches. Subsequently, by calling the business processing engine deployed in the business flow processor 20B, business logic analysis can be performed on the obtained churn processing results 207, thereby obtaining the logic analysis result 208 corresponding to the business data 204. Then, the business flow processor 20B can provide business feedback to the consensus node 20A based on the logic analysis result 208, so that the consensus node 20A can make corresponding adjustments on the chain.

[0098] Understandably, in practical applications, business objects can add different business processing engines to the business flow processor 20B to introduce different business logic according to business needs, thereby realizing corresponding business feedback. Different business feedbacks can be executed for different transaction businesses, and multiple business feedbacks can be executed for the same transaction business; this is not limited here. For example, suppose business object 3 (e.g., a tax administrator) adds a business processing engine B related to invoicing control rules to the business flow processor 20B. These invoicing control rules can be used to instruct business objects with invoicing permissions (e.g., business object 4, which could be an invoicing service provider) on the threshold number of electronic invoices they can issue within a certain time period. The business flow processor 20B can continuously receive electronic invoices issued by business object 4 and use business processing engine B to perform real-time statistics on the number of received electronic invoices. Suppose that the number of electronic invoices counted between 10:00 AM and 11:00 AM has reached the threshold number of invoices indicated by the invoicing control rules (e.g., 100 invoices), then the business flow processor 20B can report to the consensus node 20A to restrict the invoicing behavior of business object 4.

[0099] Therefore, the business flow processor 20B in this embodiment can instantly acquire real-time data (such as business data 204) from the blockchain 20 for rapid business logic analysis and corresponding business feedback, while ensuring the consistency and reliability of on-chain and off-chain data. This allows for seamless integration with the blockchain for business models based on real-time data streams. Furthermore, since the business flow processor 20B performs flow processing on the business data stream 206 before business logic analysis, and performs low-latency processing and analysis on the resulting flow processing result 207, the performance of real-time business streaming analysis and real-time business feedback can be further improved.

[0100] It should be understood that the methods provided in this application embodiment can be applied to business scenarios such as transferring virtual assets (e.g., electronic invoices, game coins, game diamonds), transferring electronic documents (e.g., electronic contracts, electronic official documents), or other business scenarios that require real-time audit analysis and real-time business feedback.

[0101] Furthermore, it is understood that in the specific implementation of this application, business data of users, enterprises, institutions and other business objects may be involved (e.g., users' invoicing information, credit information, tax refund information, etc., and enterprises' income and loss, enterprise qualifications and other information). When the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain the permission or consent of users, enterprises, institutions and other business objects, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of relevant countries and regions.

[0102] In this hierarchical structure of "business network - core consensus network", the business flow processor in the core consensus network can obtain the block to be verified with the maximum block height. When the block to be verified is successfully verified, it performs flow processing, business logic analysis, and business feedback on the business data stream associated with the block to be verified in the flow processing queue. The specific implementation methods are as follows: Figures 3-8 The corresponding implementation examples.

[0103] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a data processing method based on a hierarchical blockchain provided in an embodiment of this application. Figure 3 As shown, this method can be executed by a service flow processor, which can be a server deployed in the core consensus network or an object terminal connected to the core consensus network. The specific form of the service flow processor is not limited here; it can be any of the aforementioned... Figure 1 The core consensus network shown includes a service flow processor 130. This method may include at least the following steps S101-S103:

[0104] Step S101: When the business flow processor obtains the block to be verified with the maximum block height from the consensus node based on the association relationship, it performs block verification on the block to be verified and obtains the block verification result.

[0105] It is understood that the layered blockchain in this application embodiment may include the blockchain in the core consensus network, and the consensus nodes in the core consensus network are associated with the business flow processor (also known as the business flow processing system). Therefore, the business flow processor can obtain real-time data from the consensus nodes based on this association.

[0106] The business flow processor may include a consensus node proxy, and the aforementioned relationship may include the data interaction relationship between the consensus node proxy and the consensus node. That is, the consensus node proxy can be used to interact with the consensus node, such as reading real-time data from the consensus node and subsequently assisting in providing business feedback to the consensus node. It can be understood that the consensus node proxy here can provide a unified proxy for the consensus nodes in the core consensus network, that is, provide load balancing for reading data, so that the business flow processor can read real-time data evenly from multiple consensus nodes. The number of consensus node proxies can be one or more; this embodiment does not limit this. Optionally, when there are multiple consensus node proxies in the business flow processor, different consensus node proxies can be used to handle different feedback services. For example, consensus node proxy 1 can be used for risk assessment-related feedback services, and consensus node proxy 2 can be used for business freezing-related feedback services, thereby increasing the throughput of the business flow processor and enhancing its real-time data processing capabilities.

[0107] Based on this, the service flow processor can obtain the block to be verified with the maximum block height from the consensus node based on the association relationship with the consensus node. In one implementation, the service flow processor can send a data read request to the consensus node through the consensus node proxy based on the above data interaction relationship. The data read request can be generated and sent by the consensus node proxy, so that the consensus node can return the block storage status of all consensus nodes and the block to be processed with the maximum block height in the core consensus network according to the data read request. The block storage status can be used to indicate all the blocks currently stored by the corresponding consensus node or the latest block currently stored. For example, if a consensus node has written block 1, block 2, ..., block 8 into storage, the corresponding block storage status can include the block heights corresponding to these 8 blocks (i.e., block 1 to block 8), or it can be the block height corresponding to the latest block 8. Furthermore, in this embodiment, the block to be processed refers to the block with the largest block height among all the blocks stored by all consensus nodes, and also the block with the largest generation timestamp. For ease of understanding, the block height of the latest block currently stored by a consensus node can be taken as the maximum block height of the node corresponding to that consensus node. For example, assuming that the core consensus network includes consensus node 1, consensus node 2 and consensus node 3, the maximum block height of the nodes corresponding to consensus node 1 and consensus node 2 is 8, while the maximum block height of the node corresponding to consensus node 3 is 7, then the maximum block height in the core consensus network is 8. Therefore, the data read request can be used to instruct these consensus nodes to take the block corresponding to block height 8 as the block to be processed.

[0108] Furthermore, the consensus node proxy in the business flow processor can perform block deterministic verification on the block to be processed based on the block storage state of the aforementioned consensus node to obtain the block deterministic verification result. For ease of understanding, it can be assumed that the number of consensus nodes in the core consensus network is N, where N is a positive integer, and one consensus node corresponds to one block storage state. Then, the consensus node proxy can select the consensus node that has stored the block to be processed among the N consensus nodes as the target consensus node based on the block storage state corresponding to each of the N consensus nodes. The number of target consensus nodes is less than or equal to N. That is, when the block storage state of a certain consensus node indicates that the maximum block height of the node corresponding to that consensus node is equal to the aforementioned maximum block height, that consensus node can be selected as the target consensus node. Optionally, if the number of target consensus nodes exceeds a node count threshold, the block state of the block to be processed can be determined as the first block state, and the block to be processed with the first block state can be used as a deterministic success verification result. This first block state can indicate that the block to be processed has been confirmed. Conversely, if the number of target consensus nodes is less than or equal to the node count threshold, the block state of the block to be processed can be determined as the second block state, and the block to be processed with the second block state can be used as a deterministic failure verification result. This second block state can indicate that the block to be processed has not been confirmed. Ultimately, either the deterministic success verification result or the deterministic failure verification result can be used as the block's deterministic verification result. It is understood that when the block's deterministic verification result is a deterministic success verification result, the block to be processed with the first block state indicated by the deterministic success verification result can be used as the block to be verified for block verification.

[0109] It should be noted that the layered blockchain in this application embodiment can adopt a blockchain consensus protocol with instant determinism. Compared with a blockchain consensus protocol with probabilistic determinism, newly added blocks do not need to wait for confirmation by 6 blocks. Instead, confirmation can be completed when most consensus nodes reach a consensus (e.g., the number of consensus nodes that reach a consensus reaches a specified threshold), thereby improving block confirmation efficiency. In this application embodiment, block determinism verification can also be called block determinism determination. It is mainly used to confirm that the block containing real-time data that can be used for business processing (the block to be processed) has completely completed the consensus stage and has been finally confirmed. It can be understood that in the case of blockchain forks, block determinism verification can determine whether the block to be processed is on the longest chain. In some embodiments, the number of consensus nodes N = 3F + 1, where F is the maximum number of malicious nodes in the core consensus network. A block to be processed with the maximum block height is confirmed to have passed consensus only when it has been written to permanent storage by at least (2F + 1) of the (3F + 1) consensus nodes (i.e., the node number threshold), or in other words, when the ratio of the number of target consensus nodes to N is greater than 2 / 3. As can be seen from the above, the method provided in this application embodiment can improve the efficiency of the business flow processor in acquiring real-time data and ensure the consistency of the acquired real-time data on-chain and off-chain.

[0110] In this embodiment, the consensus node proxy can be a server in the business flow processor or a functional module within the business flow processor; the specific form of the consensus node proxy is not limited here. The consensus node proxy can randomly interact with any consensus node. For example, at time T1, the consensus node proxy can read data from consensus node 1; at time T2, the consensus node proxy can read data from consensus node 2. The consensus node receiving the data read request (e.g., consensus node 1) can broadcast the data read request to other consensus nodes for request verification. For example, each consensus node can verify the request signature information obtained by the consensus node proxy signing the data read request to verify the identity and permissions of the consensus node proxy. When the verification is successful, the consensus node (e.g., consensus node 1) can return the block storage status of each consensus node and the corresponding unprocessed blocks to the consensus node proxy based on the data read request.

[0111] Optionally, in another implementation, the consensus node proxy in the business flow processor can first obtain the block storage status corresponding to each of the N consensus nodes. Then, it can determine the maximum block height based on the obtained N block storage statuses. For example, it can determine the maximum block height of the corresponding consensus node based on each block storage status, and the node with the largest value among the N maximum block heights can be used as the maximum block height. Subsequently, the consensus node proxy can use these N block storage statuses to select the consensus node among the N consensus nodes that already stores the block corresponding to the maximum block height as the target consensus node. It can be understood that when the number of target consensus nodes exceeds a node number threshold, the consensus node proxy can generate a data read request based on the maximum block height and send the data read request to the consensus node. This data read request can be used to instruct the consensus node to treat the block with the maximum block height as a pending block and return the pending block to the consensus node proxy.

[0112] Understandably, after the business flow processor sends a data read request to the consensus node through the consensus node proxy, as mentioned above, the consensus node can return its block storage status and the complete block to be processed based on the data read request. Alternatively, to save transmission bandwidth, the consensus node can also return its block storage status. After the consensus node proxy performs block deterministic verification on the block to be processed based on the block storage status, it can then choose whether to request relevant data from the consensus node based on the obtained block deterministic verification result. For example, if the block deterministic verification result is a successful deterministic verification result, the consensus node proxy can obtain data related to the block to be verified from the consensus node, such as data required for subsequent block verification, business data that needs to be transmitted to the flow processing queue after successful verification, etc.

[0113] Furthermore, to ensure the integrity and consistency of data both on-chain and off-chain, the business flow processor needs to perform block verification on the block to be verified to obtain the block verification result. The specific process can be as follows: The consensus node proxy obtains the node signature set associated with the block to be verified, as well as the public keys of the N consensus nodes. These N consensus nodes can form a consensus node committee. Correspondingly, the node signature set can also be called the consensus node committee signature set (QC). This node signature set can include the node signature information obtained by each of the N participating consensus nodes signing the block to be verified using their respective private keys. This can be used to determine whether the data state has reached a consensus in a blockchain system with Byzantine nodes. Subsequently, the business flow processor can perform node signature verification on the node signature set based on the obtained N node public keys to obtain the node signature verification result. In this process, the public key of a consensus node can be used to verify the signature information of one node in the node signature set. For ease of understanding, let's take verifying one node signature Q as an example: During the process of packaging and uploading the block to be verified onto the chain, consensus node P can perform a hash operation on all block content (including block header and block body) or part of the block content (e.g., the block body) to obtain the digest information H of the block to be verified. Then, based on the private key of consensus node P, it can digitally sign the digest information H to obtain the node signature information Q corresponding to the block to be verified. Further, when the business flow processor obtains the block to be verified and the node signature information Q through the consensus node proxy D, it can obtain the public key of consensus node P. Then, based on this public key, it can perform node signature verification on the node signature information Q to obtain the corresponding sub-verification result. In this process, it can be understood that consensus node proxy D can verify the digital signature in the node signature information Q of consensus node P based on the node's public key, obtaining the digest information H of the block to be verified. It can then use the same hash algorithm as consensus node P to perform a hash operation on the content of the same block in the block to be verified, thereby obtaining the digest information h of the block to be verified. Further, consensus node proxy D can compare the digest information H obtained after verification with the digest information h obtained from the hash operation to obtain a sub-verification result. If the sub-verification result indicates that the digest information H and the digest information h are different, it can be understood that the node signature information Q has failed to be verified; if the sub-verification result indicates that the digest information H and the digest information h are the same, it can be understood that the node signature information Q has been successfully verified. It can be understood that after verifying the node signature information of N nodes in the node signature set, sub-verification results corresponding to each node signature information can be obtained, and these N sub-verification results are used as the node signature verification result.When all N sub-signature verification results indicate successful verification, the business flow processor can determine that the node signature set has been successfully verified, indicating that the block content in the area to be verified has not been maliciously tampered with and is genuine and valid; when there is a sub-signature verification result among the N sub-signature verification results indicating verification failure, the business flow processor can determine that the node signature set has failed verification.

[0114] Furthermore, if the node verification result indicates successful verification, then root verification and transaction verification can be performed on the block to be verified to confirm the integrity and consistency of the data in the block. It can be understood that the consensus node proxy can perform root verification on the Merkle root in the block to be verified, obtaining a root verification result. If the root verification result indicates successful root verification, then transaction verification can be further performed on the transaction data associated with that Merkle root in the block to be verified, obtaining a transaction verification result.

[0115] In some embodiments, the consensus node agent can obtain the comparison tree roots associated with the block to be verified on each consensus node. These comparison tree roots can be determined by the consensus node based on the transaction hash values ​​corresponding to the transaction data in the block to be verified. Then, the obtained N comparison tree roots can be compared with the Merkle tree roots in the block to be verified to obtain the tree root verification result. If the tree root verification result indicates that the number of comparison tree roots in the N comparison tree roots that match the Merkle tree root is greater than the tree root number threshold, the consensus node agent can determine that the tree root verification is successful; conversely, if the tree root verification result indicates that the number of comparison tree roots in the N comparison tree roots that match the Merkle tree root is less than or equal to the tree root number threshold, the consensus node agent can determine that the tree root verification has failed. The tree root number threshold can be set according to actual needs and is not limited here. For example, when N = 3F + 1, the tree root number threshold can be set to (2F + 1).

[0116] Understandably, when the root verification result indicates successful root verification, the consensus node agent can obtain the transaction data to be compared associated with the root to be compared on each consensus node. This transaction data can be obtained by the consensus nodes executing the transaction list packaged into the block to be verified in parallel. This transaction list can include one or more transactions to be verified; the number of transactions to be verified is not limited here. Therefore, each set of transaction data to be compared will contain transaction data corresponding to one or more transactions to be verified. Subsequently, the N sets of transaction data to be compared can be compared with the transaction data in the block to be verified to obtain the transaction verification result. If the transaction verification result indicates that the number of matching transaction data in the N sets of transaction data is greater than the transaction number threshold, the consensus node agent can determine that the transaction verification is successful; conversely, if the transaction verification result indicates that the number of matching transaction data in the N sets of transaction data is less than or equal to the transaction number threshold, the consensus node agent can determine that the transaction verification has failed. The transaction quantity threshold can be set according to actual needs and is not limited here. For example, when N = 3F + 1, the transaction quantity threshold can be set to (2F + 1). It should be noted that the transaction comparison also includes the comparison of contract data associated with the transaction data. This contract data can include the write dataset generated after executing the transaction to be verified by calling a specified business contract. After each consensus node calls the same business contract to execute the same transaction to be verified and obtains the corresponding transaction data to be compared, it can obtain the contract data to be compared associated with that transaction data from the consensus node. Then, the obtained N sets of contract data to be compared can be compared with the aforementioned contract data. Finally, the transaction verification result can be determined by combining the results of the transaction data comparison. It can be understood that only when the transaction data to be compared A is consistent with the transaction data X, and the contract data B associated with the transaction data A is consistent with the contract data Y associated with the transaction data X, is it determined that the transaction data A and the transaction data X are truly consistent.

[0117] Optionally, in other embodiments, after the consensus node determines the root tree to be compared, each consensus node performs a root comparison between its obtained root tree and the Merkel root tree, and returns its own root comparison result to the consensus node agent. The consensus node agent then statistically analyzes the N root comparison results to obtain a root verification result. When the root verification result indicates that the number of matching results among the N root comparison results is greater than the root number threshold, the consensus node agent can determine that the root verification is successful. Similarly, when the above root verification result indicates successful root verification, each consensus node can perform a transaction comparison between its obtained transaction data and the transaction data, and return its own transaction comparison result to the consensus node agent. The consensus node agent then statistically analyzes the N transaction comparison results to obtain a transaction verification result. When the transaction verification result indicates that the number of matching results among the N transaction comparison results is greater than the transaction number threshold, the consensus node agent can determine that the transaction verification is successful.

[0118] Furthermore, if the transaction verification result indicates that the transaction verification is successful, then the block to be verified can be determined to be successfully verified. The consensus node agent can take the successfully verified block to be verified as the block verification success result. In other words, only when the node signature verification result indicates that the signature verification is successful, the root verification result indicates that the root verification is successful, and the transaction verification result indicates that the transaction verification is successful, can the consensus node agent finally determine that the block to be verified is successfully verified.

[0119] It is understandable that the consensus node proxy can also determine the block verification result of the block to be verified based on the aforementioned node signature verification results, root verification results, transaction verification results, and block verification success results. Specifically, if the node signature verification result indicates signature failure, or the root verification result indicates root verification failure, or the transaction verification result indicates transaction verification failure, then the block to be verified can be determined to have failed verification. The consensus node proxy can use the failed block to be verified as the block verification failure result. Ultimately, it can use either the block verification success result or the block verification failure result as the block verification result.

[0120] As mentioned above, since malicious nodes (i.e., malicious nodes) may deceive consensus node agents in the blockchain system, consensus node agents need to obtain the block QC (i.e., node signature set) where the real-time data is located, and perform QC verification (i.e., block verification) according to the members of the consensus node committee. Only data that passes QC verification will be pushed down.

[0121] Step S102: If the block verification result indicates that the verification is successful, the business data associated with the block to be verified is sent to the stream processing queue in the business stream processor in the form of a data stream. The business data stream in the stream processing queue is processed to obtain the churn processing result corresponding to the business data.

[0122] Specifically, when the block verification result indicates successful verification, the transaction data (also known as ledger data) of the block to be verified and the contract data associated with the transaction data can be read from the node memory of the consensus node where the block to be verified is located through the consensus node proxy in the business flow processor. The read transaction data and contract data can be used as business data associated with the block to be verified.

[0123] In some embodiments, a business node can obtain corresponding transaction data (e.g., transaction data X) based on the execution result of a target transaction when executing it. For example, when a patient visits a hospital in region A, a business node in region A can issue an electronic invoice for the virtual assets spent on the visit, and then generate corresponding transaction data based on the electronic invoice. It is understood that a business node can execute a target transaction by invoking a specified business contract. For example, a business node can initiate a contract invocation request to a consensus node to obtain a business contract for executing the target transaction. Based on this business contract, it can read the read dataset corresponding to the target transaction from its node memory, and then execute the target transaction based on the read dataset to obtain the transaction execution result. This result can then be written to the write dataset corresponding to the target transaction, and the obtained write dataset can be used as the corresponding contract data (e.g., contract data Y). Business nodes can send the target transaction, the transaction data obtained from executing the target transaction, and contract data to the consensus node. When the consensus node obtains a transaction list containing the target transaction from the relevant transaction pool, it can package the transaction list and all or part of the data related to the transaction list (e.g., transaction data, transaction execution results, read datasets, write datasets, etc.) into a block. This embodiment does not limit the content of the data packaged into the block. It is understood that the consensus node can store the final block (e.g., the block to be verified) and related data not packaged into the block in its own node memory.

[0124] Understandably, each consensus node's memory can include a local cache (also known as a block cache, with each block corresponding to one block cache) and local storage. The local cache has relatively fast read / write speeds, so consensus nodes can prioritize read / write operations in the local cache, thus improving the overall performance of the blockchain network. Local storage is used for persistent storage of data (e.g., blocks). Consensus nodes can initially write the data to be stored into the corresponding local cache. However, considering the limitations of the local cache (e.g., data loss due to power failure), subsequent asynchronous write operations can gradually write the relevant data to local storage (e.g., a local database) to ultimately ensure data reliability and persistence. Therefore, a consensus node proxy can read the transaction data of the block to be verified and the associated contract data from the consensus node's local cache. If reading from the local cache fails, it can further attempt to read the transaction data and associated contract data from the local storage. The consensus node proxy can then use the read transaction data and contract data as business data associated with the block to be verified.

[0125] Furthermore, the consensus node agent can send the received business data as a data stream (i.e., an infinite sequence of continuously arriving data) to the stream processing queue in the business stream processor for storage, and can use the business data stored in the stream processing queue as a business data stream. It can be understood that because the consensus node agent continuously records and obtains the latest state of the blockchain ledger height (i.e., the block storage state) and batches the latest transaction data and contract data, this embodiment provides a high-throughput, highly scalable message queue service through the stream processing queue to support efficient real-time data processing. The stream processing queue can be constructed from stream agent components, specifically Kafka (a high-throughput distributed publish-subscribe messaging system), or other forms of components; the form and number of stream agent components are not limited here.

[0126] Furthermore, the churn handling component and the associated transformation processing engine within the business flow processor can be used to process the business data stream, thereby obtaining the churn handling result corresponding to the business data. In other words, after storing the business data in the flow processing queue, subsequent churn handling can be triggered, meaning the message (business data stream) is consumed by the churn handling component. Both the churn handling component and the transformation processing engine can be functional modules within the business flow processor or stand-alone servers deployed within it; this application does not limit their form. It should be noted that churn handling / stream processing refers to dividing continuously flowing input data into independent units for processing. Stream processing provides low-latency processing and analysis of streaming data and can reduce resource waste.

[0127] In some embodiments, the stream processing component can be Spark Streaming, and the transformation processing engine can be Spark Engine. Spark Streaming is the original stream processing framework of Spark (an open-source, Hadoop MapReduce-like general-purpose parallel framework specifically designed for iterative computation with large datasets). It can perform stream processing using micro-batch processing, enabling rapid scaling of real-time data, high throughput, and high fault tolerance, making it suitable for fast processing of large amounts of data. Spark Streaming uses discrete streams as an abstract representation, called DStreams. It can be understood that DStreams are independent of each other, while the data within a DStream is continuous, consisting of a series of RDDs (Resilient Distributed Datasets). Therefore, any operation on a DStream will be transformed into an operation on the underlying RDDs (through operators, such as map). Based on this, the specific process for handling churn in business data streams can be as follows: First, the business data stream is pulled from the stream processing queue by a churn handling component (e.g., Spark Streaming) in the business stream processor. Then, the pulled business data stream can be split based on a splitting time interval to obtain at least two sub-business data streams (i.e., discrete streams DStream). The specific size of the splitting time interval can be set according to actual conditions; this embodiment does not limit this. For example, if the splitting time interval is set to 5 seconds, then a sub-business data stream can be obtained every 5 seconds. Further, the at least two sub-business data streams can be transmitted to a transformation processing engine (e.g., Spark Engine) associated with the churn handling component for data transformation processing to obtain the transformation processing result corresponding to each sub-business data stream. The obtained at least two transformation processing results can then be used as the churn handling result corresponding to the business data. This can be understood as using Spark Engine to perform data transformation processing on the RDDs in each DStream and returning the RDD operation results in batches. It is understood that compared to the original business data stream, the transformation processing result obtained after data transformation processing is more beneficial for subsequent business logic analysis.

[0128] In this embodiment, the churn handling component and the transformation processing engine can be used together to process and store real-time data through ETL (extract, transform, load) so that the scattered business data streams can be extracted to a temporary intermediate layer, cleaned, transformed, and integrated, and finally loaded into the business control component of the business flow processor to become data that is convenient for real-time business logic analysis.

[0129] For ease of understanding, please refer to the following: Figure 4 , Figure 4 This is a schematic diagram illustrating the deployment logic of a stream processing queue provided in an embodiment of this application. For example... Figure 4 As shown, a distributed stream processing queue with high scalability and high throughput can be built by deploying M stream proxy components. These components can include stream proxy components K1, K2, ..., KM, where M is a positive integer. Each stream proxy component can be a Kafka instance, thus forming a Kafka cluster where all nodes are peers. Figure 4 As shown, the Kafka-based stream processing queue can divide the participants into three categories: (1) Producer: responsible for producing messages and sending them to the message broker; (2) Message Broker: each Broker is a Kafka service instance, and multiple Brokers constitute a Kafka cluster. Messages published by the producer will be stored in the Broker, and consumers will pull messages from the Broker for consumption; (3) Consumer: responsible for consuming Topic messages in the Broker. Each Consumer instance belongs to a Consumer Group. In Kafka, messages can be classified, and each type of message is called a Topic. Consumers can perform different processing on different Topics. A Topic can be divided into multiple Partitions. Each Partition is an ordered queue, and each message in a Partition has an ordered offset. In the same Consumer Group, only one Consumer instance can consume messages from a certain Partition.

[0130] Based on this, in this embodiment, the consensus node proxy can act as a producer, responsible for pushing business data obtained from the consensus node to the stream proxy component. The stream proxy component can act as a message broker, responsible for storing the business data sent by the consensus node proxy, while the churn handling component can act as a consumer, responsible for pulling business data streams from the stream proxy component for churn handling. Figure 4As shown, the number of consensus node proxies can be one or more, and there is no limit to this. For example, multiple consensus node proxies can include consensus node proxies 41a, 41b, 41c, and 41d. Each consensus node proxies can establish a communication connection with a stream proxy component. For example, consensus node proxies 41a can establish a communication connection with stream proxy component K1, consensus node proxies 41b can establish a communication connection with stream proxy component K2, consensus node proxies 41c can establish a communication connection with stream proxy component K2, and consensus node proxies 41d can establish a communication connection with stream proxy component KM, so that different consensus node proxies can push the business data they have obtained to the corresponding stream proxy components in parallel. Similarly, the number of churn handling components can be one or more, without limitation. For example, multiple churn handling components may include churn handling component 42a, churn handling component 42b, churn handling component 42c, and churn handling component 42d. Each churn handling component can establish a communication connection with a streaming proxy component. For instance, churn handling component 42a can establish a communication connection with streaming proxy component K1, churn handling component 42b can establish a communication connection with streaming proxy component K2, churn handling component 42c can establish a communication connection with streaming proxy component K3, and churn handling component 42d can establish a communication connection with streaming proxy component KM. This allows different churn handling components to pull business data streams from their respective streaming proxy components in parallel for churn handling. The aforementioned communication connections can be TLS (Transport Layer Security) connections or communication connections using other communication protocols.

[0131] also, Figure 4 The distributed service component cluster 40 shown (e.g., ZooKeeper, a distributed, open-source distributed application coordination service) can provide consistency services for the stream processing queue. The distributed service component cluster 40 manages the Kafka cluster, such as: Broker list management, the relationship between Partition and Broker, the relationship between Partition and Consumer, Producer and Consumer load balancing, consumption progress offset recording, consumer registration, etc. Therefore, in order to achieve high availability, ZooKeeper itself must also be a cluster. Here, the number of ZooKeeper instances in the cluster is not limited.

[0132] like Figure 4As shown, each consensus node agent can access the stream processing queue in different ways. For example, consensus node agents 41a, 41b, and 41c can all be front ends, while consensus node agent 41d can be a node providing a certain service. Furthermore, the data pulled by different consumers can have different uses. For instance, churn handling component 42a can transmit the pulled business data stream to another distributed cluster (e.g., a Hadoop cluster) for distributed processing; churn handling component 42b can perform real-time observation and statistics on the pulled business data stream; churn handling component 42c can provide the pulled business data stream to other services; and churn handling component 42d can further load the pulled business data stream into a data warehouse.

[0133] It is understandable that adopting such a method is acceptable. Figure 4 The deployment method shown enables distributed processing of business data streams in the streaming queue, thereby effectively improving the efficiency of real-time business streaming analysis and real-time business feedback. For example, a streaming proxy component (such as Kafka) can handle a streaming queue, and each streaming proxy component can classify the business data it receives. For instance, in electronic invoice-related businesses, electronic invoices can be classified according to specified classification rules, such as by enterprise type (e.g., enterprise size, main business area), or by invoice type (including but not limited to VAT invoices, general invoices, transportation invoices, or other tax invoices), so that different types of electronic invoices can be processed differently in the future.

[0134] It should be noted that the consensus node proxy and churn handling components need to first register the corresponding public key in the on-chain business contract, and then apply for the corresponding public key certificate. During the generation and consumption of business data streams, communication connections (such as TLS connections) are required based on the public key certificate issued by the expected on-chain identity. This ensures that only the consensus node proxy and churn handling components specified on the chain can perform data push and pull operations. For details on the implementation process, please refer to the following sections. Figure 6 Steps S305-S312 in the corresponding embodiments.

[0135] Step S103: Perform business logic analysis on the churn handling results to obtain the logic analysis results corresponding to the business data, and provide business feedback to the consensus node based on the logic analysis results.

[0136] It is understood that a business flow processor can perform real-time business logic analysis on the transformation processing results output by the transformation processing engine. This business logic analysis process can be executed by the business control component within the business flow processor. This business control component (also known as a business control unit) can be a modular framework, and business participants (i.e., business objects) can add different processing logic by adding different processing engines. In this embodiment, the business control component can be a functional module within the business flow processor or a server deployed independently within the business flow processor; this embodiment does not limit the specific implementation.

[0137] The business control component can include a business processing engine associated with the target business logic. This engine can be pre-imported by the business object. The target business logic is a specific logical rule that the business object wants to execute. It's understood that the business control component can also include business processing engines associated with other business logics; the number of business processing engines in the business control component is not limited here. Furthermore, a business contract associated with the feedback business is deployed on the consensus node. This contract registers the private keys of the aforementioned business processing engines. It's understood that executing certain specific transaction businesses (e.g., transferring electronic invoices) requires calling the on-chain business contract. The feedback business refers to the business of real-time auditing and analysis of important transaction businesses and providing feedback to the on-chain business contract, based on the need for real-time risk control management of blockchain data. In the tax blockchain, feedback businesses can include, but are not limited to, risk assessment, business freezing, alarm issuance, invoicing control, and tax refund review.

[0138] Based on this, the business flow processor performs business logic analysis on the churn handling results to obtain the logic analysis results corresponding to the business data, and then provides business feedback to the consensus node based on these logic analysis results. The specific process can be as follows: The business flow processor can call the business processing engine to perform business logic analysis on the churn handling results based on the aforementioned target business logic, thereby obtaining the logic analysis results corresponding to the business data. For example, when the target business logic is related to tax refund review (i.e., a tax refund review rule), the corresponding business processing engine can perform real-time statistics on the received electronic invoices (e.g., tax details) based on the target business logic, thereby obtaining the tax amount B1 already paid by business object A in a certain year, and can determine the tax amount B2 payable by business object A in that year based on the tax refund application information of business object A, and obtain the tax difference between the tax amount B1 already paid and the tax amount B2 payable. If the tax difference is positive, it means that business object A can apply for a tax refund; if the tax difference is 0, it means that business object A neither needs a tax refund nor needs to pay additional tax; if the tax difference is negative, it means that business object A needs to pay additional tax. Furthermore, the business processing engine can generate business feedback messages based on the obtained logical analysis results. To prevent malicious tampering, the engine can also sign the feedback message using its private key, which is already registered in the business contract, thus obtaining engine signature information. Subsequently, the engine can return the engine signature information and the feedback message to the consensus node broker through the component interface of the business control component. Specifically, the engine can digitally sign the first digest information (e.g., digest information H1) of the feedback message using its private key to obtain engine signature information. The first digest information of the feedback message can be obtained by hashing the feedback message. Further, the consensus node broker can verify the engine signature information to obtain the verification result. If the verification result indicates successful verification, the broker can forward the feedback message to the consensus node. Conversely, if the verification result indicates failure, the broker can discard the feedback message or return a verification failure message to the engine so that the engine can initiate a new feedback message. When the consensus node agent receives the engine signature information and the business feedback message, it can obtain the engine public key corresponding to the engine private key, and verify the digital signature in the engine signature information based on the engine public key to obtain the first digest information (e.g., digest information H1) of the business feedback message. It can also perform a hash operation on the business feedback message using the same hash algorithm as the business processing engine to obtain the second digest information (e.g., digest information h1) of the business feedback message. Then, it can compare the first digest information obtained after signature verification with the second digest information obtained by hash operation to obtain the engine signature verification result.If the engine's signature verification result indicates that the first digest information and the second digest information are the same, then the engine signature information verification is successful; otherwise, if the engine's signature verification result indicates that the first digest information and the second digest information are different, then the engine signature information verification is unsuccessful.

[0139] It is understood that the consensus node proxy in this embodiment can also realize the function of reverse streaming feedback on the chain, that is, executing the feedback of the business control component. Specifically, when the engine verification result indicates successful verification, the consensus node proxy can forward the business feedback message to the consensus node in the core consensus network. The specific process can be as follows: if the engine verification result indicates successful verification, the consensus node proxy can perform transaction assembly processing on the business feedback message to obtain a feedback business transaction. Here, transaction assembly processing can be understood as encapsulating the business feedback operation carried in the business feedback message into a transaction form, so that the consensus node can more efficiently execute the business feedback operation indicated by the feedback business transaction. Furthermore, the consensus node proxy is configured with a proxy private key (also known as a business administrator private key). Therefore, the feedback business transaction can be signed based on this proxy private key to obtain proxy signature information. Specifically, the consensus node proxy can perform a hash operation on the feedback business transaction to obtain the digest information of the feedback business transaction, and then digitally sign the digest information of the feedback business transaction based on the proxy private key to obtain the proxy signature information. Furthermore, the consensus node proxy can forward the obtained proxy signature information and feedback business transactions to the consensus node, enabling the consensus node to reach a consensus on the proxy signature information and engine signature information. When both the proxy signature information and engine signature information pass consensus, the contract state of the business contract is modified based on the feedback business transactions. The specific implementation process can be found below. Figure 5 Step S203 in the corresponding embodiment.

[0140] As described above, the consensus node proxy can assemble and sign business feedback operations (such as risk assessment, business freezing, and alarm issuance) from the business control component, and send the resulting feedback business transactions back to the consensus node, thereby changing the contract state of the on-chain business contract in real time. It can be understood that the content of the on-chain business contract itself is not changed. The consensus node changing the contract state of the business contract can be understood as changing the state of the business object requesting the call to the business contract, or as changing the permission of a business object to call a method within the business contract (for example, through an instruction in the permission contract associated with the business contract). For example, suppose business object A previously called business contract E to perform a transaction (such as an asset transfer). Under normal circumstances, business object A is in a non-frozen state when calling business contract E and can transfer virtual assets normally. However, after the business flow processor performs a business feedback operation to the consensus node (for example, detecting an abnormality in business object A's account and reporting a business freeze for business object A), the consensus node can change the contract state of business contract E based on this business feedback operation, restricting business object A's permission to call business contract E again. Therefore, business object A will be in a frozen state when calling business contract E.

[0141] It is understood that the embodiments of this application support dynamic changes to the business processing engine. That is, business participants can import one or more business processing engines into the business control component at any time and can continuously change their business logic. At the same time, each business processing engine can call the basic interface (i.e., component interface) of the business control component to execute feedback behaviors based on the results of logical analysis, such as risk assessment, business freezing, and alarm issuance. In addition, the business control component can provide business feedback through trusted on-chain identities. It is understood that each business processing engine in the business control component needs to be configured with an identity key registered in the on-chain business contract (i.e., the engine private key of each business processing engine). When sending business freeze transactions, issuing alarms off-chain, or other business feedback, the business control component will send relevant business feedback messages to the consensus node agent. At this time, it is necessary to sign the message using the configured identity key. Both the consensus node agent and the consensus node will verify the identity signature (i.e., engine signature information). Only business feedback messages that meet the identity permissions can be fed back to the chain, thereby changing the contract state of the business contract.

[0142] For example, in a risk-based shutdown scenario, suppose there is a business processing engine that is a sensitive word filtering engine. This sensitive word filtering engine can be loaded and started in the business control component and continuously receive electronic invoices on the chain. The sensitive word filtering engine can perform sensitive word detection processing on the content of the received electronic invoices. If a sensitive word is detected in the content of an electronic invoice issued by a certain company C, the sensitive word filtering engine can sign the business feedback message D with the identity key X configured in the sensitive word filtering engine, and send a feedback to shut down company C. The business feedback message D is forwarded to the chain through the consensus node proxy. When the on-chain business contract verifies that the identity key X corresponds to the risk shutdown review and has the authority to provide feedback and execute shutdown, it can shut down company C in real time on the chain based on the feedback.

[0143] As described above, this application provides a real-time business flow feedback scheme for consensus nodes in a layered blockchain (e.g., a tax blockchain), enabling real-time business flow analysis and feedback within the core consensus network. The service architecture provided by this application, which processes and feeds back to the blockchain, facilitates real-time auditing and analysis of important business processes by participants in the blockchain business system, and allows for feedback operations to the on-chain business contracts. Since the entire real-time business flow analysis and feedback process, the off-chain flow processing queue, and the identity of the business processing engine are bound to permissions in the on-chain business contracts, consistency and reliability of on-chain and off-chain business processing permissions can be achieved, and seamless integration of real-time data flow-based business models with the blockchain can be realized. Furthermore, because the business data flow is processed before business logic analysis, and the results are processed and analyzed with low latency, the efficiency and accuracy of business logic analysis and feedback can be improved, thereby enhancing the performance of real-time business flow analysis and feedback.

[0144] Further, please see Figure 5 , Figure 5 This is a flowchart illustrating a data processing method based on a hierarchical blockchain provided in an embodiment of this application. Figure 5 As shown, this method can be executed by a consensus node in the core consensus network. This consensus node can be a server connected to the core consensus network, or it can be an object terminal connected to the core consensus network. The specific form of the consensus node is not limited here; it can be any of the aforementioned... Figure 1 Any consensus node in the core consensus network shown, for example, node 130a. The method may include at least the following steps S201-S203:

[0145] Step S201: When the consensus node obtains the data read request sent by the business flow processor based on the association relationship, according to the data read request, the block to be verified with the largest block height in the consensus node is returned to the business flow processor so that the business flow processor can perform block verification on the verification block and obtain the block verification result.

[0146] In this embodiment, the layered blockchain may include the blockchain in the core consensus network, where each business flow processor in the core consensus network is associated with any consensus node. It can be understood that a consensus node in the core consensus network can, based on its association with the business flow processor, obtain a data read request sent by the business flow processor. This data read request can then be broadcast to other consensus nodes for verification. When the data read request verification passes, the node can return the block storage status of all consensus nodes and the pending block with the highest block height in the core consensus network to the business flow processor based on the data read request. Each consensus node can verify the request signature information obtained by the consensus node proxy in the business flow processor signing the data read request, in order to verify the identity and authority of the consensus node proxy. When the verification is successful (for example, more than 2 / 3 of the consensus nodes determine that the request signature information has been successfully verified), the consensus node can return the block storage status of each consensus node and the corresponding unprocessed blocks to the consensus node proxy according to the data read request. This allows the consensus node proxy to perform block deterministic verification of the unprocessed blocks based on the aforementioned block storage status of the consensus nodes, and to determine the block to be verified when the block deterministic verification result is a successful deterministic verification result. The specific implementation process can be found in the above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0147] Subsequently, the consensus node proxy in the business flow processor can perform block verification on the verification block to obtain the block verification result. When the block verification result indicates successful verification, the business flow processor sends the business data associated with the block to be verified as a data stream to the flow processing queue in the business flow processor, and performs churn processing on the business data stream in the flow processing queue to obtain the churn processing result corresponding to the business data. The business flow processor can then perform business logic analysis on the churn processing result to obtain the logic analysis result corresponding to the business data. This logic analysis result can be used to instruct the business flow processor to provide business feedback to the consensus node. The specific implementation process can be found above. Figure 3 Steps S101-S103 in the corresponding embodiments will not be described again here.

[0148] Step S202: Obtain the feedback business transaction returned by the business flow processor;

[0149] It is understandable that after the business control component in the business flow processor generates a business feedback message based on the logical analysis results, it can sign the business feedback message to obtain engine signature information. Then, the engine signature information and the business feedback message can be returned to the consensus node proxy. Upon successful verification of the engine signature information, the consensus node proxy performs transaction assembly processing and signing on the business feedback message. Subsequently, the obtained proxy signature information and feedback business transaction are forwarded to the consensus node. The specific implementation process of this step can be found above. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0150] Step S203: Verify the feedback business transaction. When the feedback business transaction is successfully verified, change the contract status of the business contract associated with the feedback business deployed on the consensus node based on the feedback business transaction.

[0151] Specifically, when a consensus node receives a feedback business transaction from the business flow processor, it can also obtain the proxy signature information and engine signature information associated with that feedback business transaction. The feedback business transaction is obtained by the consensus node proxy in the business flow processor assembling the business feedback message; the proxy signature information is obtained by the consensus node proxy signing the feedback business transaction based on the proxy's private key. The business feedback message is a message generated by the business processing engine contained in the business control component of the business flow processor based on logical analysis results; the engine signature information is obtained by the business processing engine signing the business feedback message based on its private key. The specific implementation process can be found above. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0152] Furthermore, the consensus node that obtains the proxy signature information and engine signature information can broadcast these two signature information to other consensus nodes. All consensus nodes need to participate in the consensus on the proxy signature information and engine signature information to verify the identity and permissions of the feedback business transaction. The specific process can be as follows: First, consensus can be reached on the proxy signature information to obtain the first consensus result. Here, the proxy signature information is obtained by the consensus node proxy digitally signing the third digest information (e.g., digest information H2) of the feedback business transaction based on the proxy private key. The third digest information of the feedback business transaction is obtained by the consensus node proxy performing a hash operation on the feedback business transaction. Based on this, each consensus node can perform proxy signature verification on the obtained proxy signature information. For ease of understanding, assume that there are N consensus nodes. Take consensus node i among the N consensus nodes as an example. Consensus node i can be any one of the N consensus nodes, and i is a positive integer less than or equal to N. When consensus node i obtains the proxy signature information, it can acquire the proxy public key of the consensus node proxy and verify the digital signature in the proxy signature information based on this proxy public key to obtain the third digest information of the feedback business transaction (e.g., digest information H2). It can also perform a hash operation on the feedback business transaction using the same hash algorithm as the consensus node proxy to obtain the fourth digest information of the feedback business transaction (e.g., digest information h2). Then, it can compare the third digest information obtained after verification with the fourth digest information obtained after hashing to obtain the proxy verification result i. It can be understood that if the proxy verification result i indicates that the third digest information and the fourth digest information are the same, then consensus node i has successfully verified the signature; conversely, if the proxy verification result i indicates that the third digest information and the fourth digest information are different, then consensus node i has failed to verify the signature.

[0153] It is understood that when N consensus nodes verify the proxy signature information, N proxy signature verification results can be obtained. In this embodiment, the N proxy signature verification results can be used as the first consensus result. Optionally, if the first consensus result indicates that the number of proxy signature verification results indicating successful verification among the N proxy signature verification results is greater than the result number threshold, it can be determined that the proxy signature information consensus has passed, indicating that the above-mentioned feedback business transaction was verified and forwarded by the consensus nodes. Optionally, if the first consensus result indicates that the number of proxy signature verification results indicating successful verification among the N proxy signature verification results is less than or equal to the result number threshold, it can be determined that the proxy signature information consensus has not passed.

[0154] Furthermore, when the first consensus result indicates that the proxy signature information consensus has passed, the consensus nodes can reach a consensus on the engine signature information to obtain the second consensus result. This engine signature information is obtained by the business processing engine digitally signing the fifth digest information (e.g., digest information H3) of the business feedback message based on its private key. The fifth digest information of the business feedback message is obtained by the business processing engine through a hash operation on the business feedback message. Based on this, each consensus node can verify the engine signature information it has obtained. For ease of understanding, we will still use consensus node i as an example. The specific process is as follows: When consensus node i obtains the engine signature information, it can obtain the engine public key of the business processing engine and verify the digital signature in the engine signature information based on this engine public key to obtain the fifth digest information (e.g., digest information H3) of the business feedback message. It can also perform a hash operation on the business feedback message using the same hash algorithm as the business processing engine to obtain the sixth digest information (e.g., digest information h3) of the business feedback message. Finally, it can compare the fifth digest information obtained after verification with the sixth digest information obtained through hashing to obtain the engine signature verification result i. It is understandable that if the engine signature verification result i indicates that the fifth digest information is the same as the sixth digest information, then the consensus node i can be determined to have successfully verified the signature; conversely, if the engine signature verification result i indicates that the fifth digest information is different from the sixth digest information, then the consensus node i can be determined to have failed to verify the signature.

[0155] It is understood that when N consensus nodes verify the engine signature information, N engine signature verification results can be obtained. In this embodiment, the N engine signature verification results can be used as the second consensus result. Optionally, if the second consensus result indicates that the number of engine signature verification results indicating successful verification among the N engine signature verification results is greater than the result number threshold, it can be determined that the engine signature information consensus has passed, indicating that the above-mentioned business feedback message was issued by the business processing engine, and that the content is true and valid, conforming to the identity and permissions specified by the business processing engine in the on-chain business contract; Optionally, if the second consensus result indicates that the number of engine signature verification results indicating successful verification among the N engine signature verification results is less than or equal to the result number threshold, it can be determined that the engine signature information consensus has not passed.

[0156] The result quantity threshold can be set according to actual needs, and there is no limit here. For example, when N = 3F + 1, the result quantity threshold can be set to (2F + 1).

[0157] It is understandable that when the second consensus result indicates that the engine signature information consensus has passed, the consensus node can determine that the feedback business transaction has been successfully verified. Therefore, it can modify the contract state of the business contract deployed on the consensus node that is associated with the feedback business based on this feedback business transaction. For a description of the contract state of the business contract, please refer to the above. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0158] It should be noted that for the same consensus node, it can only determine that its verification of the feedback business transaction is successful when both the corresponding proxy signature verification result and the engine signature verification result indicate that the verification is successful. In other words, among N consensus nodes, there must be overlap between the consensus nodes that successfully verify the proxy signature information and the consensus nodes that successfully verify the engine signature information, and the number of overlapping consensus nodes must be greater than the above-mentioned result threshold before the feedback business transaction can be considered to have been successfully verified.

[0159] Therefore, in the core consensus network, the embodiments of this application achieve seamless integration between the business model based on real-time data stream and the blockchain by performing real-time business logic analysis on business data off-chain and providing real-time business feedback to the business contracts on-chain. At the same time, it can effectively improve the performance of real-time business streaming analysis and real-time business feedback while ensuring the consistency and reliability of on-chain and off-chain data.

[0160] Further, please see Figure 6 , Figure 6 This is a schematic diagram of the interaction flow of a data processing method based on a hierarchical blockchain provided in an embodiment of this application. For example... Figure 6 As shown, this method can be jointly executed by the service flow processor and consensus nodes in the core consensus network, wherein the service flow processor can be the aforementioned Figure 1 The core consensus network shown includes a service flow processor 130, which can be one of the aforementioned consensus nodes. Figure 1 This refers to any consensus node in the core consensus network shown, for example, node 130a. The method may include at least the following steps:

[0161] Step S301: Based on the association relationship with the consensus node, the service flow processor sends a data read request to the consensus node through the consensus node proxy;

[0162] The specific implementation process for this step can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0163] Step S302: Based on the data read request, the consensus node returns the block storage status of the consensus node and the unprocessed block with the highest block height in the core consensus network to the consensus node proxy in the business flow processor.

[0164] The specific implementation process for this step can be found above. Figure 3 The corresponding embodiment of step S101, or, as described above, can be referred to. Figure 5 Step S201 in the corresponding embodiment will not be described again here.

[0165] In step S303, the consensus node proxy in the business flow processor performs block deterministic verification on the block to be processed based on the block storage status of the consensus node, obtains the block deterministic verification result, and when the block deterministic verification result is a deterministic success verification result, the block to be processed is taken as the block to be verified.

[0166] The specific implementation process for this step can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0167] Step S304: The consensus node in the service flow processor performs block verification on the block to be verified and obtains the block verification result.

[0168] The specific implementation process for this step can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0169] Step S305: The consensus node agent in the business flow processor sends a data push request and the first signature information to the consensus node;

[0170] It is understood that the stream processing queue in the business flow processor is built based on the stream proxy component. A business contract associated with the feedback business is deployed on the consensus node, and this business contract registers the proxy public key of the consensus node proxy included in the business flow processor. Therefore, the consensus node proxy can apply for a corresponding public key certificate. For ease of distinction, this public key certificate can be referred to as the first public key certificate. The public key certificate in this application embodiment can refer to a Public Key Infrastructure (PKI). In a certificate system, a certificate is proof of identity for a public key owner, issued by an authoritative authority (CA). Asymmetric encryption and digital signatures for information can be implemented based on a public key certificate system. This public key certificate system can include public-private key cryptography, x509 certificates, CA certificate issuance centers, etc.

[0171] When the consensus node proxy obtains the first public key certificate containing the proxy public key, it can generate a data push request and sign the data push request based on the proxy private key corresponding to the proxy public key, thereby obtaining the first signature information. Specifically, the consensus node proxy can perform a hash operation on the data push request to obtain its digest information (which can be called the seventh digest information, for example, digest information H4), and then digitally sign this digest information to obtain the first signature information. Subsequently, the consensus node proxy can send the data push request and the first signature information to the consensus node.

[0172] Step S306: After successfully verifying the first signature information, the consensus node performs certificate verification on the first public key certificate based on the data push request, obtains the first certificate verification result, and returns the first certificate verification result to the business flow processor.

[0173] Specifically, after receiving a data push request and the first signature information, a consensus node can broadcast the data push request and the first signature information to other consensus nodes. Subsequently, each consensus node can verify the first signature information. Here, we take consensus node i (where i is a positive integer less than or equal to N) out of N consensus nodes as an example: Consensus node i can obtain the proxy public key and verify the digital signature in the first signature information based on the proxy public key to obtain the digest information of the data push request (i.e., the seventh digest information, for example, digest information H4). It can also use the same hash algorithm as the consensus node proxy to perform a hash operation on the data push request to obtain the digest information of the data push request (which can be called the eighth digest information, for example, digest information h4). Then, it can compare the seventh digest information obtained after verification with the eighth digest information obtained by hash operation to obtain the first verification result i. It is understandable that if the first signature verification result i indicates that the seventh digest information is the same as the eighth digest information, then the consensus node i can be determined to have successfully verified the signature; conversely, if the first signature verification result i indicates that the seventh digest information is different from the eighth digest information, then the consensus node i can be determined to have failed to verify the signature.

[0174] It is understandable that after N consensus nodes verify the first signature information, N first verification results can be obtained. Optionally, if the number of first verification results indicating successful verification among these N first verification results is greater than a first threshold, it indicates that the consensus node has successfully verified the first signature information; conversely, if the number of first verification results indicating successful verification among these N first verification results is less than or equal to the first threshold, it indicates that the consensus node has failed to verify the first signature information. The first threshold can be set according to actual needs and is not limited here. For example, when N = 3F + 1, the first threshold can be set to (2F + 1).

[0175] Furthermore, after a consensus node successfully verifies the first signature information, it can perform certificate verification on the first public key certificate based on the data push request, obtaining the first certificate verification result. Each consensus node can compare the first public key certificate currently used by its proxy with the first public key certificate pre-submitted to the chain by its proxy. This includes comparing the proxy public key in the first public key certificate, comparing the certificate content, verifying the validity of the first public key certificate, verifying the certificate version, and so on.

[0176] Subsequently, the first certificate verification result can be returned to the business flow processor. Specifically, if the first certificate verification result indicates that the number of successfully verified consensus nodes out of the N consensus nodes is greater than a first threshold, it means that the consensus node has successfully verified the first public key certificate; otherwise, it means that the consensus node has failed to verify the first public key certificate. It can be understood that the process of verifying the first public key certificate is the process of authenticating the consensus node proxy. Only consensus node proxies with legitimate certificates are trustworthy, ensuring that the subsequent established first communication connection is secure and reliable.

[0177] Step S307: If the first certificate verification result indicates successful verification, the business flow processor establishes a first communication connection between the consensus node proxy and the flow proxy component.

[0178] It is understandable that if the first certificate verification result indicates successful verification, it can be determined that the consensus node agent has the data push permission. Therefore, a first communication connection (e.g., a TLS connection) can be established between the consensus node agent and the stream agent component. This first communication connection can be used to transmit the business data obtained by the consensus node agent to the stream agent component.

[0179] Step S308: The churn handling component in the service flow processor sends a data retrieval request and second signature information to the consensus node;

[0180] Similar to the process in step S305 above, the business contract registers the component public key of the churn handling component included in the business flow processor. Therefore, the churn handling component can apply for the corresponding public key certificate, which can be referred to as the second public key certificate for easy distinction. When the churn handling component obtains the second public key certificate containing the component public key, it can generate a data pull request and sign the data pull request based on the component private key corresponding to the component public key, thereby obtaining the second signature information. Specifically, the churn handling component can perform a hash operation on the data pull request to obtain the digest information of the data pull request (which can be called the ninth digest information, for example, digest information H5), and then digitally sign the digest information of the data pull request to obtain the second signature information. Subsequently, the churn handling component can send the data pull request and the second signature information to the consensus node.

[0181] Step S309: After successfully verifying the second signature information, the consensus node performs certificate verification on the second public key certificate based on the data pull request, obtains the second certificate verification result, and returns the second certificate verification result to the business flow processor.

[0182] Similar to the process in step S306 above, after receiving a data pull request and the second signature information, a consensus node can broadcast the data pull request and the second signature information to other consensus nodes. Each consensus node can then verify the second signature information. Taking consensus node i as an example: Consensus node i can obtain the component's public key and verify the digital signature in the second signature information based on that public key, obtaining the digest information of the data pull request (i.e., the ninth digest information, for example, digest information H5). It can also perform a hash operation on the data pull request using the same hash algorithm as the churn handling component, obtaining the digest information of the data pull request (which can be called the tenth digest information, for example, digest information h5). Then, it can compare the ninth digest information obtained after verification with the tenth digest information obtained through hashing to obtain the second verification result i. It can be understood that if the second verification result i indicates that the ninth digest information and the tenth digest information are the same, then consensus node i has successfully verified the signature; conversely, if the second verification result i indicates that the ninth digest information and the tenth digest information are different, then consensus node i has failed to verify the signature.

[0183] It is understandable that after N consensus nodes verify the second signature information, N second verification results can be obtained. Optionally, if the number of second verification results indicating successful verification among these N second verification results is greater than a second threshold, it indicates that the consensus node has successfully verified the second signature information; conversely, if the number of second verification results indicating successful verification among these N second verification results is less than or equal to the second threshold, it indicates that the consensus node has failed to verify the second signature information. The second threshold can be set according to actual needs and is not limited here. For example, when N = 3F + 1, the second threshold can be set to (2F + 1).

[0184] Furthermore, after the consensus node successfully verifies the second signature information, it can perform certificate verification on the second public key certificate based on the data pull request to obtain the second certificate verification result. Each consensus node can compare the second public key certificate currently used by the churn handling component with the second public key certificate pre-submitted to the chain by the churn handling component. This includes comparing whether the component public key in the second public key certificate matches, comparing whether the certificate content matches, and also verifying the validity of the second public key certificate, verifying the certificate version, etc.

[0185] Subsequently, the second certificate verification result can be returned to the business flow processor. Specifically, if the second certificate verification result indicates that the number of successfully verified consensus nodes out of the N consensus nodes is greater than a second threshold, it means the consensus node has successfully verified the second public key certificate; otherwise, it means the consensus node has failed to verify the second public key certificate. It can be understood that the process of verifying the second public key certificate is the process of authenticating the churn handling component. Only churn handling components with legitimate certificates are trustworthy, ensuring the security and reliability of the subsequently established second communication connection.

[0186] Step S310: If the second certificate verification result indicates successful verification, the service flow processor establishes a second communication connection between the churn handling component and the flow proxy component.

[0187] It is understandable that if the second certificate verification result indicates successful verification, it can be determined that the churn handling component has data retrieval permissions. Therefore, a second communication connection (e.g., a TLS connection) can be established between the churn handling component and the streaming proxy component. This second communication connection can be used to transmit the business data stream stored in the streaming proxy component to the churn handling component.

[0188] Step S311: If the block verification result indicates that the verification is successful, the consensus node agent in the service flow processor sends the service data associated with the block to be verified to the flow processing queue in the service flow processor in the form of a data stream through the first communication connection.

[0189] The specific implementation process for this step can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0190] In step S312, the churn handling component in the business flow processor pulls the business data stream from the flow processing queue through the second communication connection, performs churn handling on the business data stream through the churn handling component and the conversion processing engine, and obtains the churn handling result corresponding to the business data.

[0191] The specific implementation process for this step can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0192] Step S313: The business flow processor performs business logic analysis on the churn processing results through the business processing engine, obtains the logic analysis results corresponding to the business data, generates feedback business transactions based on the logic analysis results, and sends the feedback business transactions to the consensus node.

[0193] The specific implementation process for this step can be found above. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0194] Step S314: The consensus node verifies the feedback business transaction.

[0195] The specific implementation process for this step can be found above. Figure 5 Step S203 in the corresponding embodiment will not be described again here.

[0196] Step S315: When the feedback business transaction is successfully verified, the consensus node changes the contract state of the business contract associated with the feedback business deployed on the consensus node based on the feedback business transaction.

[0197] The specific implementation process for this step can be found above. Figure 5 Step S203 in the corresponding embodiment will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again.

[0198] For better understanding, please refer to [link / reference]. Figure 7 , Figure 7 This is a system architecture diagram of real-time business flow feedback in a tax blockchain provided in this application embodiment. This tax blockchain is a layered blockchain, including isolated business networks and a core consensus network, such as... Figure 7As shown, the business network can include multiple business nodes. The number of business nodes is not limited here; for example, it can include business nodes 701a, 701b, 701c, 701d, and 701e. In the tax blockchain, each business node has its own level and function. For example, business nodes 701a, 701b, and 701c can all be lightweight tax business nodes (also called tax business SPV nodes) below the provincial level (such as city / county / township level), which can be used to execute certain specific tax businesses. For example, business node 701a can calculate the tax amount payable by all enterprises in its region for the current year. Business nodes 701d and 701e can be provincial-level lightweight nodes (also called provincial-level SPV nodes), with higher permissions than lightweight nodes below the provincial level, and can manage business nodes 701a, 701b, and 701c. The core consensus network can include multiple consensus nodes. There is no limit to the number of consensus nodes. For example, it can include consensus node 702a, consensus node 702b, consensus node 702c, ..., consensus node 702n. These consensus nodes can verify the transactions submitted by business nodes and package them onto the chain after verification. For example, after a business entity pays a specified amount of tax, the relevant business node can issue an electronic invoice for the business entity and upload the electronic invoice to the consensus node for processing.

[0199] In addition, the core consensus network may also include service flow processors, such as Figure 7As shown, the business flow processor is associated with each consensus node in the core consensus network. The business flow processor can include the following components: consensus node proxy 703, flow processing queue 704, churn handling component 705, conversion processing engine 706 associated with churn handling component 705, and business control component 707. The consensus node proxy 703 provides load balancing for the business flow processor's data reading, allowing it to read real-time data evenly from multiple consensus nodes. The consensus node proxy 703 primarily implements three core logics: block determinism determination (i.e., performing block determinism verification on blocks to be processed), data QC verification (i.e., performing block verification on blocks to be verified), and reverse streaming feedback on-chain (i.e., assembling and signing business feedback operations in business control component 707, and forwarding the resulting feedback business transactions to consensus nodes). The consensus node proxy 703 can batch-obtain the latest transaction data and contract data from consensus nodes and store them in the flow processing queue 704. The flow processing queue 704 can be obtained by deploying a Kafka cluster to achieve distributed processing of real-time data. After triggering churn handling, the churn handling component 705 can actively pull business data streams from the stream processing queue 704 and perform stream processing using micro-batch processing. Specifically, the churn handling component 705 can be Spark Streaming, which can split the pulled business data streams based on a preset splitting time interval to obtain at least two sub-business data streams. The transformation processing engine 706 can specifically be Spark Engine, which can perform data transformation processing on the sub-business data streams obtained by the churn handling component 705 to finally obtain the churn handling result. One or more business processing engines can be added to the business control component 707. The number of business processing engines is not limited here; for example, it can include business processing engine 707a, business processing engine 707b, ..., business processing engine 707m. Each business processing engine can correspond to a set of business logic / logic rules. For example, business processing engine 707a can introduce business logic related to invoicing control into the business control component 707, and business processing engine 707b can introduce business logic related to tax refund review into the business control component 707. The business control component 707 can invoke the corresponding business processing engine to perform real-time business logic analysis on the churn processing results output by the conversion processing engine 706. It can also provide business feedback to the consensus node based on its trusted on-chain identity, such as risk assessment, business freezing, and alarm issuance. The specific tasks performed by each functional module in the business flow processor can be found above. Figure 3 The corresponding implementation examples will not be described in detail here.

[0200] It is understandable that, based on the real-time risk control management of tax blockchain data, this application embodiment adds a Spark-based real-time business flow processing system (i.e., business flow processor) to the core consensus network. By processing transaction data and contract data in real time, tax managers (such as local tax bureaus) can add the corresponding business processing engine to the business control component of the real-time flow processing and introduce the required business logic to complete the real-time risk control processing.

[0201] For better understanding, please refer to [link / reference]. Figure 8 , Figure 8 This is a system architecture diagram for a blockchain electronic invoice scenario provided in an embodiment of this application. For example... Figure 8 As shown in the embodiments of this application, the business layer, the routing proxy layer, and the core consensus network layer constitute the entire complete blockchain business system. Figure 8 The core chain 1, core chain 2, ... and core chain N shown are target blockchains maintained by tax authorities in different regions. For example, the business data (e.g., business data G) in this embodiment may include transaction data and contract data generated when performing electronic invoice transfer business.

[0202] It is understandable that when blockchain is used in some scenarios of government agencies (e.g., tax systems) or commercial organizations, in order to improve the confidentiality and security of data, the layered blockchain structure of "business network - core consensus network" in the embodiments of this application can be adopted.

[0203] The business layer resides within the witness network (i.e., the business network). Business nodes in this layer can include terminal devices corresponding to the e-tax bureau, terminal devices corresponding to enterprise users, and terminal devices corresponding to consumer users. The e-tax bureau can refer to the local tax bureau within the tax bureau's dedicated network. Enterprise users can be invoicing service providers, reimbursement service providers, or retail enterprises (e.g., KA enterprises, i.e., large retail clients and key retail clients) in the public cloud. Consumer users can be payment service providers, circulation service providers, or retail enterprises in the private cloud. The business nodes in this business network primarily execute transaction operations and do not participate in ledger consensus. It is understood that when executing electronic invoice transfer transactions, business nodes can generate transaction data and contract data for transmission to relay nodes.

[0204] In this routing proxy layer, N relay nodes (i.e., routing nodes) can be used to isolate the business layer and the core consensus network layer. Each relay node can provide peer-to-peer (P2P) service, routing service, certificate caching, and authentication service. Peer-to-peer service refers to a service in a P2P network based on a specific network protocol. In a P2P network, network nodes do not require a central node to maintain the network state; instead, each node maintains the overall network state or the connection state of its neighbors through broadcast interactions with them. Routing service is a basic function of nodes and can be used for communication between nodes. Certificates associated with the certificate cache can refer to Public Key Certificate Systems (PKI). In a PKI, a certificate is proof of identity for the owner of a public key, issued by an authoritative authority (CA). Authentication service can be used to verify the data format of received data, node legitimacy, etc. In this embodiment, relay nodes can forward transaction data and contract data generated by business nodes to the consensus node.

[0205] In this core consensus network layer, the consensus nodes (i.e., accounting nodes) can be trusted nodes within the tax-specific network. Each consensus node has the ability to package blocks, meaning it can package transaction data sent by relay nodes into blocks, store contract data sent by relay nodes, or package both transaction and contract data sent by relay nodes into blocks to successfully write them into the target blockchain within the core consensus network layer. Furthermore, a business flow processor can be added to the core consensus network layer. This business flow processor is associated with the consensus nodes. When the business flow processor obtains a block with the highest block height from the consensus node based on this association, it can perform block verification. If the verification is successful, the business flow processor can send the business data associated with the block to its stream processing queue as a data stream to handle the flow of business data in the queue, thus obtaining the corresponding flow processing result. The business flow processor can also perform business logic analysis on the flow processing result and provide business feedback to the consensus node based on the obtained logic analysis results. Correspondingly, consensus nodes can return the block with the highest block height to be verified to the business flow processor based on the data read request sent by the business flow processor. They can also verify the feedback business transactions returned by the business flow processor. When the feedback business transaction is successfully verified, the contract state of the business contract deployed on the consensus node related to the feedback business can be changed based on the feedback business transaction. Therefore, in the core consensus network, the business flow processor can instantly obtain real-time data streams (i.e., business data streams) from the blockchain for rapid business logic analysis and corresponding business feedback, while ensuring the consistency and reliability of on-chain and off-chain data. This enables seamless integration of real-time data stream-based business models with the blockchain, while improving the performance of real-time business streaming analysis and real-time business feedback.

[0206] Please see Figure 9 This is a schematic diagram of the structure of a data processing device based on a hierarchical blockchain provided in an embodiment of this application. The data processing device 1 based on a hierarchical blockchain can be a computer program (including program code) running on a computer device; for example, the data processing device 1 based on a hierarchical blockchain can be an application software. This device can be used to execute corresponding steps in the data processing method based on a hierarchical blockchain provided in the embodiment of this application. In this embodiment, the device can run in a business flow processor, which can be the aforementioned... Figure 2 In the corresponding embodiment, the service flow processor 20B, the layered blockchain may include the blockchain in the core consensus network, where the consensus nodes are associated with the service flow processor. For example... Figure 9As shown, the data processing device 1 based on the hierarchical blockchain may include: a block verification module 101, a loss handling module 102, a business feedback module 103, a data request module 104, a block determination module 105, a first signature module 106, a first sending module 107, a first communication module 108, a second signature module 109, a second sending module 110, and a second communication module 111.

[0207] The block verification module 101 is used to perform block verification on the block to be verified when the business flow processor obtains the block to be verified with the maximum block height from the consensus node based on the association relationship, and obtain the block verification result.

[0208] The block verification module 101 may include: a node signature verification unit 1011, a root verification unit 1012, a transaction verification unit 1013, a verification success unit 1014, and a verification result determination unit 1015.

[0209] The node signature verification unit 1011 is used to obtain the node signature set associated with the block to be verified and the node public keys corresponding to N consensus nodes through the consensus node proxy, and to perform node signature verification on the node signature set based on the obtained N node public keys to obtain the node signature verification result; the node signature set includes the node signature information obtained by each of the N consensus nodes signing the block to be verified.

[0210] The root verification unit 1012 is used to perform root verification on the Merkel root in the block to be verified if the node verification result indicates that the verification is successful, and obtain the root verification result.

[0211] The transaction verification unit 1013 is used to perform transaction verification on the transaction data associated with the Merkel root in the block to be verified if the root verification result indicates that the root verification is successful, and obtain the transaction verification result.

[0212] The verification success unit 1014 is used to determine that the block to be verified is successful if the transaction verification result indicates that the transaction verification is successful, and to take the block to be verified as the block verification success result.

[0213] The verification result determination unit 1015 is used to determine the block verification result based on the node signature verification result, the root verification result, the transaction verification result, and the block verification success result.

[0214] Specifically, the verification result determination unit 1015 is used to determine that the block to be verified has failed if the node verification result indicates that the verification has failed, or the root verification result indicates that the root verification has failed, or the transaction verification result indicates that the transaction verification has failed. The block to be verified that has failed is taken as the block verification failure result; and the block verification success result or the block verification failure result is taken as the block verification result.

[0215] The specific functional implementation methods of the node signature verification unit 1011, the root verification unit 1012, the transaction verification unit 1013, the verification success unit 1014, and the verification result determination unit 1015 can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0216] The churn handling module 102 is used to send the business data associated with the block to be verified to the stream processing queue in the business stream processor in the form of a data stream if the block verification result indicates that the verification is successful, and to perform churn handling on the business data stream in the stream processing queue to obtain the churn handling result corresponding to the business data.

[0217] The churn handling module may include: a business data acquisition unit 1021, a data stream storage unit 1022, and a churn handling unit 1023;

[0218] The business data acquisition unit 1021 is used to read the transaction data of the block to be verified and the contract data associated with the transaction data from the node memory of the consensus node where the block to be verified is located through the consensus node proxy in the business flow processor, and use the read transaction data and contract data as business data associated with the block to be verified.

[0219] The data stream storage unit 1022 is used to send business data to the stream processing queue in the business stream processor in the form of a data stream for storage, and to use the business data stored in the stream processing queue as a business data stream.

[0220] The churn handling unit 1023 is used to perform churn handling on the business data stream through the churn handling component in the business flow processor and the transformation processing engine associated with the churn handling component, and to obtain the churn handling result corresponding to the business data.

[0221] The loss processing unit 1023 may include: a data stream cutting subunit 10231 and a data conversion subunit 10232;

[0222] The data stream splitting sub-unit 10231 is used to pull business data streams from the stream processing queue through the churn handling component in the business stream processor, and split the pulled business data streams based on the splitting time interval to obtain at least two sub-business data streams;

[0223] The data conversion subunit 10232 is used to transmit at least two sub-business data streams to the conversion processing engine associated with the churn handling component for data conversion processing, obtain the conversion processing result corresponding to each sub-business data stream, and use the obtained at least two conversion processing results as the churn handling result corresponding to the business data.

[0224] The specific functional implementation methods of the data stream cutting subunit 10231 and the data conversion subunit 10232 can be found in the above description. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0225] The specific functional implementation methods of the business data acquisition unit 1021, data stream storage unit 1022, and flow processing unit 1023 can be found above. Figure 3 Step S102 in the corresponding embodiment will not be described again here.

[0226] The business feedback module 103 is used to perform business logic analysis on the churn handling results, obtain the logic analysis results corresponding to the business data, and provide business feedback to the consensus node based on the logic analysis results.

[0227] In one implementation, the business flow processor further includes a consensus node proxy and a business control component. The business control component contains a business processing engine associated with the target business logic. A business contract associated with the feedback business is deployed on the consensus node. The business contract registers the engine private key of the business processing engine.

[0228] The business feedback module 103 may include: a logic analysis unit 1031, a feedback signature unit 1032, an engine signature verification unit 1033, and a message forwarding unit 1034;

[0229] The logic analysis unit 1031 is used to call the business processing engine to perform business logic analysis on the churn processing results based on the target business logic, and obtain the logic analysis results corresponding to the business data.

[0230] Feedback signature unit 1032 is used to generate business feedback messages based on logical analysis results, sign the business feedback messages based on the engine private key to obtain engine signature information, and return the engine signature information and business feedback messages to the consensus node proxy through the component interface of the business control component.

[0231] The engine signature verification unit 1033 is used to verify the engine signature information through the consensus node proxy and obtain the engine signature verification result.

[0232] The message forwarding unit 1034 is used to forward the business feedback message to the consensus node if the engine signature verification result indicates that the signature verification is successful.

[0233] The message forwarding unit 1034 may include: a signature assembly subunit 10341 and a transaction forwarding subunit 10342;

[0234] The assembly signature subunit 10341 is used to perform transaction assembly processing on the business feedback message if the engine verification result indicates that the verification is successful, to obtain the feedback business transaction, and to sign the feedback business transaction based on the proxy private key of the consensus node proxy to obtain the proxy signature information.

[0235] The transaction forwarding subunit 10342 is used to forward the proxy signature information and feedback business transaction to the consensus node, so that the consensus node can reach a consensus on the proxy signature information and engine signature information. When the proxy signature information and engine signature information are both agreed upon, the contract state of the business contract is changed based on the feedback business transaction.

[0236] The specific functional implementation methods of the assembly signature subunit 10341 and the transaction forwarding subunit 10342 can be found in the above description. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0237] The specific functional implementation methods of the logic analysis unit 1031, feedback signature unit 1032, engine signature verification unit 1033, and message forwarding unit 1034 can be found in the above description. Figure 3 Step S103 in the corresponding embodiment will not be described again here.

[0238] In one implementation, the above-mentioned service flow processor includes a consensus node proxy, and the association includes the data interaction relationship between the consensus node proxy and the consensus node;

[0239] The data request module 104 is used to send a data read request to the consensus node through the consensus node proxy based on the data interaction relationship, so that the consensus node can return the block storage status of the consensus node and the unprocessed block with the maximum block height in the core consensus network according to the data read request.

[0240] The block determination module 105 is used to perform block deterministic verification on the block to be processed based on the block storage state of the consensus node, and obtain the block deterministic verification result; when the block deterministic verification result is a deterministic success verification result, the block to be processed with the first block state indicated by the deterministic success verification result is taken as the block to be verified.

[0241] In one implementation, the number of consensus nodes is N, where N is a positive integer; one consensus node corresponds to one block storage state; the block determination module 105 may include: a node determination unit 1051, a first verification unit 1052, a second verification unit 1053, and a verification result determination unit 1054.

[0242] The node determination unit 1051 is used to determine the consensus node that has stored unprocessed blocks among the N consensus nodes as the target consensus node based on the block storage status of the N consensus nodes respectively; the number of target consensus nodes is less than or equal to N.

[0243] The first verification unit 1052 is used to determine the block state of the block to be processed as the first block state if the number of nodes of the target consensus node is greater than the node number threshold, and to take the block to be processed with the first block state as the deterministic success verification result.

[0244] The second verification unit 1053 is used to determine the block state of the block to be processed as the second block state if the number of nodes of the target consensus node is less than or equal to the node number threshold, and to take the block to be processed with the second block state as the deterministic failure verification result.

[0245] The verification result determination unit 1054 is used to take the deterministic successful verification result or the deterministic failed verification result as the block deterministic verification result.

[0246] The specific functional implementation methods of the node determination unit 1051, the first verification unit 1052, the second verification unit 1053, and the verification result determination unit 1054 can be found above. Figure 3 Step S101 in the corresponding embodiment will not be described again here.

[0247] In one implementation, the stream processing queue is built on a stream proxy component, and a business contract associated with the feedback service is deployed on the consensus node. The business contract registers the proxy public key of the consensus node proxy contained in the business stream processor.

[0248] The first signature module 106 is used to generate a data push request when the consensus node proxy obtains the first public key certificate containing the proxy public key, and to sign the data push request based on the proxy private key corresponding to the proxy public key to obtain the first signature information.

[0249] The first sending module 107 is used to send the data push request and the first signature information to the consensus node, so that after the consensus node successfully verifies the first signature information, it performs certificate verification on the first public key certificate based on the data push request and obtains the first certificate verification result.

[0250] The first communication module 108 is used to determine that the consensus node agent has data push permission if the first certificate verification result indicates successful verification, and to establish a first communication connection between the consensus node agent and the stream agent component; the first communication connection is used to transmit the business data obtained by the consensus node agent to the stream agent component.

[0251] In one implementation, the stream processing queue is built on a stream broker component, and a business contract associated with the feedback service is deployed on the consensus node. The business contract registers the component public key of the churn processing component contained in the business stream processor.

[0252] The second signature module 109 is used to generate a data retrieval request when the churn handling component obtains a second public key certificate containing the component's public key, and to sign the data retrieval request based on the component's private key corresponding to the component's public key to obtain the second signature information.

[0253] The second sending module 110 is used to send the data pull request and the second signature information to the consensus node, so that after the consensus node successfully verifies the second signature information, it performs certificate verification on the second public key certificate based on the data pull request and obtains the second certificate verification result.

[0254] The second communication module 111 is used to determine that the churn handling component has data retrieval permission if the second certificate verification result indicates successful verification, and to establish a second communication connection between the churn handling component and the stream proxy component; the second communication connection is used to transmit the business data stream stored in the stream proxy component to the churn handling component.

[0255] The specific functional implementation methods of the block verification module 101, the loss handling module 102, the service feedback module 103, the data request module 104, the block determination module 105, the first signature module 106, the first sending module 107, the first communication module 108, the second signature module 109, the second sending module 110, and the second communication module 111 can be found above. Figure 3 The corresponding steps S101-S103 in the embodiments, and the above Figure 6 Steps S301-S315 in the corresponding embodiments will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again.

[0256] Please see Figure 10This is a schematic diagram of the structure of a data processing device based on a layered blockchain provided in an embodiment of this application. The data processing device 2 based on a layered blockchain can be a computer program (including program code) running on a computer device; for example, the data processing device 2 based on a layered blockchain can be an application software. This device can be used to execute corresponding steps in the data processing method based on a layered blockchain provided in this embodiment of the application. In this embodiment, the device can run on a consensus node in the core consensus network, and the consensus node can be one of the aforementioned... Figure 2 In the corresponding embodiment, consensus node 20A, the layered blockchain may include the blockchain in the core consensus network, and the business flow processors in the core consensus network are associated with the consensus nodes. For example... Figure 10 As shown, the data processing device 2 based on the hierarchical blockchain may include: a block acquisition module 21, a feedback acquisition module 22, and a state change module 23;

[0257] The block acquisition module 21 is used to, when the consensus node obtains a data read request sent by the business flow processor based on the association relationship, return the block to be verified with the largest block height in the consensus node to the business flow processor according to the data read request, so that the business flow processor can perform block verification on the verification block and obtain the block verification result; when the block verification result indicates that the verification is successful, the business flow processor is used to send the business data associated with the block to be verified to the flow processing queue in the business flow processor in the form of a data stream, and to perform churn processing on the business data stream in the flow processing queue to obtain the churn processing result corresponding to the business data; the business flow processor is used to perform business logic analysis on the churn processing result to obtain the logic analysis result corresponding to the business data, and the logic analysis result is used to instruct the business flow processor to provide business feedback to the consensus node;

[0258] The feedback acquisition module 22 is used to acquire the feedback business transactions returned by the business flow processor; the feedback business transactions are generated by the business flow processor based on the results of logical analysis.

[0259] The state change module 23 is used to verify the feedback business transaction. When the feedback business transaction is successfully verified, the contract state of the business contract associated with the feedback business deployed on the consensus node is changed based on the feedback business transaction.

[0260] The aforementioned state change module 23 may include: a signature acquisition unit 231, a first consensus unit 232, a second consensus unit 233, and a verification success unit 234;

[0261] The signature acquisition unit 231 is used to acquire proxy signature information and engine signature information associated with the feedback business transaction; the feedback business transaction is obtained by the consensus node proxy in the business flow processor after assembling and processing the business feedback message; the proxy signature information is obtained by the consensus node proxy signing the feedback business transaction based on the proxy private key; the business feedback message is a message generated by the business processing engine contained in the business control component in the business flow processor based on the logical analysis results; the engine signature information is obtained by the business processing engine signing the business feedback message based on the engine private key.

[0262] The first consensus unit 232 is used to reach a consensus on the proxy signature information and obtain the first consensus result.

[0263] The second consensus unit 233 is used to reach consensus on the engine signature information when the first consensus result indicates that the consensus on the proxy signature information has passed, and to obtain the second consensus result.

[0264] The successful verification unit 234 is used to confirm the successful verification of the business transaction when the second consensus result indicates that the consensus of the engine signature information has been passed.

[0265] The specific functional implementation methods of the signature acquisition unit 231, the first consensus unit 232, the second consensus unit 233, and the verification success unit 234 can be found above. Figure 5 Step S203 in the corresponding embodiment will not be described again here.

[0266] The specific functional implementation methods of the block acquisition module 21, feedback acquisition module 22, and state change module 23 can be found in the above description. Figure 5 The corresponding steps S201-S203 in the embodiments, or as described above. Figure 6 Steps S301-S315 in the corresponding embodiments will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again.

[0267] Please see Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 11As shown, the computer device 1000 may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the processor 1001. Figure 11 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0268] In such Figure 11 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to execute the aforementioned... Figure 3 , Figure 5 , Figure 6 The description of the data processing method based on the hierarchical blockchain in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0269] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores the computer program executed by the aforementioned data processing device 1 and data processing device 2 based on hierarchical blockchain. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 , Figure 5 , Figure 6The description of the data processing method based on hierarchical blockchain in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network. These multiple computing devices distributed across multiple locations and interconnected via a communication network can constitute a blockchain system.

[0270] The aforementioned computer-readable storage medium can be the data processing device based on hierarchical blockchain provided in any of the foregoing embodiments, or the internal storage unit of the aforementioned 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., equipped on the computer device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices 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.

[0271] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned... Figure 3 , Figure 5 , Figure 6 The method is provided in any of the corresponding embodiments. Furthermore, the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0272] For further details, please see Figure 12 , Figure 12 This is a schematic diagram of the structure of a data processing system provided in an embodiment of this application. The data processing system 3 may include a data processing device 1a and a data processing device 2a. The data processing device 1a may be the one described above. Figure 9The data processing device 1 based on the hierarchical blockchain in the corresponding embodiment can be understood to be integrated into the above-mentioned... Figure 2 The service flow processor 20B in the corresponding embodiment will not be described in detail here. The data processing device 2a can be the one described above. Figure 10 The data processing device 2 based on the hierarchical blockchain in the corresponding embodiment can be understood to be integrated into the above-mentioned... Figure 2 The consensus node 20A in the corresponding embodiment will not be described again here. Furthermore, the beneficial effects of using the same method will also not be described again. For technical details not disclosed in the embodiments of the data processing system involved in this application, please refer to the description of the method embodiments of this application.

[0273] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0274] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0275] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on hierarchical blockchain, characterized in that, The method is executed by a business flow processor. The layered blockchain includes a blockchain in a core consensus network. The consensus nodes in the core consensus network are associated with the business flow processor. The association includes the data interaction relationship between the consensus node proxy in the business flow processor and the consensus node. The method includes: Based on the data interaction relationship, a data read request is sent to the consensus node through the consensus node proxy, so that the consensus node returns the block storage status of the consensus node and the unprocessed block with the maximum block height in the core consensus network according to the data read request; Based on the block storage state of the consensus node, the block to be processed is subjected to block deterministic verification to obtain the block deterministic verification result; When the deterministic verification result of the block is a deterministic success verification result, the block to be processed with the first block state indicated by the deterministic success verification result is taken as the block to be verified. Perform block verification on the block to be verified to obtain the block verification result; If the block verification result indicates that the verification is successful, the service data associated with the block to be verified is sent to the stream processing queue in the service stream processor in the form of a data stream. The service data stream in the stream processing queue is processed to obtain the churn processing result corresponding to the service data. The churn handling results are analyzed using business logic to obtain the logic analysis results corresponding to the business data. Based on the logic analysis results, business feedback is sent to the consensus node.

2. The method according to claim 1, characterized in that, The number of consensus nodes is N, where N is a positive integer; one consensus node corresponds to one block storage state. The step of performing block determinism verification on the block to be processed based on the block storage state of the consensus node to obtain the block determinism verification result includes: Based on the block storage status corresponding to each of the N consensus nodes, the consensus node that has stored the block to be processed among the N consensus nodes is taken as the target consensus node; the number of the target consensus nodes is less than or equal to N. If the number of nodes of the target consensus node is greater than the node number threshold, the block status of the block to be processed is determined as the first block status, and the block to be processed with the first block status is taken as the deterministic success verification result. If the number of nodes of the target consensus node is less than or equal to the node number threshold, then the block state of the block to be processed is determined as the second block state, and the block to be processed with the second block state is taken as the deterministic failure verification result. The deterministic success verification result or the deterministic failure verification result shall be used as the block deterministic verification result.

3. The method according to claim 2, characterized in that, The step of performing block verification on the block to be verified to obtain the block verification result includes: The consensus node proxy obtains the node signature set associated with the block to be verified and the node public keys corresponding to the N consensus nodes respectively. Based on the obtained N node public keys, the node signature set is verified to obtain the node signature verification result. The node signature set includes the node signature information obtained by each of the N consensus nodes signing the block to be verified. If the node verification result indicates that the verification was successful, then the Merkle root in the block to be verified is verified to obtain the root verification result. If the root verification result indicates that the root verification is successful, then the transaction data associated with the Merkel root in the block to be verified is verified to obtain the transaction verification result. If the transaction verification result indicates that the transaction verification was successful, then the block to be verified is determined to have been successfully verified, and the successfully verified block to be verified is taken as the block verification success result. Based on the node signature verification result, the root verification result, the transaction verification result, and the block verification success result, the block verification result is determined.

4. The method according to claim 3, characterized in that, The process of determining the block verification result based on the node signature verification result, the root verification result, the transaction verification result, and the block verification success result includes: If the node verification result indicates verification failure, or the root verification result indicates root verification failure, or the transaction verification result indicates transaction verification failure, then the block to be verified is determined to have failed verification, and the block to be verified that failed verification is taken as the block verification failure result. The block verification success result or the block verification failure result shall be used as the block verification result.

5. The method according to claim 1, characterized in that, The step of sending the service data associated with the block to be verified to the stream processing queue in the service stream processor as a data stream, performing churn processing on the service data stream in the stream processing queue, and obtaining the churn processing result corresponding to the service data includes: The consensus node proxy in the business flow processor reads the transaction data of the block to be verified and the contract data associated with the transaction data from the node memory of the consensus node where the block to be verified is located, and uses the read transaction data and the contract data as business data associated with the block to be verified. The business data is sent as a data stream to the stream processing queue in the business stream processor for storage, and the business data stored in the stream processing queue is used as a business data stream. The churn handling component in the business flow processor and the conversion processing engine associated with the churn handling component perform churn handling on the business data flow to obtain the churn handling result corresponding to the business data.

6. The method according to claim 5, characterized in that, The step of performing churn processing on the service data stream through the churn processing component in the service flow processor and the conversion processing engine associated with the churn processing component to obtain the churn processing result corresponding to the service data includes: The service data stream is pulled from the stream processing queue by the churn handling component in the service stream processor, and the pulled service data stream is split into data streams based on the splitting time interval to obtain at least two sub-service data streams; The at least two sub-service data streams are transmitted to the conversion processing engine associated with the churn handling component for data conversion processing to obtain the conversion processing result corresponding to each sub-service data stream. The at least two conversion processing results obtained are used as the churn handling result corresponding to the service data.

7. The method according to claim 1, characterized in that, The stream processing queue is built based on a stream proxy component. A business contract associated with the feedback service is deployed on the consensus node, and the business contract registers the proxy public key of the consensus node proxy included in the business stream processor. The method further includes: When the consensus node proxy obtains the first public key certificate containing the proxy public key, it generates a data push request and signs the data push request based on the proxy private key corresponding to the proxy public key to obtain the first signature information; The data push request and the first signature information are sent to the consensus node, so that after the consensus node successfully verifies the first signature information, it performs certificate verification on the first public key certificate based on the data push request to obtain the first certificate verification result. If the first certificate verification result indicates successful verification, it is determined that the consensus node agent has data push permission, and a first communication connection is established between the consensus node agent and the stream proxy component; the first communication connection is used to transmit the business data obtained by the consensus node agent to the stream proxy component.

8. The method according to claim 1, characterized in that, The stream processing queue is built based on the stream proxy component. The consensus node is deployed with a business contract associated with the feedback service. The business contract registers the component public key of the churn handling component contained in the business stream processor. The method further includes: When the churn handling component obtains a second public key certificate containing the component's public key, it generates a data retrieval request and signs the data retrieval request based on the component's private key corresponding to the component's public key to obtain second signature information. The data retrieval request and the second signature information are sent to the consensus node, so that after the consensus node successfully verifies the second signature information, it performs certificate verification on the second public key certificate based on the data retrieval request to obtain the second certificate verification result. If the second certificate verification result indicates successful verification, it is determined that the churn handling component has data retrieval permission, and a second communication connection is established between the churn handling component and the stream proxy component; the second communication connection is used to transmit the business data stream stored in the stream proxy component to the churn handling component.

9. The method according to claim 1, characterized in that, The business flow processor also includes a consensus node proxy and a business control component. The business control component contains a business processing engine associated with the target business logic. A business contract associated with the feedback business is deployed on the consensus node. The business contract registers the engine private key of the business processing engine. The process of performing business logic analysis on the churn handling results to obtain the logic analysis results corresponding to the business data, and providing business feedback to the consensus node based on the logic analysis results, includes: Based on the target business logic, the business processing engine is invoked to perform business logic analysis on the churn handling result, and the logic analysis result corresponding to the business data is obtained. A business feedback message is generated based on the logical analysis result. The business feedback message is signed based on the engine private key to obtain engine signature information. The engine signature information and the business feedback message are returned to the consensus node proxy through the component interface of the business control component. The consensus node proxy performs engine signature verification on the engine signature information to obtain the engine signature verification result; If the engine verification result indicates successful verification, the business feedback message is forwarded to the consensus node.

10. The method according to claim 9, characterized in that, If the engine verification result indicates successful verification, the business feedback message is forwarded to the consensus node, including: If the engine verification result indicates successful verification, the business feedback message is processed to assemble the transaction to obtain a feedback business transaction. The feedback business transaction is then signed based on the proxy private key of the consensus node to obtain proxy signature information. The proxy signature information and the feedback business transaction are forwarded to the consensus node so that the consensus node can reach a consensus on the proxy signature information and the engine signature information. When the proxy signature information and the engine signature information are both agreed upon, the contract state of the business contract is changed based on the feedback business transaction.

11. A data processing method based on hierarchical blockchain, characterized in that, The method is executed by consensus nodes in the core consensus network. The layered blockchain includes the blockchain in the core consensus network. The business flow processor in the core consensus network is associated with the consensus nodes. The association includes the data interaction relationship between the consensus node proxy in the business flow processor and the consensus nodes. The method includes: When the consensus node receives a data read request sent by the consensus node proxy based on the data interaction relationship, it returns the block storage state of the consensus node and the unprocessed block with the maximum block height in the core consensus network to the service flow processor according to the data read request. This allows the service flow processor to perform block deterministic verification on the unprocessed block based on the block storage state of the consensus node, obtaining a block deterministic verification result. When the block deterministic verification result is a successful deterministic verification result, the unprocessed block with the first block state indicated by the successful deterministic verification result is taken as the block to be verified. The stream processor is used to perform block verification on the verification block to obtain a block verification result. When the block verification result indicates successful verification, the service stream processor is also used to send the service data associated with the block to be verified to the stream processing queue in the service stream processor as a data stream, and to perform churn processing on the service data stream in the stream processing queue to obtain a churn processing result corresponding to the service data. The service stream processor is also used to perform business logic analysis on the churn processing result to obtain a logic analysis result corresponding to the service data. The logic analysis result is used to instruct the service stream processor to provide business feedback to the consensus node. Obtain the feedback business transaction returned by the business flow processor; the feedback business transaction is generated by the business flow processor based on the logical analysis results; The feedback service transaction is verified. When the feedback service transaction is successfully verified, the contract status of the business contract associated with the feedback service deployed on the consensus node is changed based on the feedback service transaction.

12. The method according to claim 11, characterized in that, The transaction verification of the feedback business transaction includes: Obtain the proxy signature information and engine signature information associated with the feedback business transaction; the feedback business transaction is obtained by the consensus node proxy in the business flow processor after assembling and processing the business feedback message; the proxy signature information is obtained by the consensus node proxy signing the feedback business transaction based on the proxy private key; the business feedback message is a message generated by the business processing engine contained in the business control component in the business flow processor according to the logical analysis result; the engine signature information is obtained by the business processing engine signing the business feedback message based on the engine private key. A consensus is reached on the proxy signature information to obtain a first consensus result; When the first consensus result indicates that the consensus on the proxy signature information has passed, consensus is reached on the engine signature information to obtain a second consensus result. When the second consensus result indicates that the consensus on the engine signature information has passed, it is determined that the feedback business transaction verification is successful.

13. A data processing device based on hierarchical blockchain, characterized in that, The device operates in a business flow processor. The hierarchical blockchain includes a blockchain in a core consensus network. The consensus nodes in the core consensus network are associated with the business flow processor. This association includes the data interaction relationship between the consensus node proxy in the business flow processor and the consensus node. The device includes: The data request module is used to send a data read request to the consensus node through the consensus node proxy based on the data interaction relationship, so that the consensus node returns the block storage status of the consensus node and the unprocessed block with the maximum block height in the core consensus network according to the data read request; The block determination module is used to perform block determinism verification on the block to be processed based on the block storage status of the consensus node, and obtain the block determinism verification result; The block determination module is further configured to, when the block deterministic verification result is a deterministic success verification result, take the block to be processed with the first block state indicated by the deterministic success verification result as the block to be verified. The block verification module is used to perform block verification on the block to be verified when the service flow processor obtains the block to be verified with the maximum block height from the consensus node based on the association relationship, and obtain the block verification result. The churn handling module is used to send the service data associated with the block to be verified to the stream processing queue in the service stream processor in the form of a data stream if the block verification result indicates that the verification is successful, and to perform churn handling on the service data stream in the stream processing queue to obtain the churn handling result corresponding to the service data. The business feedback module is used to perform business logic analysis on the churn handling results, obtain the logic analysis results corresponding to the business data, and provide business feedback to the consensus node based on the logic analysis results.

14. A data processing device based on a hierarchical blockchain, characterized in that, The device operates in a consensus node within a core consensus network. The layered blockchain includes the blockchain within the core consensus network. The business flow processor in the core consensus network is associated with the consensus node, and this association includes the data interaction relationship between the consensus node proxy in the business flow processor and the consensus node. The device includes: The block acquisition module is configured to, when the consensus node receives a data read request sent by the consensus node's proxy based on the data interaction relationship, return the block storage state of the consensus node and the unprocessed block with the maximum block height in the core consensus network to the service flow processor according to the data read request. This allows the service flow processor to perform block deterministic verification on the unprocessed block based on the block storage state of the consensus node, obtaining a block deterministic verification result. When the block deterministic verification result is a successful deterministic verification result, the unprocessed block with the first block state indicated by the successful deterministic verification result is designated as the block to be verified. The service flow processor is used to perform block verification on the verification block to obtain a block verification result. When the block verification result indicates successful verification, the service flow processor is also used to send the service data associated with the block to be verified to the flow processing queue in the service flow processor as a data stream, and to perform churn processing on the service data stream in the flow processing queue to obtain a churn processing result corresponding to the service data. The service flow processor is also used to perform business logic analysis on the churn processing result to obtain a logic analysis result corresponding to the service data. The logic analysis result is used to instruct the service flow processor to provide business feedback to the consensus node. The feedback acquisition module is used to acquire the feedback business transaction returned by the business flow processor; the feedback business transaction is generated by the business flow processor based on the logical analysis result; The state change module is used to verify the feedback business transaction. When the feedback business transaction is successfully verified, the contract state of the business contract associated with the feedback business deployed on the consensus node is changed based on the feedback business transaction.

15. A computer device, characterized in that, include: Processor and memory; The processor is connected to the memory, wherein the memory is used to store a computer program, and the processor is used to invoke the computer program to cause the computer device to perform the method according to any one of claims 1-12.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-12.

17. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, the computer instructions being adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-12.

Images