Transaction processing method and device, equipment and storage medium

Abstract

The invention provides a transaction processing method and device, equipment and a storage medium, can be applied to the field of block chains and the like, and is used for solving the problem of relatively low transaction processing efficiency in a transaction processing process based on an alliance chain. The method at least comprises the following steps: a master node cluster acquires each slave node cluster associated with the master node cluster and acquires a to-be-processed transaction; wherein each service node in each slave node cluster is from different node providers, and the error between the first performance parameters of each two service nodes is within a preset error range; when it is determined that the to-be-processed transaction is a contract deployment transaction, respectively determining a second performance parameter of each slave node cluster based on a pre-stored cluster performance detection strategy; and sending the contract deployment transaction to a target node cluster of which the second performance parameter meets a preset screening condition in each slave node cluster. The transaction processing efficiency is improved by reasonably reducing the number of service nodes participating in transaction processing.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a transaction processing method, apparatus, device, and storage medium. Background Art

[0002] With the continuous advancement of technology, more and more devices can process transactions through consortium blockchain systems. For example, consortium blockchain systems can handle transfers between accounts. In a consortium blockchain system, a blockchain is managed and controlled by multiple organizations or entities. These organizations or entities act as node providers, providing multiple service nodes for the consortium blockchain system. Each service node can process transactions, verify transactions, and use data in the consortium blockchain system.

[0003] In related technologies, the transaction processing method based on the alliance chain is to select one service node from each service node as the master node, and the other service nodes as slave nodes; the master node combines with the slave nodes to obtain and execute the pending transactions.

[0004] When the pending transaction is a contract deployment transaction, the smart contract provided by the contract deployment transaction is deployed in the master node and each slave node respectively, so that the master node and each slave node can process the data processing transaction involving the smart contract to obtain the transaction processing result;

[0005] When the transaction to be processed is a data processing transaction, the master node and each slave node perform data processing on the data to be processed provided by the data processing transaction based on the smart contract involved in the data processing transaction to obtain the transaction processing result.

[0006] However, as the amount of business data in various business scenarios continues to increase, when the number of service nodes included in the consortium chain system is large, if all service nodes participate in the processing of each pending transaction, the computational complexity of processing transactions will increase at a polynomial level, resulting in a significant decrease in transaction processing throughput and thus a reduction in transaction processing efficiency.

[0007] At the same time, the processing performance of each service node is different. During the transaction processing process, the service node with better processing performance needs to be idle to wait for the service node with poor processing performance to process the transaction, which is prone to the "barrel effect" problem, thereby reducing transaction processing efficiency.

[0008] It can be seen that the transaction processing efficiency of the transaction processing process based on the alliance chain in the relevant technology is low. Summary of the Invention

[0009] The embodiments of the present application provide a transaction processing method, apparatus, device, and storage medium for solving the problem of low transaction processing efficiency in the transaction processing process based on the alliance chain.

[0010] In a first aspect, a transaction processing method is provided, which is applied to a master node cluster in a consortium chain system, wherein the consortium chain system includes multiple service nodes provided by multiple node providers, each of which is provided by a different node provider. The method comprises:

[0011] Obtaining slave node clusters associated with the master node cluster and obtaining pending transactions; wherein each service node in each slave node cluster is from a different node provider, and an error between a first performance parameter of each two service nodes is within a preset error range; the first performance parameter represents: task processing performance of the corresponding service node in processing random computing tasks;

[0012] When it is determined that the transaction to be processed is a contract deployment transaction, second performance parameters of each of the slave node clusters are determined based on a pre-stored cluster performance detection strategy; wherein the second performance parameter represents: the comprehensive processing performance of the service node when the corresponding slave node cluster processes the transaction;

[0013] The contract deployment transaction is sent to the target node cluster in each slave node cluster whose second performance parameter meets the preset screening condition, so that the target node cluster deploys the corresponding smart contract based on the contract deployment transaction to process the data processing transaction involving the smart contract and generate a transaction processing result.

[0014] In a second aspect, a transaction processing device is provided, which is applied to a master node cluster in a consortium chain system, wherein the consortium chain system includes multiple service nodes provided by multiple node providers, each of which is provided by a different node provider. The device includes:

[0015] An acquisition module is configured to acquire slave node clusters associated with the master node cluster and to acquire pending transactions; wherein each service node in each slave node cluster is from a different node provider, and the error between a first performance parameter of each two service nodes is within a preset error range; and the first performance parameter represents the task processing performance of the corresponding service node in processing random computing tasks;

[0016] A processing module: configured to, when determining that the transaction to be processed is a contract deployment transaction, determine, based on a pre-stored cluster performance detection strategy, a second performance parameter of each slave node cluster; wherein the second performance parameter represents: the comprehensive processing performance of the service node when the corresponding slave node cluster processes the transaction;

[0017] The processing module is also used to: send the contract deployment transaction to the target node cluster whose second performance parameter meets the preset screening conditions in each slave node cluster, so that the target node cluster deploys the corresponding smart contract based on the contract deployment transaction to process the data processing transaction involving the smart contract and generate a transaction processing result.

[0018] Optionally, the acquisition module is specifically configured to:

[0019] Sending random computing tasks to other service nodes in the consortium chain system, except for the service nodes included in the master node cluster, so that each other service node performs task processing based on the received random computing tasks and returns the end time when the task processing ends;

[0020] Determining first performance parameters of each of the other service nodes based on the received end times returned by each of the other service nodes;

[0021] Based on the obtained first performance parameters and the node providers corresponding to the other service nodes, the other service nodes are grouped to obtain slave node clusters associated with the master node cluster.

[0022] Optionally, the random computing task includes: a main computing task generated by a master node based on a random main task generation strategy; the master node is: a service node for generating blocks among the service nodes included in the master node cluster;

[0023] The acquisition module is specifically used for:

[0024] The master node sends the master computing task to each of the other service nodes, so that each of the other service nodes performs task processing based on the received master computing task and returns a master end time when the task processing ends.

[0025] Optionally, the random computing task includes: a slave computing task generated by each slave node based on a random slave task generation strategy; the slave node is: a service node among the service nodes included in the master node cluster, used to verify blocks based on a consensus strategy;

[0026] The acquisition module is specifically used for:

[0027] Each slave node receives a node performance detection block respectively; wherein the node performance detection block instructs: the corresponding slave node to send the slave computing task to each other service node respectively;

[0028] Each slave node sends a corresponding slave computing task to each other service node based on the received node performance detection block, so that each other service node performs task processing based on the received slave computing task and returns the slave end time when the task processing ends.

[0029] Optionally, the processing module is further configured to:

[0030] After each slave node sends a corresponding slave computing task to each other service node based on the received node performance detection block, each slave node performs the following operations: the slave node performs block verification on the node performance detection block based on the slave end time returned by each other service node, and generates a block verification result corresponding to the slave node; wherein the block verification result indicates whether the corresponding slave node has passed verification of the node performance detection block;

[0031] Each slave node returns a corresponding block verification result to the master node; the master node is: the service node that generates the node performance detection block among the service nodes included in the master node cluster;

[0032] The master node determines, based on the obtained verification results of each block, that each slave node has passed the verification of the node performance detection block, and uses the respective master end times as the end times.

[0033] Optionally, the node performance detection block includes: a main end time when each of the other service nodes finishes processing a main computing task; the main computing task is generated by the master node based on a random main task generation strategy and sent to each of the other service nodes;

[0034] The processing module is specifically used for:

[0035] The slave node performs averaging processing on each received slave end time to obtain a slave mean time;

[0036] The slave node performs averaging processing on each master end time included in the node performance detection block to obtain a master mean time;

[0037] The slave node matches the master mean time and the slave mean time to generate a block verification result corresponding to the slave node.

[0038] Optionally, the processing module is specifically configured to:

[0039] Determine the time difference between each of the end times and the sending time of the random computing task;

[0040] Based on the obtained time differences, a first performance parameter of each of the other service nodes is determined; wherein the time difference is negatively correlated with the first performance parameter.

[0041] Optionally, the processing module is specifically configured to:

[0042] Obtaining node performance parameters of each service node included in each slave node cluster; wherein the node performance parameters represent: node processing performance of the corresponding service node when processing transactions;

[0043] For each of the slave node clusters, the following operations are performed respectively to determine a second performance parameter of the slave node cluster based on the obtained weighted sum of the performance parameters of each node corresponding to the slave node cluster.

[0044] Optionally, the processing module is specifically configured to:

[0045] Sending a performance test instruction to each slave node cluster, wherein the performance test instruction instructs: obtaining a node performance parameter corresponding to each service node included in the corresponding slave node cluster; the node performance parameter represents: a non-idle time duration during which the corresponding service node is in a non-idle state for processing transactions within a preset time duration starting from the current time when the performance test instruction is sent; the non-idle time duration is negatively correlated with the node performance parameter;

[0046] Receive multiple node performance parameters returned by each of the slave node clusters.

[0047] Optionally, the processing module is specifically configured to:

[0048] For each slave node cluster, perform the following operations:

[0049] After the slave node cluster finishes processing the historical transaction, node performance parameters of each service node included in the slave node cluster are received and sent by the slave node cluster; the node performance parameters represent: the transaction processing time of the corresponding service node processing the historical transaction; the transaction processing time is negatively correlated with the node performance parameters.

[0050] Optionally, the processing module is specifically configured to:

[0051] Selecting the slave node cluster with the largest value of the second performance parameter among the slave node clusters as the target node cluster; or,

[0052] Based on the values ​​of the obtained second performance parameters, the slave node clusters are sorted to obtain a ranking order for each of the slave node clusters, and a slave node cluster whose ranking order matches the contract priority of the contract to be deployed provided by the contract deployment transaction is selected as the target node cluster; wherein the contract priority represents: the number of data processing transactions involving the corresponding contract to be deployed;

[0053] Send the contract deployment transaction to the target node cluster.

[0054] Optionally, the processing module is further configured to:

[0055] After obtaining the pending transaction, when determining that the pending transaction is a data processing transaction, obtaining at least one cluster contract deployed by each of the slave node clusters;

[0056] Determining, based on at least one cluster contract deployed by each of the slave node clusters, a target node cluster in each of the slave node clusters that deploys the smart contract involved in the data processing transaction;

[0057] The data processing transaction is sent to the target node cluster, so that the target node cluster performs transaction processing based on the received data processing transaction and generates a transaction processing result.

[0058] According to a third aspect, a computer program product is provided, comprising a computer program, which implements the method according to the first aspect when executed by a processor.

[0059] According to a fourth aspect, a computer device is provided, comprising:

[0060] a memory for storing program instructions;

[0061] The processor is configured to call the program instructions stored in the memory and execute the method described in the first aspect according to the obtained program instructions.

[0062] In a fifth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method described in the first aspect.

[0063] In the embodiments of the present application, each service node in the consortium chain system is divided into a master node cluster and its associated multiple slave node clusters. The master node cluster is used to manage the slave node clusters, which are used to process transactions. This greatly reduces the number of service nodes required to process each transaction, polynomially reducing computational complexity, increasing transaction processing throughput, and improving transaction processing efficiency. Furthermore, it enables the consortium chain system to scale to handle more transactions without being limited by the performance bottlenecks of a single chain.

[0064] Among them, the master node cluster includes service nodes provided by different node providers, and the slave node cluster includes service nodes provided by different node providers. In this way, the service nodes are evenly distributed, avoiding any node provider controlling too many service nodes in the master node cluster, improving the decentralization of the master node cluster, increasing the difficulty for abnormal accounts to break into the master node cluster, and improving data security.

[0065] Furthermore, the error between the first performance parameters of every two service nodes included in the slave node cluster is within the preset error range, so that the processing performance of each service node in the same slave node cluster is equivalent, avoiding the situation where the service nodes with better processing performance need to be idle when the slave node cluster processes transactions to wait for the service nodes with poorer processing performance to process transactions, that is, avoiding the "barrel effect" problem and improving transaction processing efficiency.

[0066] Furthermore, when the pending transaction is a contract deployment transaction, a target node cluster that meets preset screening criteria can be selected based on the second performance parameter of each slave node cluster to deploy the smart contract provided by the contract deployment transaction. This allows the smart contract provided by the contract deployment transaction to be deployed on a slave node cluster with suitable processing performance. This not only avoids the situation where all service nodes in the consortium chain system deploy all smart contracts to participate in transaction processing, resulting in low transaction processing efficiency, but also ensures the rational utilization of service node resources. This ensures that high-performance service nodes bear more workloads, while low-performance service nodes do not become bottlenecks in the consortium chain system, thereby improving transaction processing efficiency to a certain extent. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] Figure 1A A schematic diagram of a scenario of the transaction processing method provided in an embodiment of the present application;

[0068] Figure 1B A schematic diagram of a transaction processing method in related technology;

[0069] Figure 1C An application scenario of the transaction processing method provided in the embodiment of the present application;

[0070] Figure 2A A schematic diagram of a transaction processing method according to an embodiment of the present application;

[0071] Figure 2B A second schematic diagram of a principle of a transaction processing method provided in an embodiment of the present application;

[0072] Figure 2C A structural diagram of a transaction processing method provided in an embodiment of the present application;

[0073] Figure 2D A flowchart of a transaction processing method provided in an embodiment of the present application is shown in FIG1 ;

[0074] Figure 3 A second flow chart of a transaction processing method provided in an embodiment of the present application;

[0075] Figure 4A A schematic diagram of the transaction processing method provided in this embodiment of the application Figure 3 ;

[0076] Figure 4B A schematic diagram of a transaction processing method provided in an embodiment of the present application Figure 3 ;

[0077] Figure 4C An interactive diagram of the transaction processing method provided in an embodiment of the present application;

[0078] Figure 5A A fourth schematic diagram of a principle of a transaction processing method provided in an embodiment of the present application;

[0079] Figure 5B A second structural diagram of a transaction processing method provided in an embodiment of the present application;

[0080] Figure 5C A fourth flowchart of a transaction processing method provided in an embodiment of the present application;

[0081] Figure 6A A fifth schematic diagram of a principle of a transaction processing method provided in an embodiment of the present application;

[0082] Figure 6B A sixth schematic diagram of a principle of a transaction processing method provided in an embodiment of the present application;

[0083] Figure 7A Schematic diagram 7 of a principle of a transaction processing method provided in an embodiment of the present application;

[0084] Figure 7B A schematic diagram of the transaction processing method provided in this embodiment of the application Figure 8 ;

[0085] Figure 7C Schematic diagram 5 of a flow chart of a transaction processing method provided in an embodiment of the present application;

[0086] Figure 7D Schematic diagram 6 of a flow chart of a transaction processing method provided in an embodiment of the present application;

[0087] Figure 8 A first structural diagram of a transaction processing device provided in an embodiment of the present application;

[0088] Figure 9 A second structural diagram of a transaction processing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0089] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0090] Some of the terms used in the embodiments of the present application are explained below to facilitate understanding by those skilled in the art.

[0091] (1) Consortium Blockchain and Consortium Blockchain System:

[0092] A consortium blockchain is a blockchain network model that is jointly managed and maintained by multiple organizations or entities. Compared to public blockchains, consortium blockchains focus more on participant authentication, access control, and data privacy protection.

[0093] A consortium blockchain system is a private blockchain network based on blockchain technology, jointly managed and maintained by several independent organizations or entities. Participants in a consortium blockchain system require permission to join the network, and they can jointly establish network rules and determine transaction verification mechanisms. Through this consortium blockchain system, participants can securely share data and conduct transactions while protecting their privacy and business interests. Consortium blockchains aim to address some of the challenges of traditional centralized systems, such as trust and transparency. They provide a secure and reliable way to record and verify transactions, enabling collaboration and information sharing among members.

[0094] (2) Blockchain:

[0095] Blockchain is a distributed ledger technology in the field of information technology. It is generally composed of consensus, transaction blocks and status data storage, cryptographic identity security, etc. Since the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of being tamper-proof, traceable, and jointly maintained.

[0096] (3) Smart contract:

[0097] A smart contract is a computer protocol designed to communicate, verify, or execute contracts in an information-based manner. Smart contracts allow for trusted transactions without a third party, and these transactions are traceable and irreversible.

[0098] (4) Blockchain ledger:

[0099] The blockchain ledger is the core data structure in a blockchain system, used to store and manage all confirmed blocks. Organized in a chain-like structure, each block contains a set of transactions, a block header (including metadata such as the previous block's hash value and timestamp), and other information. The ledger provides a public, immutable record of transaction history within the blockchain system, ensuring transparency and consistency.

[0100] (5) Status data:

[0101] State data is a data structure used in blockchain systems to represent the current state of the system. This data includes the balances of all accounts, the status of smart contracts, and other relevant information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a given point in time. In blockchain systems, state data is typically stored in the form of Merkle trees or other encrypted data structures to ensure its integrity and security.

[0102] (6) Transaction Pool:

[0103] The transaction pool (also known as the memory pool or mempool) is a data structure in a blockchain network that stores pending transactions that have not yet been included in a block. When a user submits a new transaction to the blockchain network, it first enters the transaction pool. When a blockchain node prepares to generate a new block, it selects a certain number of transactions from the transaction pool to include in the block.

[0104] (7) Throughput:

[0105] Throughput refers to the amount of data or processing power that passes through a system, device, or network in a given period of time. Common units include data rates per second (bps) and queries per second. For example, network bandwidth throughput is often measured in data transferred per second. In computing, throughput is often used to evaluate hardware or software performance.

[0106] The embodiments of the present application involve blockchain technology and cloud computing. Blockchain technology and cloud computing can be applied to multiple fields, such as common smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, unmanned driving, autonomous driving, smart transportation, smart maps, assisted driving, in-vehicle terminals, aircraft, digital twins, virtual humans, robots, artificial intelligence generated content (AIGC), conversational interaction, smart medical care, smart customer service, game AI, etc. It is believed that with the development of technology, blockchain technology and cloud computing will be applied in more fields and play an increasingly important role.

[0107] Blockchain is a new application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a series of data blocks linked using cryptographic methods. Each block contains information about a batch of online transactions, used to verify the validity of this information (to prevent counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, the platform product and service layer, and the application service layer.

[0108] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation control. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the corresponding relationship between the user's real identity and the blockchain address (authority management), etc., and under authorization, it supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records the valid requests to the storage after consensus is reached. For a new business request, the basic service first adapts the interface to parse and authenticate the request (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration, issuance, triggering and execution of contracts. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the contract logic is triggered by calling keys or other events to trigger execution. The contract logic is completed, and the contract upgrade and cancellation functions are also provided. The operation and control module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the release process, such as alarms, network control, and node device health status.

[0109] The platform's product service layer provides the basic capabilities and implementation framework for typical applications. Developers can build on these basic capabilities, overlay business features, and complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0110] Cloud computing is a computing model that distributes computing tasks across a resource pool consisting of a large number of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network that provides these resources is called the "cloud." To users, these resources appear infinitely scalable and can be accessed at any time, used on demand, expanded at any time, and paid for on a pay-per-use basis.

[0111] It should be noted that in the embodiments of this application, related operations such as obtaining pending transactions or deploying smart contracts in the alliance chain system are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

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

[0113] The following is a brief introduction to the application areas of the transaction processing method provided in the embodiments of the present application.

[0114] With the continuous advancement of technology, more and more devices can process transactions through consortium blockchain systems. For example, consortium blockchain systems can handle transfers between accounts. In a consortium blockchain system, a blockchain is managed and controlled by multiple organizations or entities. These organizations or entities act as node providers, providing multiple service nodes for the consortium blockchain system. Each service node can process transactions, verify transactions, and use data in the consortium blockchain system.

[0115] For example, in the field of cross-border payments, each fund deposit and withdrawal platform and financial platform can act as a node provider, providing multiple service nodes for the alliance chain system. Each service node can handle fund-related transactions in different currencies and regions. Figure 1A, including the first fund access platform, the second fund access platform, the first financial platform, and the second financial platform. The first fund access platform provides three service nodes; the second fund access platform provides two service nodes; the first financial platform provides four service nodes; and the second financial platform provides two service nodes. Therefore, the alliance chain system includes 11 service nodes.

[0116] For example, in the field of supply chain management, organizations such as manufacturers, suppliers, logistics companies, and retailers can act as node providers and provide multiple service nodes for the alliance chain system. Each service node can handle transactions such as data sharing or product traceability in the supply chain.

[0117] For example, in areas such as insurance claims, real estate sales, or copyright management, relevant entities or organizations can act as node providers to provide multiple service nodes to process related transactions.

[0118] For example, for applications that require identity authentication and data sharing, such as those that require access to medical records or verification of educational certificates, application-related organizations can act as node providers to provide multiple service nodes to process identity authentication transactions or data sharing transactions.

[0119] For example, for voting and governance systems, a fair and transparent voting process is required, such as corporate governance or community decision-making processes. The parties involved in the voting can act as node providers to provide multiple service nodes to process related voting transactions.

[0120] For related technologies, please refer to Figure 1B The transaction processing method based on the alliance chain is to select one service node from each service node as the master node, and the other service nodes as slave nodes; the master node combines with the slave nodes to obtain and execute the pending transactions.

[0121] When the pending transaction is a contract deployment transaction, the smart contract provided by the contract deployment transaction is deployed in the master node and each slave node respectively, so that the master node and each slave node can process the data processing transaction involving the smart contract to obtain the transaction processing result;

[0122] When the transaction to be processed is a data processing transaction, the master node and each slave node perform data processing on the data to be processed provided by the data processing transaction based on the smart contract involved in the data processing transaction to obtain the transaction processing result.

[0123] However, as the amount of business data in various business scenarios continues to increase, when the number of service nodes included in the alliance chain system is large, if all service nodes participate in the processing of each pending transaction, the computational complexity of processing transactions will increase polynomially, and the network will be severely congested, resulting in a significant decrease in transaction processing throughput, thereby reducing transaction processing efficiency.

[0124] At the same time, the processing performance of each service node is different. During the transaction processing process, the service node with better processing performance needs to be idle to wait for the service node with poor processing performance to process the transaction, which is prone to the "barrel effect" problem, thereby reducing transaction processing efficiency.

[0125] It can be seen that the transaction processing efficiency of the transaction processing process based on the alliance chain in the relevant technology is low.

[0126] Furthermore, if a node provider controls a large number of service nodes in a consortium chain system, the degree of decentralization of the consortium chain system will be low, making it prone to abnormal behaviors such as double spending or 51% attacks, making the transaction processing security of the consortium chain-based transaction processing process in related technologies low.

[0127] To address the low transaction processing efficiency of consortium chain-based transactions, this application proposes a transaction processing method. This method is applied to a master node cluster in a consortium chain system. The consortium chain system includes multiple service nodes provided by multiple node providers, each of which comes from a different node provider.

[0128] In this method, the slave node clusters associated with the master node cluster are first obtained, and then the pending transactions are obtained. The service nodes in each slave node cluster are from different node providers, and the error between the first performance parameters of each two service nodes is within a preset error range. The first performance parameter represents the task processing performance of the corresponding service node in handling random computing tasks.

[0129] When the pending transaction is determined to be a contract deployment transaction, a second performance parameter is determined for each slave node cluster based on a pre-stored cluster performance detection strategy. This second performance parameter represents the overall processing performance of the service node when the corresponding slave node cluster processes the transaction. A contract deployment transaction is then sent to the target node cluster in each slave node cluster whose second performance parameter meets the pre-set screening criteria. Based on the contract deployment transaction, the target node cluster deploys the corresponding smart contract, processes the data processing transaction involving the smart contract, and generates a transaction processing result.

[0130] In the embodiments of the present application, each service node in the consortium chain system is divided into a master node cluster and its associated multiple slave node clusters. The master node cluster is used to manage the slave node clusters, which are used to process transactions. This greatly reduces the number of service nodes required to process each transaction, polynomially reducing computational complexity, increasing transaction processing throughput, and improving transaction processing efficiency. Furthermore, it enables the consortium chain system to scale to handle more transactions without being limited by the performance bottlenecks of a single chain.

[0131] Among them, the master node cluster includes service nodes provided by different node providers, and the slave node cluster includes service nodes provided by different node providers. In this way, the service nodes are evenly distributed, avoiding any node provider controlling too many service nodes in the master node cluster, improving the decentralization of the master node cluster, increasing the difficulty for abnormal accounts to break into the master node cluster, and improving data security.

[0132] Furthermore, the error between the first performance parameters of every two service nodes included in the slave node cluster is within the preset error range, so that the processing performance of each service node in the same slave node cluster is equivalent, avoiding the situation where the service nodes with better processing performance need to be idle when the slave node cluster processes transactions to wait for the service nodes with poorer processing performance to process transactions, that is, avoiding the "barrel effect" problem and improving transaction processing efficiency.

[0133] Furthermore, when the pending transaction is a contract deployment transaction, a target node cluster that meets the preset screening criteria can be selected based on the second performance parameter of each slave node cluster to deploy the smart contract provided by the contract deployment transaction. This allows the smart contract provided by the contract deployment transaction to be deployed on a slave node cluster with suitable processing performance. This not only avoids the situation where all service nodes in the consortium chain system deploy all smart contracts to participate in transaction processing, resulting in low transaction processing efficiency, but also ensures the rational utilization of service node resources, thereby improving transaction processing efficiency to a certain extent.

[0134] The following describes the application scenarios of the transaction processing method provided by this application.

[0135] Please refer to Figure 1C, which is a schematic diagram of an application scenario of the transaction processing method provided in this application. The application scenario includes a client 101 cluster and a server 102 cluster. The client 101 cluster includes multiple clients 101, each client 101 represents a node provider; the server 102 cluster includes multiple servers 102, each server 102 represents a service node. Each client 101 is associated with multiple servers 102, and communication can be achieved between the clients 101, between the servers 102, and between the client 101 and the server 102 associated with it. The communication method can be to use wired communication technology, for example, by connecting a network cable or a serial cable to communicate; or it can be to use wireless communication technology, for example, by using Bluetooth or wireless fidelity (WIFI) and other technologies for communication, without specific limitation.

[0136] Client 101 generally refers to a device that can serve as a node provider, such as a terminal device, a third-party application accessible by the terminal device, or a webpage accessible by the terminal device. Terminal devices include, but are not limited to, mobile phones, computers, smart medical devices, smart home appliances, vehicle-mounted terminals, or aircraft. Server 102 generally refers to a device that can process transactions, such as a terminal device or server. Servers include, but are not limited to, cloud servers, local servers, or associated third-party servers. Both client 101 and server 102 can utilize cloud computing to reduce the use of local computing resources; similarly, they can utilize cloud storage to reduce the use of local storage resources.

[0137] As an embodiment, the client 101 and the server 102 may be the same device or different devices, without any specific limitation.

[0138] The following is based on Figure 1C Taking the transaction processing method provided in the embodiment of the present application as an example, applied to the master node cluster in the alliance chain system, the transaction processing method is introduced in detail. The relevant execution steps of the slave node cluster are introduced in the following text and will not be repeated separately.

[0139] The consortium chain system includes multiple service nodes provided by multiple node providers. Each node provider can provide a specified number of service nodes. For example, each node provider can provide four service nodes. For another example, the consortium chain system can provide service nodes specified by the corresponding node provider. For another example, the consortium chain system can provide service nodes whose third performance parameters are greater than a parameter threshold based on the third performance parameters of each service node. There are no specific limitations.

[0140] The third performance parameter may represent the processing performance of each service node for random tasks assigned by the node provider, as calculated by the node provider before providing each service node; or the processing performance of each service node for transactions within a specified period of time, starting from the node provider's statistical time, without specific limitations. The parameter threshold may represent the minimum performance requirement for a service node to be assigned tasks such as pending transactions, and may be set based on specific scenarios.

[0141] Please refer to Table 1, which shows an example of the third performance parameter of each service node. The third performance parameter represents the number of random tasks processed per second by the service node. This includes the first, second, third, and fourth node providers. Each node provider provides four service nodes.

[0142] Table 1

[0143]

[0144] Among them, the third performance parameters of the four service nodes provided by the first node provider are 10000, 8000, 3000 and 1000 respectively; the third performance parameters of the four service nodes provided by the second node provider are 10000, 7000, 5000 and 1000 respectively; the third performance parameters of the four service nodes provided by the third node provider are 10000, 7500, 2000 and 1500 respectively; the third performance parameters of the four service nodes provided by the fourth node provider are 8500, 7000, 4000 and 3000 respectively.

[0145] Based on the multiple service nodes provided by each node provider, a master node cluster can be formed. Each service node in the master node cluster comes from a different node provider, which improves decentralization and enhances the ability to resist single points of failure and abnormal behavior. The number of node providers involved in the master node cluster can be greater than the provider number threshold; it can also be the same as the total number of node providers involved in the consortium chain system, without specific restrictions. The provider number threshold can be determined proportionally based on the total number of node providers; it can also be determined proportionally based on the node data of each service node included in the consortium chain system; it can also be an empirical value, etc., without specific restrictions.

[0146] There are many ways to divide the master node cluster based on the multiple service nodes provided by each node provider. For example, when the node provider provides multiple service nodes, it carries indication information. The indication information can indicate which service nodes provided by the node provider should be divided into the master node cluster, etc.

[0147] The master node cluster is used to distribute pending transactions to the corresponding slave node clusters; it is also used to manage communications with the slave node clusters and between each slave node cluster; it is also used to maintain the overall status data of the alliance chain system, etc.

[0148] The following is an example of how two consortium chain systems select service nodes from multiple service nodes provided by each node provider to form a master node cluster.

[0149] Method 1:

[0150] If each service node is set with a node identifier, which is used to uniquely identify the corresponding service node, then based on the node identifier set by each service node, one service node is selected from the service nodes provided by each node provider in turn to form a master node cluster.

[0151] Please refer to Figure 2A , including a first node provider and a second node provider. The first node provider provides a first service node, a second service node, and a third service node; the node identifier of the first service node is 1, the node identifier of the second service node is 2, and the node identifier of the third service node is 3.

[0152] The second node provider provides a fourth service node and a fifth service node. The node identifier of the fourth service node is 4, and the node identifier of the fifth service node is 5.

[0153] From the first, second, and third service nodes provided by the first node provider, the first service node with the smallest node ID is selected as a service node in the master node cluster. From the fourth and fifth service nodes provided by the second node provider, the fourth service node with the smallest node ID is selected as a service node in the master node cluster. This is equivalent to selecting the service node with the highest node ID in the order of the nodes.

[0154] Thus, a master node cluster can be obtained, including the first service node and the fourth service node.

[0155] Method 2:

[0156] When providing each service node, the node provider may include the third performance parameter of each service node. The third performance parameter can be found in the previous section and will not be further described here. Thus, the service nodes provided by each node provider whose third performance parameters fall within the parameter range are selected in turn to form a master node cluster.

[0157] Please refer to Figure 2B, including a first node provider and a second node provider. The first node provider provides a first service node, a second service node, and a third service node; the third performance parameter of the first service node is 10, the third performance parameter of the second service node is 25, and the third performance parameter of the third service node is 33.

[0158] The second node provider provides a fourth service node and a fifth service node. The third performance parameter of the fourth service node is 24, and the third performance parameter of the fifth service node is 51.

[0159] Taking the parameter range of [22, 26] as an example, from the first service node, the second service node, and the third service node provided by the first node provider, the second service node whose third performance parameter is within the parameter range is selected as a service node in the master node cluster. From the fourth service node and the fifth service node provided by the second node provider, the fourth service node whose third performance parameter is within the parameter range is selected as a service node in the master node cluster.

[0160] Thereby, a master node cluster can be obtained, including the second service node and the fourth service node.

[0161] As an example, the structure of each service node in the master node cluster is different from that of other service nodes. Please refer to Figure 2C , which is a structural diagram of the service nodes in the master node cluster.

[0162] It includes a network module, a verification module, a transaction pool module, a scheduling module, a consensus module, and a storage module. The verification module includes a certificate verification submodule and a permission verification submodule; the transaction pool module includes a transaction forwarding submodule and a transaction storage submodule; the scheduling module includes a block generator, a slave node cluster detection submodule, a slave node cluster management submodule, a contract allocation module, and a contract repository; and the storage module includes a block ledger and a state database.

[0163] The network module is used to establish data communication between service nodes, including sending and receiving data. The network module can ensure that communication connections can be established between any two service nodes to conduct block exchange, transaction sending and receiving, and consensus strategy synchronization.

[0164] The verification module verifies the legitimacy of transactions and blocks. The certificate verification submodule verifies the identity certificates of the service node and the transaction submitter, ensuring that the transaction submitter or service node is authorized. The permission verification submodule verifies whether the transaction submitter has the authority to execute the transaction, preventing unauthorized abnormal operations.

[0165] The transaction pool module is used to store pending transactions, which are waiting to be packaged into blocks. The transaction forwarding submodule is used to forward transactions to other service nodes so that transactions can be propagated within the consortium chain system; the transaction storage submodule is used to temporarily store pending transactions.

[0166] The scheduling module manages block generation and transaction execution scheduling. The block generator packages transactions into blocks and generates new blocks. The slave node cluster detection submodule monitors the processing performance and status data of the slave node cluster to make scheduling decisions. The slave node cluster management submodule manages the service nodes in the slave node cluster, including joining and leaving service nodes and configuring the slave node cluster. The contract allocation submodule determines which smart contract to deploy to which slave node cluster. The contract repository stores the contract code and metadata of each smart contract in the consortium chain system.

[0167] The consensus module is responsible for ensuring that each service node reaches a consensus on the status data of the corresponding blockchain based on the consensus mechanism.

[0168] The storage module is used to persistently store relevant blockchain data. The block ledger is used to store blocks that have been uploaded to the blockchain; the state database is used to store the current state of the blockchain, including account balances and smart contract status data.

[0169] The following is an example of the process of obtaining a master node cluster. Please refer to Figure 2D .

[0170] In S201, each node provider uploads blockchain code to the multiple service nodes it provides. This enables the corresponding service nodes to deploy and run the consortium chain system, implement its various functions, and provide corresponding blockchain services. The blockchain code may include program code, smart contracts, or configuration files required to build the consortium chain system.

[0171] S202: Each node provider uploads a configuration file to the configuration directory of the multiple service nodes it provides. The configuration file may contain various configuration parameters and settings required for the corresponding service node to run and execute, such as network configuration, security configuration, or data storage configuration. This allows the service node to implement functions such as network data transmission, security protection of the service node and its data, or data storage. The node provider can upload the configuration file from the node provider's local computer to the configuration directory of the corresponding service node via File Transfer Protocol (FTP), Secure Copy Protocol (SCP), or other transfer protocols.

[0172] S203, each node provider starts the blockchain code in the multiple service nodes it provides, so that each service node deploys and runs the alliance chain system based on the configuration file stored in the configuration directory and the blockchain code.

[0173] S204: Determine whether each node provider has designated a service node from among the multiple service nodes it provides as a master node cluster. The node provider may include indication information in a configuration file, so that the service node can determine whether it is a service node in the master node cluster based on the configuration file. If each node provider has designated a service node as a master node cluster, S205 is executed; if each node provider has not designated a service node as a master node cluster, S206-S207 are executed.

[0174] S205 , when each node provider specifies a service node constituting a master node cluster, a master node cluster is formed based on each service node specified by each node provider.

[0175] S206: When each node provider has not designated a service node to form the master node cluster, service nodes with higher node identifiers are selected in sequence from the multiple service nodes provided by each node provider to form the master node cluster.

[0176] S207: If the master node cluster has a preset specified number of nodes, a service node is selected from the multiple service nodes provided by each node provider, and then a determination is made as to whether the selected service node has reached the specified number of nodes. If so, S209 is executed; if not, S208 to S209 are executed.

[0177] S208 , sequentially selecting service nodes with higher node identifiers from among the multiple service nodes provided by each node provider, and adding them to the master node cluster until the number of selected service nodes reaches the specified number of nodes.

[0178] S209: Each service node in the master node cluster establishes a communication connection with each other. When the number of service node pairs that have established a communication connection reaches a connection pair threshold, it is determined that each service node in the master node cluster has successfully established a communication connection, and the master node cluster can continue with subsequent transaction processing. If the connection pair threshold is not reached, the process waits for each service node in the master node cluster to establish a communication connection. If the waiting time exceeds a preset time threshold, S209 is repeated, or a prompt message is returned, prompting the user to manually establish a communication connection between the two corresponding service nodes.

[0179] Among them, the connection pair threshold can be determined proportionally according to the number of each service node. For example, two-thirds of the total number of connection pairs in which each service node establishes a communication connection is the connection pair threshold; for example, the total number of connection pairs is set as the connection pair threshold, etc., and there is no specific restriction.

[0180] Please refer to Figure 3 , which is a flow chart of the transaction processing method provided in an embodiment of the present application.

[0181] S301, obtaining each slave node cluster associated with the master node cluster, and obtaining pending transactions.

[0182] After obtaining the master node cluster, the master node cluster can obtain the slave node clusters associated with the master node cluster based on the multiple service nodes provided by each node provider, excluding the service nodes included in the master node cluster. Therefore, when the master node cluster obtains the pending transaction, the master node cluster can combine with the slave node clusters to perform the transaction processing process on the pending transaction.

[0183] The slave node cluster is used to process transactions, including executing transactions, verifying transactions, and updating the status data of the consortium chain that it records; it is also used to deploy corresponding smart contracts.

[0184] According to the actual usage scenario, if the processing performance of the service node included in the master node cluster is good, then the slave node clusters obtained by the master node cluster can also include the service node with good processing performance. In the embodiment of the present application, the service nodes included in the master node cluster and each slave node cluster do not overlap as an example for introduction.

[0185] In each slave node cluster acquired by the master node cluster, each service node in each slave node cluster comes from a different node provider, so that each slave node cluster is jointly controlled by each node provider, avoiding the situation where the slave node cluster contains many service nodes from the same node provider and is maliciously controlled by the node provider, thereby improving the data security in the alliance chain system.

[0186] Furthermore, in each slave node cluster, the error between a first performance parameter of each two service nodes is within a preset error range, where the first performance parameter represents the task processing performance of the corresponding service node in processing random computing tasks. The preset error range can be set based on empirical values ​​or determined based on the average difference between the maximum first performance parameters of each service node provided by each node provider, etc., without limitation.

[0187] Then, if the processing performance of each service node in the same slave node cluster is the same or similar, when the slave node cluster processes transactions, the processing speed of each service node in the slave node cluster is comparable, and there will be no situation where a service node with higher processing performance is idle for a long time, waiting for a service node with lower processing performance to process the transaction. This avoids the problem of the "barrel effect", and enables service nodes with various processing performances to be fully utilized, thereby improving transaction processing efficiency.

[0188] Please refer to Table 2 for an example of the master node cluster and the obtained slave node clusters.

[0189] Table 2

[0190]

[0191]

[0192] Among them, the alliance chain system includes 5 service nodes provided by the first node provider, the first node provider, the first node provider and the first node provider respectively. The preset error range is 3000. Please refer to Figure 4A , which is a schematic diagram of the master node cluster and the obtained slave node clusters.

[0193] The first performance parameters of the five service nodes provided by the first node provider are 10000, 8000, 3000, 1000 and 15000 respectively; the first performance parameters of the five service nodes provided by the second node provider are 12000, 9000, 7000, 1500 and 3500 respectively; the first performance parameters of the five service nodes provided by the third node provider are 1000, 7500, 3600, 13000 and 10000 respectively; the first performance parameters of the five service nodes provided by the fourth node provider are 8500, 4500, 11500, 3000 and 10500 respectively.

[0194] The master node cluster includes service node 2 provided by the first node provider, service node 3 provided by the second node provider, service node 2 provided by the third node provider, and service node 1 provided by the fourth node provider.

[0195] The first slave node cluster includes the service node 5 provided by the first node provider, the service node 1 provided by the second node provider, the service node 4 provided by the third node provider, and the service node 3 provided by the fourth node provider; the second slave node cluster includes the service node 1 provided by the first node provider, the service node 2 provided by the second node provider, the service node 5 provided by the third node provider, and the service node 5 provided by the fourth node provider; the third slave node cluster includes the service node 3 provided by the first node provider, the service node 5 provided by the second node provider, the service node 3 provided by the third node provider, and the service node 2 provided by the fourth node provider; the fourth slave node cluster includes the service node 4 provided by the first node provider, the service node 4 provided by the second node provider, the service node 1 provided by the third node provider, and the service node 4 provided by the fourth node provider.

[0196] As an embodiment, when the master node cluster obtains each slave node cluster, it can first determine the first performance parameters of the multiple service nodes provided by each node provider; and then, based on the obtained first performance parameters, divide the multiple service nodes provided by each node provider into each slave node cluster.

[0197] The process of obtaining each slave node cluster can be that after obtaining the master node cluster, the master node cluster pre-acquires each slave node cluster, and waits for the pending transactions to be obtained before performing the transaction processing process, so as to improve the timeliness of transaction processing; or after the master node cluster obtains the pending transactions, it first obtains each slave node cluster, and then performs transaction processing based on the slave node clusters obtained in real time, so as to improve the accuracy of resource allocation; or the master node cluster periodically obtains and updates each slave node cluster, and waits for the pending transactions to be obtained, and then performs transaction processing based on the latest slave node cluster, so as to balance the timeliness of transaction processing and the accuracy of resource allocation, etc., without specific restrictions. Among them, periodicity can be when the processing resource occupancy rate of the master node cluster is lower than the preset occupancy threshold, or it can be a period with a preset time interval, or it can be when an update instruction for updating each slave node cluster is received, etc., without specific restrictions.

[0198] There are many ways to obtain the clusters of each slave node. The following takes two of them as examples to specifically introduce the process of obtaining the clusters of each slave node.

[0199] Method 1:

[0200] The master node cluster generates random computing tasks based on the random task generation strategy. The master node cluster sends these random computing tasks to all service nodes in the consortium chain system, excluding those in the master node cluster. Each service node receives these random computing tasks and processes them. Upon completion, the service node returns the end time of the task processing to the master node cluster.

[0201] Since the master node cluster can obtain the sending time of its own random computing tasks, the end time can be used to determine the processing time of each other service node in processing the random computing tasks. The processing time can reflect the current processing performance of the corresponding other service nodes to a certain extent.

[0202] Thus, the master node cluster receives the end times returned by each other service node and, based on the received end times, determines the first performance parameters of each other service node. Based on the obtained first performance parameters and the node providers corresponding to each other service node, the master node cluster groups the other service nodes to obtain slave node clusters associated with the master node cluster. The first performance parameters can represent the real-time processing performance of the corresponding other service nodes, improving the accuracy of resource allocation when obtaining each slave node cluster.

[0203] As an embodiment, since the master node cluster contains multiple service nodes, one or more service nodes can be selected from them to generate and send random computing tasks. Each service node in the master node cluster takes turns to be selected as the master node. The master node is the service node used to generate blocks among the service nodes included in the master node cluster. Service nodes other than the master node are correspondingly used as slave nodes. The slave nodes are the service nodes used to verify blocks based on the consensus strategy among the service nodes included in the master node cluster. Therefore, the master node can generate and send random computing tasks; each slave node can generate and send random computing tasks; the master node can also generate and send random computing tasks in combination with each slave node, etc., without specific limitations.

[0204] For example, the random task generation strategy may be a random master task generation strategy, and the random computing task may include a master computing task, which is generated by the master node based on the random master task generation strategy.

[0205] After generating a main computing task, the master node sends it to each other service node. Each other service node performs task processing based on the received main computing task. Upon completion, it returns the master end time of task processing to the master node. Thus, the master node can receive the master end time returned by each other service node and, based on the received master end time, determine the first performance parameter of each other service node. This eliminates the need for all service nodes in the master node cluster to participate in the determination of each first performance parameter, improving data processing efficiency.

[0206] For another example, the random task generation strategy may be a random slave task generation strategy, and the random computing task may include a slave computing task, which is generated by a corresponding slave node based on the random slave task generation strategy.

[0207] Each slave node receives a node performance check block, which instructs the corresponding slave node to send slave computing tasks to other service nodes. The node performance check block can be generated by the master node and broadcast within the master node cluster, or it can be packaged and broadcast within the master node cluster by the node provider, without limitation.

[0208] Each slave node sends a corresponding slave computing task to each other service node based on the received node performance detection block, so that each other service node performs task processing based on the received slave computing task and returns the slave end time when the task processing is completed. Thus, each slave node can receive the slave end time returned by each other service node, and the slave node can determine the first performance parameters of each other service node based on the received slave end time. Each slave node can determine a set of first performance parameters based on the first performance parameters of each other service node determined by each slave node and a consensus strategy. Since each slave node comes from a different node provider, the first performance parameters determined by consensus among the slave nodes are more reliable, and there is no possibility of malicious control of the determined first performance parameters by a node provider, thereby improving data security.

[0209] For another example, the random master task generation strategy and the random slave task generation strategy are the same strategy, namely, the random task generation strategy. Random computing tasks include master computing tasks and slave computing tasks. The master computing task is generated by the master node based on the random task generation strategy, and the slave computing tasks are generated by the corresponding slave nodes based on the random task generation strategy.

[0210] The master node receives the master end times returned by each other service node, generates a node performance check block based on each master end time, and broadcasts this node performance check block to the master node cluster. The process by which the master node obtains each master end time can be found in the previous section and will not be repeated here.

[0211] Each slave node receives a node performance detection block respectively. Based on the received node performance detection block, the slave node sends a corresponding slave computing task to each other service node. For details, please refer to the previous introduction and will not be repeated here.

[0212] Taking the execution process of a slave node as an example, the slave node verifies the node performance check block based on the end time returned by each other service node and the consensus strategy, generating a block verification result corresponding to the slave node. The block verification result indicates whether the corresponding slave node has passed the node performance check block verification.

[0213] Each slave node returns the corresponding block verification result to the master node. Based on the obtained block verification results, the master node determines whether each slave node has passed the node performance detection block verification, and uses each master end time as the end time introduced above to determine the first performance parameters of the corresponding other service nodes.

[0214] The master node may, in the received block verification results, indicate the number of verified block verification results. If the number exceeds a result number threshold, the master node may determine that the slave node has passed the node performance test block verification. Alternatively, if the number of verified block verification results in the received block verification results equals the total number of slave nodes, the master node may determine that the slave node has passed the node performance test block verification, etc., without limitation. The result number threshold may be determined proportionally based on the total number of slave nodes, for example, two-thirds of the total number of slave nodes.

[0215] By broadcasting the node performance detection block through the master node and performing block verification based on the received node performance detection block, abnormal situations such as malicious tampering of data in the process of determining each first performance parameter are avoided, thereby improving data security.

[0216] As an embodiment, there are multiple methods for performing block verification on the node performance detection block from the slave node to generate a block verification result corresponding to the slave node. For example, each master end time is compared with the corresponding slave end time in turn. If all are the same or within the time error range, then a block verification result is generated indicating that the verification has passed; if there are any differences or there are any situations that are not within the time error range, then a block verification result is generated indicating that the verification has failed.

[0217] For another example, the slave node averages the received slave end times to obtain a slave mean time, and averages the received master end times contained in the node performance detection block to obtain a master mean time. The slave node matches the master mean time with the slave mean time. If the master mean time and the slave mean time are the same, the slave node generates a block verification result indicating that verification has passed. If the master mean time and the slave mean time are different, the slave node generates a block verification result indicating that verification has failed.

[0218] Since the time when the master node sends the master random task and the time when each slave node sends the slave random task are known, the processing time of each other service node for processing the random task can be determined based on the master mean time and the slave mean time, thereby reflecting the processing performance of each other service node. The complex process of determining the processing performance is simplified to the process of determining the master mean time and the slave mean time, thereby improving data processing efficiency.

[0219] As an embodiment, there are multiple methods for the master node cluster to determine the first performance parameters of each other service node based on the end time returned by each other service node. For example, the order of the end times is first determined, and then the difference between each two end times is determined according to the order. The preset performance parameter is used as the first performance parameter of the other service node corresponding to the first end time. Then, based on the mapping relationship between the preset time values ​​and the performance parameters, the performance parameters corresponding to the other end times are determined with reference to the first end time, thereby obtaining the first performance parameter of each other service node.

[0220] For another example, the master node cluster determines the time difference between each end time and the time when the random computing task was sent. Based on the obtained time differences, the first performance parameter of each other service node is determined. The time difference is negatively correlated with the first performance parameter. The larger the time difference, the longer it takes for the other service nodes to process the random computing task, and the smaller the corresponding first performance parameter; the smaller the time difference, the shorter it takes for the other service nodes to process the random computing task, and the larger the corresponding first performance parameter. By determining the time difference, the complex process of determining processing performance is simplified to the process of determining the main mean time and the slave mean time, thereby improving data processing efficiency.

[0221] When the end time is the main end time introduced above, the master node determines the time difference between each main end time and the sending time of the main computing task. Based on the obtained time differences, the master node determines the first performance parameters of each other service node.

[0222] As an embodiment, the master node cluster can group the other service nodes based on the first performance parameters obtained and the node providers corresponding to the other service nodes by using a circular partitioning method to obtain the slave node clusters associated with the master node cluster. Figure 4B .

[0223] S41: The master node in the master node cluster creates a node partition block. The master node cluster can then proceed with a new round of master elections to obtain the current master node and slave nodes. The node partition block instructs the processing of node grouping tasks for other service nodes.

[0224] S42, based on the obtained first performance parameters and the node providers corresponding to the other service nodes, the master node selects the other service node with the largest value of the first performance parameter from the multiple other service nodes provided by each node provider, and adds it to the first slave node cluster.

[0225] S43: If the first slave node cluster is associated with a set node quantity, which indicates the total number of other service nodes included in the first slave node cluster, the master node counts and determines whether the total number of other service nodes included in the first slave node cluster reaches the set node quantity. If the set node quantity is not reached, it indicates that the first slave node cluster does not have enough other service nodes, and S44 is executed. If the set node quantity is reached, it indicates that the first slave node cluster does have enough other service nodes, and S45 is executed.

[0226] S44, the master node selects other service nodes with the largest value of the first performance parameter from other service nodes provided by each node provider in turn, and adds them to the first slave node cluster until the total number of other service nodes included in the first slave node cluster reaches the set number of nodes, thereby obtaining a slave node cluster.

[0227] S45, the master node enters the process of obtaining the next slave node cluster. This process loops through S42 to S44, and so on, until all other service nodes provided by each node provider are added to the corresponding slave node cluster.

[0228] All service nodes that have been selected will not be selected again, so that the master node cluster and each slave node cluster contain different service nodes.

[0229] S46: The master node packages the blocks of each slave node cluster based on the created node partition block, generates and broadcasts the node partition block. Each slave node verifies the received node partition block based on the consensus strategy and returns the block verification result of the node partition block to the master node.

[0230] S47, the master node determines, based on the block verification result of the received node partition block, that each slave node has passed the node partition block verification, and obtains each slave node cluster associated with the master node cluster.

[0231] As an example, after each service node in the master node cluster successfully establishes a communication connection, the master node cluster can begin packaging blocks and uploading them to the chain. The master node cluster can generate a genesis block, which serves as the first block in the consortium chain system and the origin of the entire consortium chain. The genesis block can represent the initial state of the consortium chain system, for example, including the initial ID, initial timestamp, difficulty target, initial consensus strategy, etc. After uploading the genesis block to the chain, the master node cluster can generate the node performance test block mentioned above to obtain the performance of each slave node cluster.

[0232] In the process of the master node cluster generating the genesis block, the first round of master election tasks can be carried out in each service node included in the master node cluster, so that the master node of this round and the slave nodes associated with the master node can be obtained. The master node packages the genesis block and broadcasts the genesis block in the master node cluster. Each slave node receives the genesis block separately. Based on the consensus strategy, each slave node verifies the received genesis block and returns the block verification result to the master node. After confirming that each slave node has passed the verification of the genesis block, the master node puts the genesis block on the chain.

[0233] The following is an example of the process of obtaining each slave node cluster, please refer to Figure 4C .

[0234] S401, a master node in a master node cluster generates a main computing task based on a random task generation strategy.

[0235] The master node may be the master node of this round obtained after the master node cluster performs the second round of master election, thereby obtaining the slave nodes associated with the master node.

[0236] In step S402, the master node sends a main computing task to each other service node. Each other service node receives the main computing task sent by the master node, processes the task based on the received main computing task, and returns the main end time to the master node when the task processing is completed.

[0237] S403: The master node receives the master end time returned by each other service node.

[0238] S404: The master node packages a node performance detection block based on the received master end times.

[0239] S405: The master node broadcasts a node performance detection block in the master node cluster, and each slave node receives the node performance detection block broadcast by the master node. For each slave node, S406 to S409 are executed.

[0240] S406 , after receiving the node performance detection block, the slave node generates a slave computing task based on a random task generation strategy.

[0241] S407: The slave node sends a slave computing task to each other service node. Each other service node receives the slave computing task sent by the slave node, processes the task based on the received slave computing task, and returns the slave end time to the slave node when the task processing is completed.

[0242] S408: The slave node receives the slave end time returned by each other service node.

[0243] In step S409, the slave node determines whether the master mean time of the master end time contained in the node performance check block matches the received slave mean time of each slave end time. If so, the slave node has successfully verified the node performance check block and returns the block verification result to the master node. If not, the slave node has failed to verify the node performance check block and returns the block verification result to the master node.

[0244] S410, the master node receives the block verification results returned by each slave node.

[0245] S411, based on the verification results of each block received, the master node determines that when each slave node passes the node performance detection block verification based on the consensus strategy, and based on the end time of each master, determines the first performance parameters of each other service node respectively.

[0246] S412: The master node groups the other service nodes based on the obtained first performance parameters and the node providers corresponding to the other service nodes to obtain slave node clusters associated with the master node cluster.

[0247] Method 2:

[0248] Each node provider generates a random computing task based on a random task generation strategy, and the node provider sends the generated random computing tasks to the multiple service nodes it provides. Each service node receives the random computing task, and the service node performs task processing based on the received random computing task. When the task processing is completed, it returns the end time to the corresponding node provider. The node provider receives the end time returned by each service node, and based on the received end times, determines the first performance parameter of each service node. For details, please refer to the previous introduction and will not be repeated here. In this case, the first performance parameter may be the third performance parameter introduced above, or it may not be the third performance parameter introduced above. When providing each service node, the node provider carries the first performance parameter of each service node, so that each slave node cluster can be obtained based on each first performance parameter. For details, please refer to the previous introduction and will not be repeated here.

[0249] As an embodiment, the master node cluster is used to manage each slave node cluster and allocate smart contracts to the slave node clusters so that the smart contracts are deployed in the corresponding slave node clusters. Therefore, the master node cluster and each slave node cluster are each associated with a cluster blockchain.

[0250] Please refer to Figure 5A , including a master node cluster, a first slave node cluster, a second slave node cluster, a third slave node cluster, and a fourth slave node cluster. The master node cluster is associated with the master cluster blockchain; the first slave node cluster is associated with the first cluster blockchain; the second slave node cluster is associated with the second cluster blockchain; the third slave node cluster is associated with the third cluster blockchain; and the fourth slave node cluster is associated with the fourth cluster blockchain.

[0251] Please refer to Figure 5B , which is a structural diagram of the service node in the slave node cluster, is similar to the structure of the service node in the master node cluster. For details, please refer to the previous introduction and will not be repeated here.

[0252] The difference between the structure of the service node in the master node cluster and that of the scheduling module is that, in addition to the block generator and contract repository, it also includes a virtual machine engine that can execute transactions in batches.

[0253] As an embodiment, there are multiple methods for the master node cluster to obtain pending transactions. For example, the master node cluster obtains multiple transactions including pending transactions from the transaction pool, and the master node cluster processes each transaction in turn. When processing a pending transaction, it can be determined that the master node cluster has obtained the pending transaction.

[0254] For another example, the transaction submitter of the pending transaction sends the pending transaction to the master node cluster, so that the master node cluster obtains the pending transaction.

[0255] For another example, the transaction submitter of a pending transaction sends the pending transaction to any slave node cluster included in the consortium chain system. After receiving the pending transaction, the slave node cluster forwards the pending transaction to the master node cluster, so that the master node cluster obtains the pending transaction.

[0256] The following is an example of the process of obtaining pending transactions. Figure 5C , which is a flowchart for obtaining pending transactions when the pending transaction is a contract deployment transaction.

[0257] S501: The transaction submitter writes the source code of the smart contract on the local system and generates metadata for the source code.

[0258] S502: The transaction submitter generates transaction data based on the obtained source code and metadata.

[0259] S503: The transaction submitter signs the acquired transaction data to obtain a data signature.

[0260] S504: The transaction submitter sends a transaction request carrying transaction data and a data signature to the master node cluster, and the master node cluster receives the transaction request sent by the transaction submitter.

[0261] S505: The master node cluster authenticates the transaction request based on the data signature in the received transaction request and obtains an authentication result. The authentication result indicates whether the transaction data carried in the transaction request is abnormal data.

[0262] S506: When the master node cluster determines that the transaction data is not abnormal data based on the authentication result, it generates a contract deployment transaction based on the transaction data, that is, obtains the pending transaction.

[0263] S302: When it is determined that the transaction to be processed is a contract deployment transaction, the second performance parameter of each slave node cluster is determined based on a pre-stored cluster performance detection strategy.

[0264] After receiving a pending transaction, the master node cluster determines whether it is a contract deployment transaction, which deploys the smart contract provided by the contract deployment transaction. If the master node cluster determines that the pending transaction is a contract deployment transaction, it selects a target node cluster from among the slave node clusters to deploy the smart contract provided by the contract deployment transaction. Therefore, the master node cluster can determine the second performance parameter for each slave node cluster based on a pre-stored cluster performance testing strategy. The second performance parameter represents the overall processing performance of the service node when the corresponding slave node cluster processes the transaction. The master node cluster uses the obtained second performance parameters as a basis for selecting a target node cluster, enabling the consortium chain system to effectively utilize the computing resources provided by each service node, thereby improving transaction processing efficiency to a certain extent.

[0265] As an embodiment, there are multiple methods for determining the second performance parameters of each slave node cluster. For example, the master node cluster sends random transactions to each slave node cluster. The specific process can refer to the previous determination process for the first performance parameter. The random transaction replaces the random computing task introduced in the previous article to carry out the corresponding process, which will not be repeated here.

[0266] For example, the master node cluster can determine the corresponding second performance parameter based on the historical transaction processing performance of each slave node cluster. This simplifies the process of sending random transactions and improves transaction processing efficiency to a certain extent. At the same time, the second performance parameter is determined based on the processing performance of real transactions, making the determined second performance parameter more accurate and better reflecting the processing performance of the corresponding slave node cluster.

[0267] The master node cluster obtains node performance parameters for each service node within each slave node cluster. The node performance parameters represent the node processing performance of the corresponding service node when processing transactions. For each slave node cluster, the master node cluster determines a second performance parameter for the corresponding slave node cluster based on the weighted sum of the obtained node performance parameters for each slave node cluster.

[0268] The master node cluster can determine the corresponding node performance parameters based on the non-idle time of each service node in the slave node cluster when processing transactions. Please refer to Figure 6A , is a schematic diagram of the non-idle time of each service node in a slave node cluster when processing transactions. The non-idle time is negatively correlated with the node performance parameters.

[0269] The slave node cluster includes a service node 2 from a first node provider, a service node 2 from a second node provider, a service node 3 from a third node provider, and a service node 4 from a fourth node provider.

[0270] When a service node in the slave node cluster is selected as the master node to execute a transaction, the other service nodes in the slave node cluster act as slave nodes to perform block verification. Within a certain historical period, Service Node 2 from the first node provider, Service Node 2 from the second node provider, and Service Node 3 from the third node provider each executed the corresponding transaction as the master node.

[0271] Figure 6A In the figure, the entire rectangular box containing the white background and the gray background represents a certain historical period, and the rectangular area with the gray background indicates the non-idle period of the corresponding service node processing transactions or verifying blocks.

[0272] As an embodiment, there are multiple methods for the master node cluster to obtain the node performance parameters of each service node included in each slave node cluster. Two of them are described below as examples.

[0273] Method 1:

[0274] The master node cluster sends a performance check command to each slave node cluster. This command instructs the user to obtain the node performance parameters for each service node in the corresponding slave node cluster. Node performance parameters are measured by the duration of time the service node is in a non-idle state processing transactions, starting at the time the performance check command is sent. This non-idle time is negatively correlated with node performance parameters.

[0275] After each slave node cluster collects statistics on the node performance parameters of multiple other service nodes it provides, it returns the collected node performance parameters to the master node cluster. The master node cluster receives the multiple node performance parameters returned by each slave node cluster.

[0276] By taking the master node cluster as the active acquirer, the master node cluster can obtain the node performance parameters of multiple other service nodes provided by each slave node cluster within a preset time period, thereby obtaining the current processing performance of each other service node, making the determined second performance parameter more in line with the current situation, improving the accuracy of the second performance parameter, and improving the efficiency of transaction processing to a certain extent.

[0277] Method 2:

[0278] Taking a slave node cluster as an example, after the slave node cluster finishes processing historical transactions, it measures the transaction processing time of each of the other service nodes provided by the slave node cluster. Based on these processing times, the corresponding node performance parameters are determined. Node performance parameters are characterized by the transaction processing time of the corresponding service node processing historical transactions. Transaction processing time is negatively correlated with node performance parameters.

[0279] The slave node cluster sends the node performance parameters of each of the other service nodes included in the slave node cluster to the master node cluster. The master node cluster receives the node performance parameters sent by the slave node cluster.

[0280] By taking the slave node cluster as the active informant, the master node cluster can obtain the processing performance of other service nodes of the slave node cluster during the complete cycle of processing a historical transaction, so that the determined second performance parameter is more targeted at processing the complete cycle of a historical transaction, thereby improving the accuracy of the second performance parameter and improving the efficiency of transaction processing to a certain extent.

[0281] based on Figure 6A , please refer to Figure 6B The master node cluster can determine the corresponding node performance parameters based on the computing time ratio. For example, the computing time ratio is negatively correlated with the node performance parameters. The computing time ratio is obtained based on the ratio between the non-idle time of the corresponding other service nodes introduced above and a certain historical time.

[0282] The computing time of service node 2 from the first node provider accounts for 10%, the computing time of service node 2 from the second node provider accounts for 11%, the computing time of service node 3 from the third node provider accounts for 10%, and the computing time of service node 4 from the fourth node provider accounts for 9%.

[0283] The master node cluster determines a second performance parameter for the corresponding slave node cluster based on the weighted sum of the compute time percentages obtained for each slave node cluster. The second performance parameter is negatively correlated with the weighted sum. For example, assuming that the weights are all 0.25 and the sum of the compute time percentages is averaged, the weighted sum of the compute time percentages for this slave node cluster is 10%.

[0284] S303: Send a contract deployment transaction to the target node cluster whose second performance parameter meets the preset screening condition in each slave node cluster.

[0285] After obtaining the second performance parameters of each slave node cluster, the master node cluster can determine the target node cluster whose second performance parameters meet the preset screening conditions among the slave node clusters, and send a contract deployment transaction to the target node cluster.

[0286] After receiving the contract deployment transaction, the target node cluster deploys the corresponding smart contract based on the contract deployment transaction, so that the target node cluster can process the data processing transactions involving the smart contract and generate transaction processing results.

[0287] The sharded deployment of smart contracts is realized, and the slave node cluster only processes data processing transactions involving its own deployed smart contracts, reducing the number of service nodes involved in each data processing transaction process, thereby improving transaction processing efficiency.

[0288] Please refer to Figure 7A , including a first slave node cluster, a second slave node cluster, a third slave node cluster, and a fourth slave node cluster. The master node cluster successively receives contract deployment transactions for deploying the first contract, the second contract, the third contract, the fourth contract, the fifth contract, and the sixth contract, respectively. Based on the second performance parameters of each slave node cluster determined each time a contract deployment transaction is received, the master node cluster successively deploys the first contract on the first slave node cluster, the second and third contracts on the second slave node cluster, the fourth contract on the third slave node cluster, and the fifth and sixth contracts on the fourth slave node cluster.

[0289] As an embodiment, there are multiple methods for selecting the target node cluster whose second performance parameter satisfies the preset screening conditions among each slave node cluster. For example, the slave node cluster with the largest value of the second performance parameter among each slave node cluster is selected as the target node cluster. Thus, the corresponding smart contract can be deployed on the slave node cluster with the best processing performance at the moment. Then, if a data processing transaction involving the smart contract is received at the moment, it will be processed by the slave node cluster with the best processing performance, which can achieve the purpose of improving transaction processing efficiency to a certain extent.

[0290] For another example, if each smart contract is associated with a contract priority, the contract priority represents the number of data processing transactions involving the corresponding smart contract. This transaction number can be set based on empirical values ​​or calculated by other devices based on historical transaction processing records within a historical time period, without specific restrictions. In other words, the more data processing transactions expected to involve the smart contract, the higher the contract priority of the smart contract; the fewer data processing transactions expected to involve the smart contract, the lower the contract priority of the smart contract.

[0291] The master node cluster then sorts the slave node clusters based on the values ​​of the obtained second performance parameters, obtaining a ranking order for each slave node cluster. The master node cluster selects the slave node cluster whose ranking order matches the contract priority of the contract to be deployed provided in the contract deployment transaction as the target node cluster. The contract priority represents the number of data processing transactions involving the corresponding contract to be deployed. The master node cluster can then send the contract deployment transaction to the target node cluster.

[0292] There can be many ways to match the order of arrangement with the contract priority of the to-be-deployed contract provided by the contract deployment transaction, which are not limited here. For example, the order of arrangement of the first slave node cluster, the second slave node cluster, and the third slave node cluster is first, second, and third, respectively, and the contract priority includes the first priority, the second priority, and the third priority, among which the first priority is higher than the second priority, and the second priority is higher than the third priority.

[0293] Then, for example, the first rank of the first slave node cluster may be determined to match the first priority.

[0294] For another example, multiple priority thresholds are pre-set, and the number and value of the priority thresholds can be determined based on the number of contract priorities and the number of slave node clusters. The number of priority thresholds is positively correlated with the number of contract priorities and the number of slave node clusters; the value of the priority threshold is positively correlated with the number of contract priorities and the number of slave node clusters. Then, if the first digit of the first slave node cluster and the second digit of the second slave node cluster are greater than the first priority threshold, it can be determined that the first digit of the first slave node cluster and the second digit of the second slave node cluster both match the first priority.

[0295] based on Figure 6A and Figure 6B , please refer to Figure 7B , the second performance parameter of the corresponding slave node cluster can be determined based on the weighted sum of the proportions of each computing time corresponding to the slave node cluster, and the second performance parameter is negatively correlated with the weighted sum.

[0296] The weighted sums of the respective computing time proportions corresponding to the first slave node cluster, the second slave node cluster, the third slave node cluster, and the fourth slave node cluster are 10%, 13%, 15%, and 12%, respectively.

[0297] Then, the slave node cluster with the largest value of the second performance parameter among the first, second, third, and fourth slave node clusters is selected as the target node cluster. That is, the slave node cluster with the smallest weighted sum of its corresponding computing time proportions is selected as the target node cluster. The target node cluster is then the first slave node cluster.

[0298] The following is an example of the process of sending a contract deployment transaction to the target node cluster. Please refer to Figure 7C .

[0299] S7001: The master node cluster executes the obtained contract deployment transaction and generates a contract deployment block.

[0300] S7002, obtaining the computing time ratio of each service node included in each slave node cluster when processing transactions.

[0301] S7003: The master node cluster determines the comprehensive computing time proportion of each slave node cluster based on the average computing time proportion of each service node included in the master node cluster.

[0302] S7004: Select the slave node cluster with the smallest proportion in the comprehensive calculation as the target node cluster.

[0303] S7005: After each slave node in the master node cluster verifies the contract deployment block based on the consensus strategy, the master node and each slave node in the master node cluster send the contract deployment block to the target node cluster respectively.

[0304] S7006: Each other service node included in the target node cluster counts the number of received contract deployment blocks.

[0305] S7007: Among the other service nodes included in the target node cluster, the other service nodes whose block quantity reaches the preset block quantity threshold deploy the smart contract provided by the contract deployment block.

[0306] S7008: The other service nodes included in the target node cluster verify the smart contract deployment results based on the consensus strategy.

[0307] S7009: If verification passes, the target node cluster returns the smart contract deployment result to the master node cluster. If verification fails, the target node cluster redeploys the smart contract provided by the contract deployment block.

[0308] S7010: Based on the received smart contract deployment result, the master node cluster adds the smart contract as a cluster contract to at least one cluster contract associated with the recorded target node cluster.

[0309] As an embodiment, each slave node cluster deploys at least one cluster contract based on the processing process of the contract deployment transaction described above. Each cluster contract is a smart contract used to process data processing transactions involving the corresponding cluster contract.

[0310] After obtaining the pending transaction and determining that the pending transaction is a data processing transaction, the master node cluster can assign the data processing transaction to the slave node cluster deployed by the smart contract involved in the data processing transaction. The slave node cluster will process the data processing transaction, and there is no need for all services in the alliance chain system to participate, which improves transaction processing efficiency and avoids the "barrel effect" problem.

[0311] The master node cluster obtains at least one cluster contract deployed by each slave node cluster. The at least one cluster contract deployed by each slave node cluster can be stored in the master node cluster in a table format for the master node cluster to read, or can be stored in the master node cluster in the form of a storage address mapping for the master node cluster to obtain, etc., without specific limitation.

[0312] Based on at least one cluster contract deployed by each slave node cluster, the master node cluster determines the target node cluster in each slave node cluster that has deployed the smart contract involved in the data processing transaction. The master node cluster sends the data processing transaction to the target node cluster, causing the target node cluster to perform transaction processing based on the received data processing transaction and generate a transaction processing result.

[0313] The following is an example of the process of processing data processing transactions, please refer to Figure 7D The process of obtaining data processing transactions can refer to the previous introduction to the process of obtaining contract deployment transactions, which will not be repeated here.

[0314] S701: The transaction submitter generates a data processing transaction based on the involved smart contract, transaction processing method, transaction parameters and other data.

[0315] In step S702, the transaction submitter sends a data processing transaction to the consortium chain system. The node cluster in the consortium chain system receives the data processing transaction sent by the transaction submitter. If the node cluster receiving the data processing transaction is the master node cluster, steps S703 to S704 are executed. If the node cluster receiving the data processing transaction is the target node cluster that has deployed the smart contract involved in the data processing transaction, step S705 is executed.

[0316] S703: The master node cluster determines a target node cluster where the smart contract involved in the data processing transaction is deployed based on at least one cluster contract deployed by each slave node cluster.

[0317] S704, the master node cluster sends the data processing transaction to the target node cluster, and the transaction pool associated with the target node cluster receives the data processing transaction sent by the master node cluster.

[0318] S705 , the target node cluster obtains multiple transactions including the data processing transaction from the associated transaction pool.

[0319] S706: The target node cluster executes the multiple transactions in sequence to obtain corresponding execution results.

[0320] S707, the target node cluster determines, based on the consensus strategy, that each slave node in the target node cluster has passed the verification of the execution result of the data processing transaction, and then generates a data processing block based on the verification of the execution result of the data processing transaction.

[0321] S708: Based on the data processing block, update the block ledger associated with the target node cluster and the status data in the status database associated with the target node cluster.

[0322] S709: The target node cluster statistics the proportion of computing time of each other service node in the process of processing data processing transactions.

[0323] S710: The target node cluster sends the calculated computing time percentages of each other service node to the master node cluster, and the master node cluster receives the calculated computing time percentages sent by the target node cluster.

[0324] S711: The master node cluster updates the second performance parameter of the target node cluster based on the received computing time proportions.

[0325] Based on the same inventive concept, the embodiment of the present application provides a transaction processing device, which is applied to the master node cluster in the alliance chain system. The alliance chain system includes multiple service nodes provided by multiple node providers. Each service node in the master node cluster comes from a different node provider and can realize the functions corresponding to the aforementioned transaction processing method. Figure 8 , the device includes an acquisition module 801 and a processing module 802, wherein:

[0326] Acquisition module 801 is used to acquire slave node clusters associated with the master node cluster and to acquire pending transactions; wherein, each service node in each slave node cluster is from a different node provider, and the error between the first performance parameters of each two service nodes is within a preset error range; the first performance parameter represents the task processing performance of the corresponding service node in processing random computing tasks;

[0327] Processing module 802: When determining that the transaction to be processed is a contract deployment transaction, determine the second performance parameter of each slave node cluster based on a pre-stored cluster performance detection strategy; wherein the second performance parameter represents the comprehensive processing performance of the service node when the corresponding slave node cluster processes the transaction;

[0328] The processing module 802 is also used to send a contract deployment transaction to the target node cluster in each slave node cluster whose second performance parameter meets the preset screening conditions, so that the target node cluster deploys the corresponding smart contract based on the contract deployment transaction to process the data processing transaction involving the smart contract and generate a transaction processing result.

[0329] In a possible embodiment, the acquisition module 801 is specifically configured to:

[0330] Send random computing tasks to other service nodes in the alliance chain system, except for the service nodes included in the master node cluster, so that other service nodes can process the tasks based on the received random computing tasks and return the end time of the task processing;

[0331] Determine first performance parameters of each of the other service nodes based on the received end times returned by each of the other service nodes;

[0332] Based on the obtained first performance parameters and the node providers corresponding to the other service nodes, the other service nodes are grouped to obtain the slave node clusters associated with the master node cluster.

[0333] In one possible embodiment, the random computing task includes: a main computing task generated by a master node based on a random main task generation strategy; the master node is: a service node for generating blocks among the service nodes included in the master node cluster;

[0334] The acquisition module 801 is specifically used for:

[0335] The master node sends the main computing task to each other service node, so that each other service node performs task processing based on the received main computing task and returns the main end time when the task processing ends.

[0336] In one possible embodiment, the random computing task includes: a slave computing task generated by each slave node based on a random slave task generation strategy; the slave node is: a service node included in the master node cluster, which is used to verify the block based on the consensus strategy;

[0337] The acquisition module 801 is specifically used for:

[0338] Each slave node receives a node performance detection block respectively; wherein the node performance detection block instructs: the corresponding slave node sends a slave computing task to each other service node respectively;

[0339] Each slave node sends a corresponding slave computing task to each other service node based on the received node performance detection block, so that each other service node performs task processing based on the received slave computing task and returns the slave end time when the task processing ends.

[0340] In a possible embodiment, the processing module 802 is further configured to:

[0341] After each slave node sends a corresponding slave computing task to each other service node based on the received node performance detection block, each slave node performs the following operations: Based on the slave end time returned by each other service node, the slave node performs block verification on the node performance detection block and generates a block verification result corresponding to the slave node; wherein the block verification result indicates whether the corresponding slave node has passed the verification of the node performance detection block;

[0342] Each slave node returns the corresponding block verification result to the master node; the master node is: the service node that generates the node performance detection block among the service nodes included in the master node cluster;

[0343] Based on the obtained verification results of each block, the master node determines that when each slave node passes the node performance detection block verification, the master node uses each master end time as the end time.

[0344] In one possible embodiment, the node performance detection block includes: a main end time when each other service node finishes processing a main computing task; the main computing task is generated by the master node based on a random main task generation strategy and sent to each other service node;

[0345] The processing module 802 is specifically configured to:

[0346] The slave node averages the received slave end times to obtain the slave mean time;

[0347] The slave node averages the master end times contained in the node performance detection block to obtain the master mean time;

[0348] The slave node matches the master mean time and the slave mean time to generate the block verification result corresponding to the slave node.

[0349] In a possible embodiment, the processing module 802 is specifically configured to:

[0350] Determine the time difference between each end time and the sending time of the random computing task;

[0351] Based on the obtained time differences, a first performance parameter of each of the other service nodes is determined; wherein the time difference is negatively correlated with the first performance parameter.

[0352] In a possible embodiment, the processing module 802 is specifically configured to:

[0353] Obtaining node performance parameters of each service node contained in each slave node cluster; wherein the node performance parameters represent: the node processing performance of the corresponding service node when processing transactions;

[0354] The following operations are performed for each slave node cluster respectively to determine a second performance parameter of the slave node cluster based on the obtained weighted sum of the performance parameters of each node corresponding to the slave node cluster.

[0355] In a possible embodiment, the processing module 802 is specifically configured to:

[0356] Sending a performance test instruction to each slave node cluster; wherein the performance test instruction instructs: obtaining the node performance parameters corresponding to each service node included in the corresponding slave node cluster; the node performance parameter represents: the non-idle time period during which the corresponding service node is in a non-idle state processing transactions within a preset time period starting from the current time when the performance test instruction is sent; the non-idle time period is negatively correlated with the node performance parameter;

[0357] Receive multiple node performance parameters returned by each slave node cluster.

[0358] In a possible embodiment, the processing module 802 is specifically configured to:

[0359] For each slave node cluster, perform the following operations:

[0360] After the slave node cluster finishes processing historical transactions, the node performance parameters of each service node included in the slave node cluster are received from the slave node cluster. The node performance parameters represent: the transaction processing time of the corresponding service node processing historical transactions. The transaction processing time is negatively correlated with the node performance parameters.

[0361] In a possible embodiment, the processing module 802 is specifically configured to:

[0362] Selecting the slave node cluster with the largest value of the second performance parameter among all slave node clusters as the target node cluster; or,

[0363] Based on the values ​​of the obtained second performance parameters, the slave node clusters are sorted to obtain a ranking order for each slave node cluster. The slave node cluster whose ranking order matches the contract priority of the contract to be deployed provided by the contract deployment transaction is selected as the target node cluster. The contract priority represents the number of data processing transactions involving the corresponding contract to be deployed.

[0364] Send a contract deployment transaction to the target node cluster.

[0365] In a possible embodiment, the processing module 802 is further configured to:

[0366] After obtaining the pending transaction, if it is determined that the pending transaction is a data processing transaction, obtaining at least one cluster contract deployed by each slave node cluster;

[0367] Based on at least one cluster contract deployed in each slave node cluster, determining a target node cluster in each slave node cluster that deploys a smart contract involved in the data processing transaction;

[0368] Send a data processing transaction to the target node cluster, so that the target node cluster performs transaction processing based on the received data processing transaction and generates a transaction processing result.

[0369] Please refer to Figure 9 , is a computer device 900 provided in an embodiment of the present application, which can be, for example, Figure 1C The client 101 or server 102 in the data storage program. The current version and historical versions of the data storage program and the application software corresponding to the data storage program can be installed on a computer device 900, which includes a processor 980 and a memory 920. In some embodiments, the computer device 900 may include a display unit 940, which includes a display panel 941 for displaying a user interactive operation interface, etc.

[0370] In a possible embodiment, the display panel 941 may be configured in the form of a liquid crystal display (LCD) or an organic light-emitting diode (OLED).

[0371] The processor 980 is configured to read a computer program and then execute the method defined by the computer program. For example, the processor 980 reads a data storage program or file, thereby running the data storage program on the computer device 900 and displaying a corresponding interface on the display unit 940. The processor 980 may include one or more general-purpose processors and may also include one or more DSPs (Digital Signal Processors) to perform related operations to implement the technical solutions provided in the embodiments of the present application.

[0372] The memory 920 generally includes internal memory and external memory. The internal memory may be a random access memory (RAM), a read-only memory (ROM), and a cache (CACHE), etc. The external memory may be a hard disk, an optical disk, a USB disk, a floppy disk, or a tape drive, etc. The memory 920 is used to store computer programs and other data. The computer program includes an application corresponding to each client, etc. Other data may include data generated after the operating system or application is run, and the data includes system data (such as configuration parameters of the operating system) and user data. In the embodiment of the present application, the computer program is stored in the memory 920, and the processor 980 executes the computer program in the memory 920 to implement any of the methods discussed in the previous figure.

[0373] The display unit 940 is used to receive input digital information, character information, or contact touch operations / contactless gestures, and to generate signal input related to user settings and function control of the computer device 900. Specifically, in the embodiment of the present application, the display unit 940 may include a display panel 941. The display panel 941, such as a touch screen, can collect user touch operations on or near it (such as operations performed by the user using a finger, stylus, or any other suitable object or accessory on or on the display panel 941) and drive corresponding connected devices according to a pre-set program.

[0374] In one possible embodiment, the display panel 941 may include a touch detection device and a touch controller. The touch detection device detects the player's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller. The touch controller receives the touch information from the touch detection device, converts it into touch point coordinates, and then sends it to the processor 980. The touch controller can also receive and execute commands from the processor 980.

[0375] The display panel 941 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the display unit 940, in some embodiments, the computer device 900 may further include an input unit 930. The input unit 930 may include an image input device 931 and other input devices 932. The other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, power keys, etc.), a trackball, a mouse, a joystick, and the like.

[0376] In addition to the above, the computer device 900 may also include a power supply 990 for powering other modules, an audio circuit 960, a near-field communication module 970, and an RF circuit 910. The computer device 900 may also include one or more sensors 950, such as an accelerometer, a light sensor, a pressure sensor, etc. The audio circuit 960 specifically includes a speaker 961 and a microphone 962. For example, the computer device 900 can use the microphone 962 to collect the user's voice and perform corresponding operations.

[0377] As an embodiment, the number of the processors 980 may be one or more, and the processor 980 and the memory 920 may be coupled or relatively independently configured.

[0378] As an example, Figure 9 The processor 980 in the embodiment can be used to implement the following Figure 8 The functions of the acquisition module 801 and the processing module 802 in .

[0379] As an example, Figure 9The processor 980 in can be used to implement the corresponding functions of the server or terminal device discussed above.

[0380] Those skilled in the art will appreciate that all or part of the steps of implementing the above-mentioned method embodiments may be accomplished by a computer program. The aforementioned computer program may be stored in a computer-readable storage medium. When the computer program is executed, it executes the steps of the above-mentioned method embodiments. The aforementioned storage medium includes various media that can store program codes, such as mobile storage devices, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical disks.

[0381] Alternatively, if the above-mentioned integrated unit of the present invention is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product, for example, through a computer program product, which is stored in a storage medium and includes a computer program for enabling a computer device to execute all or part of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks or optical disks.

[0382] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A transaction processing method, characterized in that: A master node cluster is applied to a consortium chain system, wherein the consortium chain system includes multiple service nodes provided by multiple node providers, each of which is provided by a different node provider. The method includes: Obtaining slave node clusters associated with the master node cluster and obtaining pending transactions; wherein each service node in each slave node cluster is from a different node provider, and an error between a first performance parameter of each two service nodes is within a preset error range; the first performance parameter represents: task processing performance of the corresponding service node in processing random computing tasks; When it is determined that the transaction to be processed is a contract deployment transaction, second performance parameters of each of the slave node clusters are determined based on a pre-stored cluster performance detection strategy; wherein the second performance parameter represents: the comprehensive processing performance of the service node when the corresponding slave node cluster processes the transaction; The contract deployment transaction is sent to the target node cluster in each slave node cluster whose second performance parameter meets the preset screening condition, so that the target node cluster deploys the corresponding smart contract based on the contract deployment transaction to process the data processing transaction involving the smart contract and generate a transaction processing result.

2. The method according to claim 1, characterized in that The obtaining of the slave node clusters associated with the master node cluster includes: Sending random computing tasks to other service nodes in the consortium chain system, except for the service nodes included in the master node cluster, so that each other service node performs task processing based on the received random computing tasks and returns the end time when the task processing ends; Determining first performance parameters of each of the other service nodes based on the received end times returned by each of the other service nodes; Based on the obtained first performance parameters and the node providers corresponding to the other service nodes, the other service nodes are grouped to obtain slave node clusters associated with the master node cluster.

3. The method according to claim 2, characterized in that The random computing task includes: a main computing task generated by a master node based on a random main task generation strategy; the master node is: a service node for generating blocks among the service nodes included in the master node cluster; Then, the random computing tasks are sent to the service nodes in the alliance chain system except the service nodes included in the master node cluster, including: The master node sends the master computing task to each of the other service nodes, so that each of the other service nodes performs task processing based on the received master computing task and returns a master end time when the task processing ends.

4. The method according to claim 2, characterized in that The random computing task includes: a slave computing task generated by each slave node based on a random slave task generation strategy; the slave node is: a service node among the service nodes included in the master node cluster, which is used to verify the block based on the consensus strategy; Then, the random computing tasks are sent to the service nodes in the alliance chain system except the service nodes included in the master node cluster, including: Each slave node receives a node performance detection block respectively; wherein the node performance detection block instructs: the corresponding slave node to send the slave computing task to each other service node respectively; Each slave node sends a corresponding slave computing task to each other service node based on the received node performance detection block, so that each other service node performs task processing based on the received slave computing task and returns the slave end time when the task processing ends.

5. The method according to claim 4, characterized in that After each slave node sends a corresponding slave computing task to each other service node based on the received node performance detection block, the method further includes: Each slave node performs the following operations: based on the slave end time returned by each of the other service nodes, the slave node performs block verification on the node performance detection block, and generates a block verification result corresponding to the slave node; wherein the block verification result indicates whether the corresponding slave node has passed the verification of the node performance detection block; Each slave node returns a corresponding block verification result to the master node; the master node is: the service node that generates the node performance detection block among the service nodes included in the master node cluster; The master node determines, based on the obtained verification results of each block, that each slave node has passed the verification of the node performance detection block, and uses the master end time as the end time.

6. The method according to claim 5, characterized in that The node performance detection block includes: the main end time when each of the other service nodes finishes processing the main computing task; the main computing task is: generated by the master node based on the random main task generation strategy and sent to each of the other service nodes; The slave node performs block verification on the node performance detection block based on the slave end time returned by each of the other service nodes, and generates a block verification result corresponding to the slave node, including: The slave node performs averaging processing on each received slave end time to obtain a slave mean time; The slave node performs averaging processing on each master end time included in the node performance detection block to obtain a master mean time; The slave node matches the master mean time and the slave mean time to generate a block verification result corresponding to the slave node.

7. The method according to claim 2, characterized in that The determining, based on the received end times returned by the other service nodes, the first performance parameters of the other service nodes respectively, includes: Determine the time difference between each of the end times and the sending time of the random computing task; Based on the obtained time differences, a first performance parameter of each of the other service nodes is determined; wherein the time difference is negatively correlated with the first performance parameter.

8. The method according to any one of claims 1 to 7, characterized in that The determining of the second performance parameter of each slave node cluster based on a pre-stored cluster performance detection strategy includes: Obtaining node performance parameters of each service node included in each slave node cluster; wherein the node performance parameters represent: node processing performance of the corresponding service node when processing transactions; For each of the slave node clusters, the following operations are performed respectively to determine a second performance parameter of the slave node cluster based on the obtained weighted sum of the performance parameters of each node corresponding to the slave node cluster.

9. The method according to claim 8, characterized in that The obtaining of node performance parameters of each service node included in each slave node cluster includes: Sending a performance test instruction to each slave node cluster, wherein the performance test instruction instructs: obtaining a node performance parameter corresponding to each service node included in the corresponding slave node cluster; the node performance parameter represents: a non-idle time duration during which the corresponding service node is in a non-idle state for processing transactions within a preset time duration starting from the current time when the performance test instruction is sent; the non-idle time duration is negatively correlated with the node performance parameter; Receive multiple node performance parameters returned by each of the slave node clusters.

10. The method according to claim 8, characterized in that The obtaining of node performance parameters of each service node included in each slave node cluster includes: For each slave node cluster, perform the following operations: After the slave node cluster finishes processing the historical transaction, node performance parameters of each service node included in the slave node cluster are received and sent by the slave node cluster; the node performance parameters represent: the transaction processing time of the corresponding service node processing the historical transaction; the transaction processing time is negatively correlated with the node performance parameters.

11. The method according to any one of claims 1 to 7, characterized in that: The sending of the contract deployment transaction to a target node cluster whose second performance parameter satisfies a preset screening condition among the slave node clusters includes: Selecting the slave node cluster with the largest value of the second performance parameter among the slave node clusters as the target node cluster; or, Based on the values ​​of the obtained second performance parameters, the slave node clusters are sorted to obtain a ranking order for each of the slave node clusters, and a slave node cluster whose ranking order matches the contract priority of the contract to be deployed provided by the contract deployment transaction is selected as the target node cluster; wherein the contract priority represents: the number of data processing transactions involving the corresponding contract to be deployed; Send the contract deployment transaction to the target node cluster.

12. The method according to any one of claims 1 to 7, characterized in that: After obtaining the pending transactions, the following steps are further included: When it is determined that the transaction to be processed is a data processing transaction, obtaining at least one cluster contract deployed by each of the slave node clusters; Determining, based on at least one cluster contract deployed by each of the slave node clusters, a target node cluster in each of the slave node clusters that deploys the smart contract involved in the data processing transaction; The data processing transaction is sent to the target node cluster, so that the target node cluster performs transaction processing based on the received data processing transaction and generates a transaction processing result.

13. A transaction processing device, characterized in that: A master node cluster is applied to a consortium chain system, wherein the consortium chain system includes multiple service nodes provided by multiple node providers, each of which comes from a different node provider. The device includes: An acquisition module is configured to acquire slave node clusters associated with the master node cluster and to acquire pending transactions; wherein each service node in each slave node cluster is from a different node provider, and the error between a first performance parameter of each two service nodes is within a preset error range; and the first performance parameter represents the task processing performance of the corresponding service node in processing random computing tasks; A processing module: configured to, when determining that the transaction to be processed is a contract deployment transaction, determine, based on a pre-stored cluster performance detection strategy, a second performance parameter of each slave node cluster; wherein the second performance parameter represents: the comprehensive processing performance of the service node when the corresponding slave node cluster processes the transaction; The processing module is also used to: send the contract deployment transaction to the target node cluster whose second performance parameter meets the preset screening conditions in each slave node cluster, so that the target node cluster deploys the corresponding smart contract based on the contract deployment transaction to process the data processing transaction involving the smart contract and generate a transaction processing result.

14. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 12 is implemented.

15. A computer device, characterized in that: include: a memory for storing program instructions; The processor is configured to call the program instructions stored in the memory, and execute the method according to any one of claims 1 to 12 according to the obtained program instructions.

16. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method according to any one of claims 1 to 12.

Images