Block chain uplink method and device, electronic equipment and medium

Abstract

The invention provides a block chain uplink method and device, electronic equipment and a medium. The blockchain uplink method comprises the following steps: acquiring a plurality of transactions to be packaged to a target block; obtaining a read variable set and a write variable set of the transaction; based on the read variable set and the write variable set, determining pre-execution transactions without conflicts in variable read-write in the plurality of transactions; packaging the determined pre-execution transaction to a pre-execution block, and sending the pre-execution block to a slave consensus node for execution; executing the pre-execution transaction, generating a target block based on a plurality of transactions, and sending the target block to a slave consensus node; and executing transactions except the pre-executed transaction in the plurality of transactions, and chaining the target block. According to the embodiment of the invention, the waiting time of the master and slave consensus nodes during the cochain of the block chain can be shortened, and the cochain efficiency of the block chain of the alliance chain is improved. The embodiment of the invention can be applied to various scenes such as block chains, structured information processing, security technologies and the like.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain, and in particular to a blockchain on-chain method, device, electronic device and medium. Background Art

[0002] The existing alliance chain consensus network includes multiple consensus nodes. After an external node generates a transaction to be recorded on the blockchain, it must entrust a consensus node to record it on the blockchain. Generally speaking, one of the consensus nodes will be designated to package the transaction into a block, send it to other consensus nodes for consensus, and then record it on the blockchain. The consensus node that packages the block is the master consensus node, and the other consensus nodes that receive the block for consensus are slave consensus nodes.

[0003] Before the slave consensus node uploads the block sent by the master consensus node to the chain, all transactions in the block must be executed. However, each transaction in the block is dependent on each other. Therefore, only when the master consensus node completes all transactions in the block and establishes a transaction relationship dependency graph, it is sent to the slave consensus node. The slave consensus node can correctly execute the transaction according to the transaction relationship dependency graph, thereby preventing the problem of different results caused by inconsistent order when each consensus node is executed concurrently. Therefore, at this time, when the master consensus node executes the transaction in the block, the slave consensus node can only wait and cannot perform other operations. At the same time, when the slave consensus node verifies, the master consensus node can only wait and cannot perform other operations. This makes the master and slave consensus nodes of the alliance chain's blockchain wait for a long time when it is uploaded, and the efficiency of blockchain upload is greatly reduced. Summary of the invention

[0004] The disclosed embodiments provide a blockchain on-chain method, device, electronic device and medium, which can shorten the waiting time of master-slave consensus nodes when the blockchain is on-chain, and improve the blockchain on-chain efficiency of the alliance chain.

[0005] According to one aspect of the present disclosure, a blockchain on-chain method is provided for a master consensus node, the blockchain on-chain method comprising:

[0006] Get multiple transactions to be packaged into the target block;

[0007] Obtaining a read variable set and a write variable set of the transaction;

[0008] Based on the read variable set and the write variable set, determining a pre-execution transaction in the plurality of transactions that has no conflict in variable reading and writing;

[0009] Packing the determined pre-execution transaction into a pre-execution block and sending it to the slave consensus node for execution;

[0010] Execute the pre-execution transaction, and based on a plurality of the transactions, generate the target block, and send it to the slave consensus node;

[0011] Execute the transactions other than the pre-executed transactions among the multiple transactions, and put the target block on the chain.

[0012] According to one aspect of the present disclosure, a blockchain on-chain method is provided for use from a consensus node, the blockchain on-chain method comprising:

[0013] Receive a pre-execution block from the master consensus node, wherein the pre-execution block includes multiple pre-execution transactions, and the pre-execution transactions are transactions that have no conflicts in variable reading and writing among multiple transactions to be packaged into the target block;

[0014] executing a plurality of the pre-execution transactions;

[0015] Receiving the target block from the master consensus node;

[0016] Removing a plurality of the pre-executed transactions from a plurality of the transactions of the target block to obtain remaining transactions;

[0017] Execute the remaining transactions and put the target block on the chain.

[0018] According to one aspect of the present disclosure, a blockchain on-chain device is provided, which is used for a master consensus node, and the blockchain on-chain device includes:

[0019] A first acquisition unit, used to acquire multiple transactions to be packaged into a target block;

[0020] A second acquisition unit, configured to acquire a read variable set and a write variable set of the transaction;

[0021] A first determining unit, configured to determine, based on the read variable set and the write variable set, a pre-execution transaction having no conflict in variable reading and writing among the plurality of transactions;

[0022] A first sending unit, configured to package the determined pre-execution transaction into a pre-execution block, and send the pre-execution block to a slave consensus node for execution;

[0023] A second sending unit is used to execute the pre-execution transaction, and based on a plurality of the transactions, generate the target block and send it to the slave consensus node;

[0024] The first on-chain unit is used to execute the transactions other than the pre-executed transactions among the multiple transactions, and to chain the target block.

[0025] Optionally, the first determining unit is specifically configured to:

[0026] Determining a prediction conflict matrix between a plurality of the transactions based on the read variable set and the write variable set;

[0027] Based on the predicted conflict matrix, pre-execution transactions without conflicts in variable reading and writing are determined among the multiple transactions.

[0028] Optionally, the read variable set includes a first contract identifier based on which the reading is performed, and a first variable identifier; the write variable set includes a second contract identifier based on which the writing is performed, and a second variable identifier;

[0029] The first determining unit is further specifically configured to:

[0030] If the multiple transactions include a first transaction and a second transaction, the first contract identifier in the read variable set of the first transaction is the same as the second contract identifier in the write variable set of the second transaction, and the first variable identifier in the read variable set of the first transaction is the same as the second variable identifier in the write variable set of the second transaction, then the conflict value commonly associated with the first transaction and the second transaction in the prediction conflict matrix is ​​set to the first value.

[0031] Optionally, the first determining unit is further specifically configured to:

[0032] If the conflict value commonly associated with one of the transactions and any other transactions in the predicted conflict matrix is ​​not the first value, determining the transaction as a first pre-execution transaction;

[0033] If the transaction has only the read variable set, determining the transaction as a second pre-execution transaction;

[0034] The first pre-execution transaction and the second pre-execution transaction are integrated into the pre-execution transaction.

[0035] Optionally, the first determining unit is further specifically configured to:

[0036] Determining that a plurality of the transactions contain only the write variable set, or contain neither the read variable set nor the write variable set;

[0037] The transaction containing only the set of write variables is integrated into the pre-execution transaction.

[0038] Optionally, the second acquiring unit is specifically configured to:

[0039] If the transaction includes the read, obtaining the first contract identifier of the first contract on which the read is based and the first variable identifier of the first variable read, and writing the first contract identifier and the first variable identifier into the read variable set, wherein if the read does not have the determined first variable, writing the set of variables in the first contract into the read variable set;

[0040] If the transaction includes the write, obtain the second contract identifier of the second contract on which the write is based and the second variable identifier of the read second variable, and write the second contract identifier and the second variable identifier into the write variable set, wherein if the write does not have a determined second variable, write the set of variables in the second contract into the write variable set.

[0041] Optionally, the first acquiring unit is specifically configured to:

[0042] receiving the transaction from a transaction generation node;

[0043] Put the transaction into a transaction pool;

[0044] From the transaction pool, a plurality of transactions to be packaged into the target block are taken out according to a predetermined standard.

[0045] Optionally, the first acquiring unit is further specifically configured to:

[0046] Taking out the transaction with a priority mark from the transaction pool;

[0047] Determine a first difference between a maximum number of transactions that can be accommodated by the target block and the number of transactions with the priority flag;

[0048] From the remaining transactions in the transaction pool, the first transaction is taken out in the order of receiving timestamps from earliest to latest.

[0049] Optionally, the transaction includes a first signature of the transaction generation node; after receiving the transaction from the transaction generation node, the blockchain on-chain device further includes:

[0050] A first signature verification unit, used to verify the first signature;

[0051] The first authority verification unit is used to obtain the authority data of the transaction generation node and perform authority verification on the transaction based on the authority data.

[0052] Optionally, the first signature is obtained by the transaction generation node obtaining a digest of the transaction using a predetermined digest algorithm, and encrypting the digest using a private key of the transaction generation node;

[0053] The first signature verification unit is specifically used for:

[0054] Obtaining the public key of the transaction generation node;

[0055] Decrypting the first signature using the public key to obtain a decryption result;

[0056] Recalculating a digest of the transaction using the predetermined digest algorithm;

[0057] If the decryption result is consistent with the recalculated digest, it is determined that the signature verification is successful.

[0058] Optionally, the second sending unit is specifically configured to:

[0059] Determining the number of matching processes based on the number of pre-executed transactions;

[0060] Based on the second difference between the number of matching processes and the number of opened processes, adding an opened process;

[0061] The pre-execution transaction is assigned to the added start process or the start process of the completed transaction for execution.

[0062] Optionally, after executing the transaction other than the pre-executed transaction among the multiple transactions, the blockchain on-chain device further includes:

[0063] A second determining unit, configured to execute the determined transaction and determine a relationship dependency graph between the acquired transactions;

[0064] The first correction unit is used to correct the execution of the determined transaction based on the relationship dependency graph.

[0065] Optionally, the first uplink unit is specifically used for:

[0066] Receiving a consensus success message from the slave consensus node;

[0067] The target block is put on the chain, and the status information associated with the target block is recorded.

[0068] According to one aspect of the present disclosure, a blockchain on-chain device is provided, for use from a consensus node, the blockchain on-chain device comprising:

[0069] A first receiving unit is used to receive a pre-execution block from a master consensus node, wherein the pre-execution block includes a plurality of pre-execution transactions, and the pre-execution transaction is a transaction in which there is no conflict in variable reading and writing among the plurality of transactions to be packaged into a target block;

[0070] A first execution unit, configured to execute a plurality of the pre-execution transactions;

[0071] A second receiving unit, configured to receive the target block from the master consensus node;

[0072] A third acquisition unit, configured to remove the plurality of pre-executed transactions from the plurality of transactions of the target block to obtain remaining transactions;

[0073] The second execution unit is used to execute the remaining transactions and put the target block on the chain.

[0074] Optionally, after receiving the pre-execution block from the main consensus node, the blockchain on-chain device further includes:

[0075] A first allocation unit, configured to allocate a plurality of parallel verification processes to the plurality of pre-execution transactions;

[0076] The first transaction verification unit is used to verify the plurality of pre-execution transactions using the plurality of parallel verification processes.

[0077] Optionally, the pre-execution transaction has a first signature of the master consensus node;

[0078] The first transaction verification unit is specifically used for:

[0079] For one of the pre-execution transactions, verifying the first signature by using the verification process assigned to the pre-execution transaction;

[0080] The verification process assigned to the pre-execution transaction is used to obtain the permission data of the main consensus node, and the transaction is verified based on the permission data.

[0081] Optionally, the first execution unit is specifically configured to:

[0082] Sequentially taking out the pre-execution transaction from the plurality of pre-execution transactions, and if there is a completed process in the open process pool, calling the completed process to execute the pre-execution transaction;

[0083] If there is no completed process in the open process pool, add an open process to the open process pool to execute the pre-execution transaction.

[0084] Optionally, the second execution unit is specifically configured to:

[0085] Sequentially taking out the remaining transactions from the plurality of the remaining transactions, and if there is a completed process in the open process pool, calling the completed process to execute the remaining transactions;

[0086] If there is no completed process in the open process pool, add an open process to the open process pool to execute the remaining transactions.

[0087] Optionally, the second execution unit is further specifically configured to:

[0088] Performing integrity verification on the pre-executed transaction and the remaining transaction;

[0089] If the integrity verification is successful, a consensus success message is sent to the main consensus node, and the target block is put on the chain.

[0090] Optionally, the second receiving unit is specifically configured to:

[0091] Receive, from the master consensus node, a relationship dependency graph between the target block and a plurality of the transactions;

[0092] After executing the remaining transactions, the blockchain on-chain device further includes:

[0093] The second correction unit is used to correct the execution of the pre-execution transaction and the remaining transaction based on the relationship dependency graph.

[0094] According to one aspect of the present disclosure, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the blockchain on-chain method as described above when executing the computer program.

[0095] According to one aspect of the present disclosure, a computer-readable storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the blockchain on-chain method as described above is implemented.

[0096] According to one aspect of the present disclosure, a computer program product is provided, which includes a computer program, and the computer program is read and executed by a processor of a computer device, so that the computer device executes the blockchain on-chain method as described above.

[0097] In the disclosed embodiment, a pre-execution transaction is determined according to the read variable set and the write variable set of multiple transactions to be packaged into the target block. A pre-execution transaction is a transaction in which multiple transactions in the target block have no conflicts in variable reading and writing. The determined pre-execution transaction is packaged into a pre-execution block and sent to the slave consensus node for execution. This pre-execution block enables the slave consensus node to correctly execute the transaction when executing the transaction in the block at the master consensus node without receiving the transaction relationship dependency graph sent by the master consensus node. The existing transaction relationship dependency graph can only be established after the master consensus node completes the execution of all transactions in the block. Moreover, when verifying from the consensus node, the master consensus node does not need to wait only and cannot perform other operations. Therefore, since the pre-execution transaction is conflict-free in reading and writing, the execution operation of the master-slave consensus node on the pre-execution transaction can shorten the waiting time of the master-slave consensus node when the blockchain is on the chain. At the same time, after sending the pre-execution block to the slave consensus node for execution, the master consensus node executes the pre-execution transaction and generates a target block based on multiple transactions and sends it to the slave consensus node. After the master consensus node executes the pre-execution transaction, the master consensus node executes the transactions other than the pre-execution transaction in the multiple transactions and puts the target block on the chain. In this way, in the disclosed embodiment, the transactions in the pre-execution block are pre-executed in the master-slave consensus node, which can shorten the waiting time of the master-slave consensus node when the blockchain is put on the chain, and improve the blockchain on-chain efficiency of the alliance chain.

[0098] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0099] The accompanying drawings are used to provide further understanding of the technical solution of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the technical solution of the present disclosure and do not constitute a limitation on the technical solution of the present disclosure.

[0100] Figure 1 is a system architecture diagram applied to a blockchain consensus network according to an embodiment of the present disclosure;

[0101] Figure 2A-2D It is a schematic diagram of a scenario in which the blockchain uploading method according to an embodiment of the present disclosure is applied to uploading indoor temperature data to a smart home APP;

[0102] Figure 3 It is a flowchart of a method for executing blockchain on-chain by a main consensus node according to an embodiment of the present disclosure;

[0103] Figure 4 Shows Figure 3Step 310 is a flowchart of obtaining multiple transactions to be packaged into a target block;

[0104] Figure 5 Shows Figure 4 Schematic diagram of placing transactions received from transaction generation nodes into a transaction pool;

[0105] Figure 6 Shows Figure 4 Step 430 is a flowchart of taking multiple transactions of a target block from the transaction pool according to a predetermined standard;

[0106] Figure 7 Shows Figure 4 A schematic diagram of taking multiple transactions of a target block from a transaction pool according to a predetermined standard in step 430;

[0107] Figure 8 is a flowchart of a blockchain method for verifying transactions according to another embodiment of the present disclosure;

[0108] Fig. 9 Shows Figure 8 Flowchart of step 810 for verifying the first signature;

[0109] Fig.10 Shows Figure 3 A schematic diagram of a variable set structure for reading a variable set in step 320;

[0110] Fig.11 Shows Figure 3 A schematic diagram of the variable set structure of the variable set written in step 320;

[0111] Fig. 12A Shows Figure 3 A schematic diagram of a read variable set obtained by reading the determined first variable in step 320;

[0112] Fig. 12B Shows Figure 3 In step 320, the uncertain first variable is read to obtain a schematic diagram of the read variable set;

[0113] Fig.13A Shows Figure 3 In step 320, the determined second variable is written to obtain a schematic diagram of the written variable set;

[0114] Fig. 13B Shows Figure 3 In step 320, the uncertain second variable is written to obtain a schematic diagram of the written variable set;

[0115] Fig.14 Shows Figure 3Step 330 is a flowchart of determining a pre-executed transaction among multiple transactions that has no conflict in variable reading and writing;

[0116] Fig.15 Shows Fig.14 Schematic diagram of determining read variable sets and write variable sets of multiple transactions in step 1410;

[0117] Fig.16 Shows Fig.14 A schematic diagram of determining a prediction conflict matrix between multiple transactions in step 1410;

[0118] Fig.17 Shows Fig.14 Step 1420 is a flowchart of determining a pre-executed transaction among multiple transactions that has no conflict in variable reading and writing;

[0119] Fig.18 Shows Fig.17 Schematic diagram of determining a first pre-executed transaction in step 1710;

[0120] Fig.19 Shows Fig.17 A schematic diagram of integrating the first pre-execution transaction and the second pre-execution transaction into a pre-execution transaction in step 1730;

[0121] Fig. 20 Shows Fig.14 Step 1420 is a schematic diagram of integrating a transaction containing only a write variable set into a pre-executed transaction;

[0122] Fig.21 Shows Figure 3 Schematic diagram of step 340 of packaging the pre-execution transaction into the pre-execution block;

[0123] Fig. 22 Shows Figure 3 Step 350 is a flowchart of executing a pre-execution transaction;

[0124] Fig.23 Shows Figure 3 Schematic diagram of step 350 executing a pre-executed transaction according to the start process;

[0125] Fig.24 Shows Figure 3 A flowchart of correcting a determined transaction based on a relationship dependency graph after executing transactions other than pre-executed transactions among a plurality of transactions;

[0126] Fig.25 Shows Figure 3 Flowchart of putting the target block on the chain in step 360;

[0127] Fig.26It is a flowchart of a method for executing blockchain on-chain by a slave consensus node according to an embodiment of the present disclosure;

[0128] Fig. 27 Shows Fig.26 A flowchart of a method for verifying multiple pre-executed transactions on a blockchain using multiple parallel verification processes;

[0129] Fig.28 Shows Fig. 27 Step 2720 is a flowchart of verifying multiple pre-executed transactions using multiple parallel verification processes;

[0130] Fig.29 Shows Fig.26 A flowchart of executing multiple pre-executed transactions from a consensus node in step 2620;

[0131] Fig.30 Shows Fig.26 A schematic diagram of removing multiple pre-executed transactions from multiple transactions of the target block to obtain remaining transactions in step 2640;

[0132] Fig.31 Shows Fig.26 Step 2650a in the flowchart executes the remaining transactions;

[0133] Fig.32 Shows Fig.26 Flowchart of putting the target block on the chain in step 2650b;

[0134] Fig.33 Shows Fig.26 In the flowchart of correcting the pre-executed transactions and the remaining transactions based on the relationship dependency graph after executing the remaining transactions;

[0135] Figure 34A-Figure 34B is a multi-terminal interaction diagram of a detailed embodiment of the present disclosure;

[0136] Fig.35 It is a module diagram of a blockchain on-chain device located at a main consensus node according to an embodiment of the present disclosure;

[0137] Fig.36 It is a module diagram of a blockchain on-chain device located at a slave consensus node according to an embodiment of the present disclosure;

[0138] Fig.37 It is to implement the embodiment according to the present disclosure Figure 3 The terminal structure diagram of the cross-blockchain on-chain method shown;

[0139] Fig.38 It is to implement the embodiment according to the present disclosure Figure 3 The server structure diagram of the cross-blockchain on-chain method shown. DETAILED DESCRIPTION

[0140] In order to make the purpose, technical solution and advantages of the present disclosure more clear, the present disclosure is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present disclosure and are not used to limit the present disclosure.

[0141] Before further describing the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations:

[0142] Artificial intelligence: It is the theory, method, technology and application system that uses digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain target results. In other words, artificial intelligence is a comprehensive technology in computer science. It attempts to understand the essence of intelligence and produce a new intelligent machine that can respond in a similar way to human intelligence. Artificial intelligence is to study the design principles and implementation methods of various intelligent machines so that machines have the functions of perception, reasoning and decision-making. Artificial intelligence technology is a comprehensive discipline that covers a wide range of fields, including both hardware-level technology and software-level technology. The basic technologies of artificial intelligence generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, and mechatronics. Artificial intelligence software technology mainly includes computer vision technology, speech processing technology, natural language processing technology, and machine learning / deep learning. With the research and advancement of artificial intelligence technology, artificial intelligence technology has been studied and applied in many fields, such as common smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, unmanned driving, automatic driving, drones, robots, smart medical care, smart customer service, etc. I believe that with the development of technology, artificial intelligence technology will be applied in more fields and play an increasingly important role.

[0143] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Blockchain is a distributed ledger technology in the field of information technology. Since the ledger is distributed and the blocks are agreed upon, it has the characteristics of being tamper-proof, traceable, and jointly maintained. Blockchain is essentially a decentralized database. It is a string of data blocks generated by cryptographic methods. Each data block contains a batch of transaction information, which is used to verify the validity of its information (anti-counterfeiting) and associate with the previous block. Blockchain is generally divided into three types: public chain, private chain, and alliance chain. Public chain refers to the most decentralized blockchain network form. Every participant in the public chain can read the data records on the chain, participate in transactions, and compete for the right to record new blocks through consensus. Private chain refers to the least decentralized blockchain network form. The write permission of the private chain network is controlled by an organization or institution, and the data read permission is stipulated by the organization.

[0144] Peer-to-peer network: a point-to-point network. Peer-to-peer network is based on a specific type of network protocol. There is no need for a central node to maintain the network status between network nodes. Instead, each node maintains the node status of the entire network or the connection status of its adjacent nodes through broadcast interaction with adjacent nodes.

[0145] Smart Contract: A computer protocol designed to communicate, verify or execute contracts in an information-based manner. Smart contracts allow for the execution of trusted transactions without a third party, which can be witnessed and are irreversible.

[0146] Contract repository: is a data structure used to store and manage smart contracts. The contract repository contains the code, status, and metadata of all smart contracts deployed on the blockchain. The contract repository allows users to query, call, and update smart contracts, and also provides the infrastructure for blockchain nodes to execute smart contracts.

[0147] Consortium chain: It is a form of blockchain network between public chain and private chain. Consortium chain is essentially a semi-decentralized network. Consortium chain is jointly managed and maintained by multiple organizations or entities, sharing data and consensus process. Unlike public chain, the participants of consortium chain are predetermined, usually a group of organizations with established trust relationship, and need to be authorized to join the network. This ensures that the participants in the network have a certain identity authentication and trust. Therefore, consortium chain has higher performance, better privacy protection and stricter permission control than public chain.

[0148] Consensus node: refers to the node in the blockchain network that is responsible for performing consensus algorithm calculations and verifying transactions. The consensus node is part of the network, and its main task is to ensure the consistency of transactions and blocks in the network and reach consensus. The existing alliance chain consensus network includes multiple consensus nodes.

[0149] External nodes: refers to the nodes used to generate transactions to be recorded on the blockchain. After the external node generates transactions to be recorded on the blockchain, it must entrust the consensus node to record them on the blockchain. External nodes are outside the blockchain network (such as the alliance chain consensus network).

[0150] like Figure 1 As shown in the figure, the transaction generation node is an external node outside the alliance chain consensus network. The alliance chain consensus network includes multiple consensus nodes. After the transaction generation node generates a transaction to be recorded on the blockchain, it must entrust the consensus node to record it on the blockchain. Generally speaking, one of the consensus nodes will be designated to package the transaction into a block, send it to other consensus nodes for consensus, and then record it on the blockchain. The consensus node that packages the block is the master consensus node, and the other consensus nodes that receive the block for consensus are slave consensus nodes.

[0151] Before the slave consensus node uploads the block sent by the master consensus node to the chain, all transactions in the block must be executed. However, each transaction in the block is dependent on each other. Therefore, only when the master consensus node completes all transactions in the block and establishes a transaction relationship dependency graph, it is sent to the slave consensus node. The slave consensus node can correctly execute the transaction according to the transaction relationship dependency graph, thereby preventing the problem of different results caused by inconsistent order when each consensus node is executed concurrently. Therefore, at this time, when the master consensus node executes the transaction in the block, the slave consensus node can only wait and cannot perform other operations. At the same time, when the slave consensus node verifies, the master consensus node can only wait and cannot perform other operations. This makes the master and slave consensus nodes of the alliance chain's blockchain wait for a long time when it is uploaded, and the efficiency of blockchain upload is greatly reduced.

[0152] System architecture and scenario description of the application of the embodiments of the present disclosure

[0153] See also Figure 1 The blockchain network shown in FIG. 1 includes a consensus network and an external network. The consensus network refers to a network that reaches consensus on transactions to be put on the blockchain and then puts them on the blockchain. It includes a plurality of consensus nodes 110. The external network refers to a network that generates transactions to be put on the blockchain and does not put them on the blockchain. It includes a plurality of transaction generation nodes 120. The external network of the blockchain can be connected to other networks or systems outside the blockchain network. In blockchain technology, the external network is a channel for communication and interaction with the blockchain network. The consensus node 110 is a blockchain node. The transaction generation node 120 does not need to participate in the consensus on the blockchain and is mainly used to generate transactions to be put on the blockchain.

[0154] The consensus node 110 or the transaction generation node 120 may be a server in the blockchain network or a user terminal connected to the blockchain network. The specific form of the consensus node 110 and the transaction generation node 120 is not limited here. It can also be understood that Figure 1 The consensus network and external network shown can be in different network environments. For example, generally speaking, the transaction generation node 120 is deployed in an external network in the public network, while the consensus node 110 running the blockchain consensus protocol is deployed in the consensus network of the private network. The consensus node 110 and the transaction generation node 120 can interact through the routing node, and the consensus node 110 and the transaction generation node 120 can also directly transmit data without going through the routing node. It should be noted that since the consensus network is in a relatively secure private cloud, its mutual access has a consensus mechanism to ensure security, and there is no need to add additional identity management and network control. The transaction generation node 120 is in a public network and may be accessed by other uncertain network terminals. Therefore, the behavior of the transaction generation node 120 and other possible nodes accessing the consensus network needs to be strictly controlled.

[0155] The connection between the external network and the consensus network can be achieved through different protocols and technologies, such as Hypertext Transfer Protocol, Websocket Protocol, Remote Procedure Call (RPC) Protocol, etc. At the same time, since the external network of the blockchain is independent of the consensus network itself, problems in the external network will not directly affect the security and integrity of the consensus network.

[0156] The embodiments of the present disclosure can be applied in various scenarios, such as Figure 2A-2D The scene shown is where the indoor air conditioning temperature is uploaded to the blockchain in a smart home app.

[0157] The target object has installed air conditioning equipment in Room 1, Room 2 and Room 3, and the air conditioning equipment in each room is connected to the terminal 210. The terminal refers to the device on which the target object has installed the smart home APP. During the startup process, the air conditioning equipment connected to the terminal 210 sends the current air conditioning temperature to the terminal 210 at every predetermined time period or predetermined time point. The predetermined time period may be 30 seconds, 1 minute, 5 minutes, 10 minutes, etc. The predetermined time point may be 10:00, 12:00, 14:00, etc. The predetermined time period or predetermined time point may be determined according to the frequency with which the target object checks the indoor air conditioning temperature.

[0158] like Figure 2AAs shown, the air-conditioning device in the target object's room 1 detected an air-conditioning temperature of 26 degrees (i.e., degrees Celsius) at 10:00 a.m., and 10:00 a.m. is the scheduled time point for sending the current air-conditioning temperature to the terminal 210. At this time, the interface of the terminal 210 displays the information "10:00 air-conditioning temperature in room 1: 26 degrees". Therefore, when the target object wants to link the current air-conditioning temperature data to the blockchain network corresponding to the smart home APP, the target object can click the "Blockchain Mini Program" button on the current interface, and the interface of the terminal 210 becomes as follows: Figure 2B shown.

[0159] exist Figure 2B In the example, after the target object clicks the "Blockchain Mini Program" button on the current interface at 10:05, the terminal 210 displays a confirmation window on the interface for uploading the current air-conditioning temperature data. The confirmation window provides the target object with an opportunity to confirm uploading the data to ensure that the target object is aware of and confirms that the data will be uploaded to the blockchain network of the smart home software. At this time, the confirmation window on the terminal 210 interface displays "Whether to record the current air-conditioning temperature of room 1 to the blockchain." Therefore, when the target object wants to record the current air-conditioning temperature of room 1 to the blockchain, the target object can click the "Yes" button on the current interface, and the interface of terminal 210 becomes as follows. Figure 2C shown.

[0160] exist Figure 2C In the example, when the target object clicks the "Yes" button on the current interface, the terminal 210 generates an air conditioning temperature chain transaction according to the requirement of chaining the current air conditioning temperature data to the blockchain network of the smart home APP, and requests the consensus network to chain the transaction. At this time, the terminal 210 displays "Waiting for chaining..." on the current interface. After the terminal 210 completes the chaining of the transaction, the interface of the terminal 210 changes to the following Figure 2D shown.

[0161] exist Figure 2D In the embodiment, after the terminal 210 completes uploading the current air-conditioning temperature data to the chain, a prompt message "uploading completed" is displayed on the interface of the terminal 210.

[0162] General description of the disclosed embodiments

[0163] According to one embodiment of the present disclosure, a blockchain on-chain method is provided.

[0164] The blockchain on-chain method of the disclosed embodiment is generally used in scenarios that require efficient, scalable and secure blockchain systems, such as the scenario of uploading the indoor air-conditioning temperature to the blockchain in the smart home APP shown in Figure 2. The disclosed embodiment provides a solution that uses transactions in the pre-execution block to pre-execute in the master-slave consensus node, which can shorten the waiting time of the master-slave consensus node when the blockchain is on-chain, and improve the blockchain on-chain efficiency of the alliance chain. At the same time, after the master consensus node executes the pre-execution transaction, the master consensus node executes transactions other than the pre-execution transaction in multiple transactions, and chains the target block.

[0165] The blockchain on-chain method of the embodiment of the present disclosure can be executed on a server or a terminal, or can be executed partially on the server and partially on the terminal.

[0166] like Figure 3 As shown, according to one embodiment of the present disclosure, the blockchain on-chain method includes:

[0167] Step 310: Obtain multiple transactions to be packaged into the target block;

[0168] Step 320: Obtain a read variable set and a write variable set of the transaction;

[0169] Step 330: Based on the read variable set and the write variable set, determine a pre-execution transaction in the multiple transactions that has no conflict in variable reading and writing;

[0170] Step 340: Pack the determined pre-execution transaction into a pre-execution block and send it to the slave consensus node for execution;

[0171] Step 350: Execute the pre-execution transaction, and generate a target block based on multiple transactions, and send it to the slave consensus node;

[0172] Step 360: Execute transactions other than pre-executed transactions in the multiple transactions, and put the target block on the chain.

[0173] The above steps 310 to 360 are the implementation process of applying the blockchain on-chain method to the main consensus node. The following is a detailed description of steps 310 to 360.

[0174] Detailed description of step 310

[0175] In step 310, multiple transactions to be packaged into the target block are obtained.

[0176] Transactions refer to operations that need to be executed by the master-slave consensus nodes and recorded in the blockchain, such as an enterprise invoice reimbursement transaction, a smart home air conditioning temperature transaction, etc. Transactions can be used to update and modify the blockchain ledger corresponding to the master-slave consensus nodes, such as transfers, contract calls, etc.

[0177] The master consensus node is in the consensus network and is a module used to receive and execute transactions to be uploaded and recorded in the first blockchain. The first blockchain records transactions verified by the master consensus node and can be accessed by nodes other than the master consensus node. The master consensus node can be an independent device, such as a separate computer or server, or a part of an independent device, such as a virtual machine partitioned from a server. The target block refers to a data structure on the first blockchain used to record transactions sent by external nodes.

[0178] In one embodiment, Figure 4 As shown, multiple transactions to be packaged into the target block are obtained, including:

[0179] Step 410: Receive a transaction from a transaction generation node;

[0180] Step 420: Put the transaction into the transaction pool;

[0181] Step 430: Take out multiple transactions to be packaged into the target block from the transaction pool according to a predetermined standard.

[0182] In step 410, the transaction generation node is a module for generating transactions to be packaged into the target block and forwarding the transactions. The transaction generation node can be an independent device, such as a separate computer or server, or a part of an independent device, such as a virtual machine partitioned from a server.

[0183] Step 410 can be divided into an interactive process in which a transaction generation node generates a transaction, the transaction generation node sends the generated transaction to the main consensus node, and the main consensus node receives the transaction to be packaged into the target block.

[0184] In step 420, the transaction pool refers to a module in the blockchain network that is used to store transactions that are pending confirmation and have been broadcast but have not yet been packaged into blocks. In this application, the transaction pool at this time refers to a module used by the main consensus node to store transactions to be packaged into the target block. When a transaction is generated according to the needs of the target object, the transaction will be broadcast to the entire blockchain network. Other nodes will receive this transaction and add it to their respective transaction pools. Therefore, the transaction pool is equivalent to a temporary storage area for storing pending transactions. Figure 5 As shown, the transaction pool of the main consensus node has stored transactions 1, 2, 3, and 4 received from other transaction generation nodes. When the main consensus node receives transaction 5 generated by a transaction generation node, it puts the transaction into the transaction pool. At this time, the transaction pool stores transactions 1, 2, 3, 4, and 5.

[0185] In one embodiment, the location where transactions are stored in the transaction pool is random. That is, the primary consensus node can put transactions into a random location in the transaction pool. However, this placement method may affect the efficiency of taking transactions out of the transaction pool.

[0186] In another embodiment, the transactions stored in the transaction pool may be sorted according to a predetermined order. The predetermined order may be set based on the receiving timestamp of the transaction or the size of the transaction. For example, when the predetermined order is set based on the receiving timestamp of the transaction, the transactions in the transaction pool may be sorted according to the receiving timestamps when they enter the transaction pool. Therefore, transactions that enter the transaction pool earlier may be processed first to reduce the waiting time for transaction processing.

[0187] In addition, when the predetermined order is set based on the size of the transaction, the transactions in the transaction pool can be sorted according to the size of the transaction itself. Therefore, for transactions that occupy less space, they are easier to be packed into the block, which can enable the block to accommodate more transactions.

[0188] In step 430, the predetermined standard refers to a set of rules or conditions used when selecting multiple transactions to be packaged into the target block. The predetermined standard includes one of the following: the receiving timestamp of the transaction to be packaged into the target block, the priority flag of the transaction to be packaged into the target block. For example, the maximum number of transactions to be accommodated is randomly taken out from the transaction pool, and these numbers are used as the transactions to be packaged into the target block. For another example, based on the priority flag of the transaction to be packaged into the target block, the maximum number of transactions to be accommodated is taken out from the transaction pool, and these numbers are used as the transactions to be packaged into the target block. For another example, based on the receiving timestamp of the transaction to be packaged into the target block, the maximum number of transactions to be accommodated is taken out from the transaction pool in the order of the receiving timestamp from the earliest to the latest, and these numbers are used as the transactions to be packaged into the target block.

[0189] Under the above predetermined standards, if only the maximum number of transactions that can be accommodated is considered, the timeliness of transaction packaging will be affected, resulting in some transactions not being selected for a long time and not being put on the chain. If only the transaction priority flag of the transaction is considered, since some transactions do not have a transaction priority flag set, although the timeliness is guaranteed, it may result in too few transactions to be packaged into the target block each time, wasting network resources. If only the transaction reception timestamp is considered, although network resources are not wasted, some more important transactions cannot be put on the chain in time, reducing the practicality of the chain.

[0190] Therefore, in one embodiment, if Figure 6 As shown, multiple transactions to be packaged into the target block are taken out from the transaction pool according to predetermined standards, including:

[0191] Step 610: Take out the transaction with the priority mark from the transaction pool;

[0192] Step 620, determining a first difference between the maximum number of transactions that can be accommodated by the target block and the number of transactions with priority flags;

[0193] Step 630: From the remaining transactions in the transaction pool, take out the first difference transaction in the order of receiving timestamps from earliest to latest.

[0194] In step 610, the priority flag refers to a flag used to determine the importance of the transaction in the processing process. The priority flag of the transaction can be determined according to the type of the transaction. Specifically, the method of determining the priority flag of the transaction according to the type of the transaction includes: obtaining the type identifier of the transaction from the content of the transaction, determining the type of the transaction according to the type identifier; determining the priority flag of the transaction according to the type of the transaction. For example, the content of the transaction includes "electronic invoice reimbursement 0001, amount 500, and used for out-of-town accommodation; [invoice reimbursement type]", and the transaction is determined to be an invoice reimbursement type according to the type identifier "[invoice reimbursement type]".

[0195] The method of determining the priority mark of a transaction according to the transaction type includes: determining the transaction priority mark by looking up a comparison table of transaction types and priority marks.

[0196] The transaction type and priority flag comparison table lists the correspondence between transaction types and priorities, as follows

[0197] Table 1 is an example of a transaction type and priority comparison table:

[0198] Transaction Type Priority Invoice Reimbursement Type 10 Invoice Query Type 9 Invoice Type 8 Resource exchange type 7 Resource transfer type 6 Resource Statistics Type 5

[0199] Table 1

[0200] As shown in Table 1, for the invoice reimbursement type, the invoice reimbursement type has a higher demand for urgent chaining, so the priority is set to 10. Similarly, according to the different demands for urgent chaining for each transaction type, the priority of the invoice query type is set to 9, the priority of the invoice issuance type is set to 8, the priority of the resource exchange type is set to 7, the priority of the resource transfer type is set to 6, and the priority of the resource statistics type is set to 5.

[0201] For example, if the content of a transaction in the transaction pool includes "electronic invoice reimbursement 0001, amount 500, and used for out-of-town accommodation", the transaction type of the transaction is determined to be an invoice reimbursement type, and the corresponding priority is 10. For another example, if a transaction in the transaction pool is "100 first resources exchanged for 10 second resources", the transaction type of the transaction is determined to be a resource exchange type, and the corresponding priority is 7.

[0202] In step 620, a first difference between the maximum number of transactions that can be accommodated in the target block and the number of transactions with priority flags is determined.

[0203] The maximum number of transactions that the target block can accommodate refers to the total number of transactions that the target block can accommodate. The maximum number of transactions that the target block can accommodate can be flexibly adjusted according to the network status of the blockchain network and the processing capacity of the consensus node, which will not be elaborated here.

[0204] The first difference refers to the difference between the maximum number of transactions that the target block can accommodate and the number of transactions with priority marks. For example, the maximum number of transactions that the target block can accommodate is 10, and the number of transactions with priority marks in the current transaction pool is 6. At this time, the first difference between the maximum number of transactions that the target block can accommodate and the number of transactions with priority marks is 10-6=4.

[0205] In one embodiment, the first difference may represent the value of the maximum number of transactions that can be accommodated in the target block minus the number of transactions with priority marks. The first difference is a negative number or 0, indicating that the transactions with priority marks in the transaction pool are sufficient to occupy all the space of the target block. The first difference is a positive number, indicating that the transactions with priority marks in the transaction pool are insufficient to occupy all the space of the target block. For example, the maximum number of transactions that can be accommodated in the target block is 10, and the number of transactions with priority marks in the current transaction pool is 6. At this time, the first difference between the maximum number of transactions that can be accommodated in the target block and the number of transactions with priority marks is 10-6=4. Since the first difference is 4, it is necessary to obtain transactions without priority marks from the transaction pool to obtain the maximum number of transactions that can be accommodated in the target block. For another example, the maximum number of transactions that can be accommodated in the target block is 6, and the number of transactions with priority marks in the current transaction pool is 6. At this time, the first difference between the maximum number of transactions that can be accommodated in the target block and the number of transactions with priority marks is 6-6=0. Since the first difference is 0, it is not necessary to obtain transactions without priority marks from the transaction pool. For another example, the maximum number of transactions that the target block can accommodate is 5, and the number of transactions with priority marks in the current transaction pool is 6. At this time, the first difference between the maximum number of transactions that the target block can accommodate and the number of transactions with priority marks is 5-6=-1. Since the first difference is -1, there is no need to obtain transactions without priority marks from the transaction pool.

[0206] In another embodiment, the first difference may also represent the value of the number of transactions with priority marks minus the maximum number of transactions that can be accommodated in the target block. In this case, the meaning of the first difference being a negative number or 0 is the same as the meaning of the first difference being a positive number in the above embodiment, and the first difference being a positive number is the same as the meaning of the first difference being a negative number or 0 in the above embodiment, which will not be repeated here.

[0207] In step 630, the first difference transaction is taken from the remaining transactions in the transaction pool in the order of receiving timestamps from the earliest to the latest. The receiving timestamp of a transaction refers to the time recorded when the main consensus node receives the transaction from the transaction generation node.

[0208] The remaining transactions from the transaction pool are transactions without priority flags. Figure 7 As shown, the current transaction pool stores transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, transaction 7, transaction 8, transaction 9, and transaction 10. Transaction 1 to transaction 10 are 10 transactions received from the first to the last according to the receiving timestamp. Among them, transaction 4, transaction 7, transaction 9, and transaction 10 are transactions with priority marks, the priority of transaction 4 is 6, the priority of transaction 7 is 7, the priority of transaction 9 is 8, and the priority of transaction 10 is 9. Transaction 1, transaction 2, transaction 3, transaction 5, transaction 6, and transaction 8 are transactions without priority marks. When the maximum number of transactions that can be accommodated in the target block is 6, first take out transaction 4, transaction 7, transaction 9, and transaction 10 with priority marks from the current transaction pool. At this time, it is determined that the first difference between the maximum number of transactions that can be accommodated in the target block and the number of transactions with priority marks is 6-4=2. Since the transactions with priority marks in the current transaction pool are not enough to occupy all the space of the target block, two transactions are taken out from the remaining transactions 1, 2, 3, 5, 6, and 8 in the transaction pool in the order of receiving timestamps from first to last. Among them, transactions 1, 2, 3, 5, 6, and 8 are transactions received by the transaction pool on the same day. The receiving timestamp of transaction 1 is 09:00:10, the receiving timestamp of transaction 2 is 09:05:10, the receiving timestamp of transaction 3 is 09:08:10, the receiving timestamp of transaction 5 is 10:10:30, the receiving timestamp of transaction 6 is 10:25:10, and the receiving timestamp of transaction 8 is 12:10:30. At this time, the two transactions taken out in the order of receiving timestamps from first to last are transaction 1 and transaction 2. Therefore, multiple transactions to be packaged into the target block are taken out from the transaction pool according to a predetermined standard, including: transaction 1, transaction 2, transaction 4, transaction 7, transaction 9, and transaction 10.

[0209] The advantage of the embodiment of step 610-step 630 is that the transaction with the priority mark is first taken out from the transaction pool, which can meet the urgent chain-up requirements of important transactions according to the priority, thereby improving the flexibility of chain-up. Then, according to the first difference between the maximum number of transactions with the priority mark and the number of transactions with the priority mark of the target block, the first difference transaction is taken out from the remaining transactions in the transaction pool according to the receiving timestamp from the first to the last. This method of taking out transactions in combination with the priority of the transaction and the receiving timestamp can better balance the processing requirements of different transactions and improve the fairness and efficiency of chain-up of multiple transactions as a whole.

[0210] The advantage of the embodiment of step 410-step 430 is that after placing the transaction received from the transaction generation node into the transaction pool, the transaction can be verified, sorted, and managed, which facilitates other consensus nodes to process and select transactions to be packaged. Therefore, it helps to improve the efficiency of transaction chaining, reduce node waiting time, and enhance the overall performance of the blockchain network.

[0211] In one embodiment, Figure 8 As shown, the transaction includes a first signature of a transaction generation node; after receiving the transaction from the transaction generation node, the blockchain on-chain method further includes:

[0212] Step 810: Verify the first signature.

[0213] Step 820: Obtain the permission data of the transaction generation node, and perform permission verification on the transaction based on the permission data.

[0214] In step 810, the first signature refers to a signature of the transaction generated by the transaction generation node (also called the transaction initiator). In order to ensure the validity and security of the transaction, the transaction generation node needs to sign the transaction. For example, a multi-signature transaction is a transaction that requires multiple participants to sign together, which is usually used to enhance the security and credibility of the transaction. After the first signature is generated by the transaction generation node, the transaction is sent to other participants for signature. The transaction can only be verified and included in the block after the signature requirements are met.

[0215] The first signature is obtained by the transaction generation node using a predetermined digest algorithm to obtain a digest of the transaction, and encrypting the digest using the private key of the transaction generation node. The signing process includes using a predetermined digest algorithm (such as a hash algorithm) to obtain a digest of the signature subject, and then encrypting the digest using the signer's private key (or public key). The difference in signature algorithms can be reflected in the use of different predetermined digest algorithms, etc. Therefore, the transaction generation node uses a predetermined digest algorithm to obtain a digest of the transaction, and encrypts the digest using the private key of the transaction generation node to obtain the first signature.

[0216] In blockchain, in order to ensure the validity and security of transactions, transactions are signed first. The transaction generation node uses the private key to sign the transaction to prove that the transaction was initiated by it. After receiving the transaction, other participants need to verify the first signature to confirm the authenticity and integrity of the transaction.

[0217] In one embodiment, Fig. 9 As shown, the first signature is verified, including

[0218] Step 910: Obtain the public key of the transaction generation node;

[0219] Step 920: Decrypt the first signature using the public key to obtain a decryption result;

[0220] Step 930: recalculate the digest of the transaction using a predetermined digest algorithm;

[0221] Step 940: If the decryption result is consistent with the recalculated digest, it is determined that the signature verification is successful.

[0222] In step 910, the public key is a key generated and made public by the transaction generation node. The public key can be used by other consensus nodes to verify the signature generated by the transaction generation node. In the blockchain, the public key is usually used for signature verification operations to verify the validity of the transaction. The public key and private key of the transaction generation node are a pair of keys, which are related to each other. The private key is used to generate the signature, and the public key is used to verify the signature. Only the transaction generation node holding the corresponding private key can generate a valid signature and verify it through the public key.

[0223] In step 920, the consensus node that verifies the signature (in this case, the master consensus node) uses the public key to decrypt the first signature and obtains a decryption result, which is a summary value.

[0224] In step 930, the master consensus node recalculates the digest of the transaction using the same predetermined digest algorithm (e.g., hash algorithm) as the signing process.

[0225] In step 940, if the decryption result is consistent with the recalculated digest, it is determined that the signature verification is successful. If the decryption result is inconsistent with the recalculated digest, it is determined that the signature verification fails.

[0226] In step 820, the permission data of the transaction generation node is obtained, and the transaction is verified based on the permission data.

[0227] The permission data of a transaction generation node refers to data used to confirm the types of transactions that a node can generate. The permission data of a transaction generation node may include: node type, node permission identifier, etc. Verifying the permissions of a transaction based on permission data refers to verifying the transaction initiator to determine whether it has the permissions required to generate the transaction, thereby ensuring that only nodes with corresponding permissions can perform specific operations or access specific resources.

[0228] The advantage of the embodiment of step 910 to step 940 is that the first signature is verified using the public key of the transaction generating node, so that the integrity and authenticity of the transaction can be verified.

[0229] The advantage of the embodiment of step 810-step 820 is that after the first signature is successfully verified, the transaction is verified based on the permission data of the transaction generation node, which can ensure that only nodes with corresponding permissions can perform specific operations, prevent unauthorized users from performing malicious operations or tampering with data, and ensure the legality and credibility of the operation.

[0230] Detailed description of step 320

[0231] In step 320, (the main consensus node) obtains the read variable set and the write variable set of the transaction. The read variable set and the write variable set of the transaction are used to determine the access and modification of the data by the transaction.

[0232] The read variable set refers to the set of data variables that need to be read during the transaction execution. When a transaction is executed, it specifies the data variables that need to be read and obtains the latest values ​​of these variables from the blockchain.

[0233] The write variable set refers to the set of data variables that need to be modified or updated during the transaction execution. When a transaction is executed, it specifies the data variables that need to be modified and writes the new values ​​to the blockchain. The write variable set is used to record the transaction's modification operations on the data so that after the transaction is packaged into the block and confirmed, the system can update the corresponding data status.

[0234] In one embodiment, Fig.10 As shown, reading the variable set includes the first contract identifier based on which the reading is based, and the first variable identifier.

[0235] The first contract identifier refers to the identifier of the smart contract used to identify and reference the transaction when reading variable data. The first contract identifier can specify the contract to be executed by specifying the contract identifier to execute the corresponding logic and functions. The first contract identifier can be an address, hash value or other specific identification form. Depending on different blockchain platforms and development tools, the specific identification form may vary, which will not be repeated here.

[0236] The first variable identifier refers to the name or symbol used to identify a variable data. In a smart contract, the first variable identifier is used to store and manage variable data, which can be a number, string, Boolean value, etc.

[0237] In one embodiment, Fig.11 As shown, the write variable set includes the second contract identifier based on which the write is based, and the second variable identifier.

[0238] The second contract identifier refers to the identifier of the smart contract used to identify and reference the transaction when writing variable data. The second contract identifier can specify the contract to be executed by specifying the contract identifier to execute the corresponding logic and functions. The second contract identifier can be an address, hash value or other specific identification form. Depending on different blockchain platforms and development tools, the specific identification form may vary, which will not be repeated here.

[0239] The second variable identifier refers to the name or symbol used to identify a variable data. In smart contracts, the second variable identifier is used to store and manage variable data, which can be a number, string, Boolean value, etc.

[0240] In one embodiment, obtaining a read variable set and a write variable set of a transaction includes:

[0241] If the transaction includes a read, obtaining a first contract identifier of a first contract based on which the read is based, and a first variable identifier of a first variable of the read, and writing the first contract identifier and the first variable identifier into a read variable set, wherein if the read does not have a determined first variable, writing a set of variables in the first contract into the read variable set;

[0242] If the transaction includes a write, obtain the second contract identifier of the second contract on which the write is based and the second variable identifier of the second variable that was read, and write the second contract identifier and the second variable identifier into a write variable set, wherein, if the write does not have a determined second variable, write a set of variables in the second contract into the write variable set.

[0243] In one embodiment, Fig. 12A As shown, the read variable set of a transaction may include a first contract identifier based on which the reading is performed, and a corresponding first variable identifier. For example, the read variable set of transaction 1 includes a first contract identifier ( Fig. 12A The contract 1 shown), and a corresponding first variable identifier ( Fig. 12A key1 shown).

[0244] In another embodiment, Fig. 12B As shown, the read variable set of a transaction may include multiple first contract identifiers based on which the reading is based, and multiple corresponding first variable identifiers. For example, the read variable set of transaction 1 includes contract 1 and corresponding key1, contract 1 and corresponding key1, and contract 2 and corresponding key3.

[0245] In another embodiment, transaction 1 includes a first contract identifier contract 1. Since the first variable read is an uncertain variable, the set of first variables (including key1, key2, and key3) are all written into the read variable set. At this time, the read variable set of transaction 1 includes contract 1 and corresponding key1, contract 1 and corresponding key1, and contract 1 and corresponding key3.

[0246] In one embodiment, Fig.13A As shown, the write variable set of the transaction may include a second contract identifier based on which the write is made, and a corresponding second variable identifier. For example, the read variable set of transaction 2 includes a second contract identifier ( Fig.13A The contract 3 shown), and a corresponding second variable identifier ( Fig.13A key1 shown).

[0247] In another embodiment, Fig. 13B As shown, the read variable set of a transaction may include multiple second contract identifiers based on which the reading is performed, and multiple corresponding second variable identifiers. For example, the read variable set of transaction 2 includes contract 3 and corresponding key1, contract 3 and corresponding key2, and contract 3 and corresponding key3.

[0248] In another embodiment, transaction 2 includes a second contract identifier contract 1. Since the second variable written is an uncertain variable, the set of second variables (including key1, key2, key3, and key4) are all written into the read variable set. At this time, the read-write variable set of transaction 2 includes contract 1 and the corresponding key1, contract 1 and the corresponding key1, contract 1 and the corresponding key3, and contract 1 and the corresponding key4.

[0249] Each transaction corresponds to its own set of read variables and write variables. By recording the transaction's read and write operations on data, the blockchain system can verify the legitimacy of the transaction and ensure data consistency to ensure the security and credibility of the blockchain.

[0250] Detailed description of step 330

[0251] In step 330 , based on the read variable set and the write variable set, a pre-execution transaction without conflict in variable reading and writing among the multiple transactions is determined.

[0252] Transaction conflicts refer to potential resource competition or data dependencies between two or more transactions, which prevent them from being executed simultaneously or in parallel. Transaction conflicts usually occur when multiple transactions attempt to access or modify the same data item. In blockchain systems, transaction conflicts need to be resolved through some consensus algorithm or scheduling strategy to ensure the correct execution of transactions and the consistency of the system.

[0253] In one embodiment, Fig.14 As shown, based on the read variable set and the write variable set, a pre-execution transaction without conflict in variable reading and writing among multiple transactions is determined, including:

[0254] Step 1410: determining a prediction conflict matrix between multiple transactions based on the read variable set and the write variable set;

[0255] Step 1420: Based on the predicted conflict matrix, determine the pre-execution transactions among the multiple transactions that have no conflicts in variable reading and writing.

[0256] In step 1410, before determining the prediction conflict matrix between multiple transactions based on the read variable set and the write variable set, the read variable set and the write variable set of multiple transactions to be packaged into the target block are integrated to obtain the total contract variable set. Then, the prediction conflict matrix between multiple transactions is determined based on the read variable set and the write variable set in the total contract variable set.

[0257] The total set of contract variables refers to the total set of read variables and write variables that record multiple transactions to be packaged into the target block. Fig.15 As shown, the transactions to be packaged into the target block include transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, and transaction 7. The read variable set of transaction 1 includes contract 1-key1, and the write variable set includes contract 1-key2; the read variable set of transaction 2 includes contract 1-key2, and the write variable set includes contract 1-key1; the read variable set of transaction 3 includes contract 2-key1, and the write variable set is empty; the read variable set of transaction 4 is empty, and the write variable set includes contract 3-key1; the read variable set of transaction 5 includes contract 3-key1, and the write variable set includes contract 3-key2; the read variable set of transaction 6 includes contract 3-key1, and the write variable set is empty; the read variable set of transaction 7 includes contract 3-key1 and contract 3-key2, and the write variable set is empty. According to the read variable sets and write variable sets of transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, and transaction 7, respectively, the total set of contract variables 1510 is determined.

[0258] In one embodiment, based on a read variable set and a write variable set, determining a prediction conflict matrix between multiple transactions includes: if the multiple transactions include a first transaction and a second transaction, a first contract identifier in a read variable set of the first transaction is the same as a second contract identifier in a write variable set of the second transaction, and a first variable identifier in the read variable set of the first transaction is the same as a second variable identifier in a write variable set of the second transaction, then a conflict value commonly associated with the first transaction and the second transaction in the prediction conflict matrix is ​​set to a first value.

[0259] The first transaction refers to the transaction for transaction conflict judgment. The first contract identifier in the read variable set of the first transaction is the same as the first contract identifier described in the above embodiment, and the first variable identifier in the read variable set of the first transaction is the same as the first variable identifier described in the above embodiment, which will not be repeated here.

[0260] The second transaction refers to a transaction that is different from the first transaction among the multiple transactions to be packaged into the target block. The second contract identifier in the write variable set of the second transaction is the same as the second contract identifier described in the above embodiment, and the second variable identifier in the read variable set of the second transaction is the same as the second variable identifier described in the above embodiment, which will not be repeated here. Fig.15 As shown, the transactions to be packaged into the target block include transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, and transaction 7. When the first transaction is transaction 1, the second transaction is any one of transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, and transaction 7.

[0261] The prediction conflict matrix is ​​a two-dimensional matrix used to represent the conflict relationship between multiple transactions. Each element in the prediction conflict matrix can indicate whether there is a conflict between two transactions. The prediction conflict matrix can be used to analyze the dependency relationship between transactions, thereby realizing the screening and scheduling of conflict-free transactions.

[0262] The first value refers to the value of the transaction conflict between the first transaction and the second transaction. The first value can be any value set by oneself. For example, the first value is set to 1. When the first transaction and the second transaction have a transaction conflict, the conflict value associated with the first transaction and the second transaction in the prediction conflict matrix is ​​recorded as 1.

[0263] In one embodiment, Fig.15 The total set of contract variables of the transaction to be packaged into the target block is shown. Fig.16A matrix diagram of a predicted conflict matrix 1610 between multiple transactions is shown. The transactions to be packaged into the target block include transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, and transaction 7. The read variable set of transaction 1 includes contract 1-key1, and the write variable set includes contract 1-key2; the read variable set of transaction 2 includes contract 1-key2, and the write variable set includes contract 1-key1; the read variable set of transaction 3 includes contract 2-key1, and the write variable set is empty; the read variable set of transaction 4 is empty, and the write variable set includes contract 3-key1; the read variable set of transaction 5 includes contract 3-key1, and the write variable set includes contract 3-key2; the read variable set of transaction 6 includes contract 3-key1, and the write variable set is empty; the read variable set of transaction 7 includes contract 3-key1 and contract 3-key2, and the write variable set is empty. Transaction 1 to transaction 7 are respectively regarded as the first transaction, and any other transaction except itself is regarded as the second transaction. For example, the first value indicating transaction conflict is set to 1, and the second value indicating transaction non-conflict is set to 0. When the first transaction is transaction 1, the second transaction is transaction 2, contract 1 in the read variable set of transaction 1 is the same as contract 1 in the write variable set of transaction 2, and key 1 in the read variable set of transaction 1 is the same as key 1 in the write variable set of transaction 2, then the conflict value associated with transaction 1 and transaction 2 in the prediction conflict matrix is ​​set to 1. Similarly, when the first transaction is transaction 1, the second transaction is transaction 3, contract 1 in the read variable set of transaction 1 is different from contract 2 in the write variable set of transaction 3, and key 1 in the read variable set of transaction 1 is the same as key 1 in the write variable set of transaction 3, then the conflict value associated with transaction 1 and transaction 2 in the prediction conflict matrix is ​​set to 0. By analogy, any two different transactions are sequentially taken as the first transaction and the second transaction to construct the prediction conflict matrix 1610.

[0264] In step 1420, the pre-execution transaction refers to a transaction that can be pre-executed by the slave consensus node. How the slave consensus node specifically pre-executes the pre-execution transaction will be described in detail in the subsequent implementation, and will not be repeated here. The pre-execution transaction can make the slave consensus node not have to wait while the master consensus node executes the transaction in the block, but cannot perform other operations.

[0265] A non-conflicting pre-executed transaction refers to a transaction that does not conflict with other transactions in the transactions to be packaged into the target block.

[0266] In one embodiment, Fig.17 As shown, based on the predicted conflict matrix, pre-executed transactions without conflicts in variable reading and writing among multiple transactions are determined, including:

[0267] Step 1710: If the conflict value commonly associated with a transaction and any other transaction in the predicted conflict matrix is ​​not the first value, the transaction is determined as the first pre-execution transaction;

[0268] Step 1720: If the transaction only has a read variable set, the transaction is determined as a second pre-execution transaction;

[0269] Step 1730: Integrate the first pre-execution transaction and the second pre-execution transaction into a pre-execution transaction.

[0270] In step 1710, if the conflict value commonly associated with a transaction and any other transaction in the predicted conflict matrix is ​​not the first value, the transaction is determined to be a first pre-execution transaction. The first pre-execution transaction group refers to a structure for recording the first pre-execution transaction. Fig.18 As shown, the transactions to be packaged into the target block include transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, and transaction 7. The transaction conflicts between any two transactions are recorded in the prediction conflict matrix 1810. Among them, the conflict values ​​associated with transaction 3 and other transactions are not the first value. At this time, transaction 3 is determined to be the first pre-execution transaction and recorded in the first pre-execution transaction group.

[0271] In step 1720, if the transaction only has a read variable set, then whether the contract representation and variable identifier in the read variable set and the write variable set of the two transactions are the same is not considered, and the transaction with only the read variable set is determined as the second pre-execution transaction. Fig.19 As shown, transaction 3, transaction 6, and transaction 7 are all transactions that only read variable sets, so these three transactions are determined as second pre-execution transactions and recorded in the second pre-execution transaction group. The second pre-execution transaction group refers to a structure for recording second pre-execution transactions.

[0272] In step 1730, transaction consolidation refers to the process of merging or combining multiple independent transactions into a larger transaction. Because a transaction can belong to both the first pre-execution transaction and the second pre-execution transaction, before the first pre-execution transaction and the second pre-execution transaction are integrated into the pre-execution transaction, the pre-execution transaction is deduplicated to avoid duplicate pre-execution transactions and reduce the efficiency of transaction uplinking. Fig.19 As shown, the first pre-execution transaction in the first pre-execution transaction group includes transaction 3, and the second pre-execution transaction in the second pre-execution transaction group includes transaction 3, transaction 6, and transaction 7. At this time, the pre-execution transaction after integrating the first pre-execution transaction and the second pre-execution transaction includes transaction 3, transaction 6, and transaction 7.

[0273] The advantage of the embodiment of step 1710-step 1730 is that the performance and efficiency of the blockchain system can be improved through transaction integration, and the overhead of network transmission can be reduced, thereby improving the scalability of the system.

[0274] In another embodiment, determining a pre-execution transaction without conflict in variable reading and writing among multiple transactions based on the predicted conflict matrix further includes:

[0275] Determine that a plurality of transactions contain only write variable sets, or contain neither read variable sets nor write variable sets;

[0276] Combine transactions containing only write variables set into pre-execution transactions.

[0277] Fig. 20 FIG. 1 shows a schematic diagram of integrating a transaction containing a write variable set into a pre-execution transaction. Fig. 20 In the example, the transactions to be packaged into the target block include transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, and transaction 7, and each transaction only contains a write variable set or contains neither a read variable set nor a write variable set. Among them, transaction 1, transaction 2, transaction 4, and transaction 5 only contain a write variable set. Therefore, transaction 1, transaction 2, transaction 4, and transaction 5 are integrated into the pre-execution transaction.

[0278] The advantage of the embodiment of step 1410-step 1420 is that by analyzing the read variable set and the write variable set of the transaction, a prediction conflict matrix is ​​constructed, so that conflict-free pre-execution transactions are screened out before these transactions are executed. In this way, by using the screened conflict-free pre-execution transactions for parallel execution on the master node and the slave node, the waiting time of the master-slave consensus node when the blockchain is on-chain can be effectively shortened, and the blockchain on-chain efficiency of the alliance chain can be improved.

[0279] Detailed description of step 340

[0280] In step 340, the determined pre-execution transactions are packaged into pre-execution blocks and sent to the slave consensus nodes for execution.

[0281] The determination process of the pre-execution transaction has been described in detail in the above embodiment and will not be repeated here. The pre-execution block refers to a data structure used to record the pre-execution transaction on the blockchain.

[0282] Packing confirmed pre-execution transactions into pre-execution blocks refers to the process of combining a group of pre-execution transactions into a block. Fig.21 As shown, the determined pre-execution transactions include transaction 1, transaction 2, transaction 4, and transaction 5. The determined pre-execution transactions are packaged into a pre-execution block. At this time, the pre-execution block will include transaction 1, transaction 2, transaction 4, and transaction 5.

[0283] Sending to slave consensus nodes for execution means that the master consensus node broadcasts the pre-execution block to other slave consensus nodes before executing the pre-execution transaction. In other words, the master consensus node identifies conflict-free pre-execution transactions by screening the conflict-free transaction group. In this way, the slave consensus node can complete the verification and execution of the pre-execution transaction at an early stage before receiving the target block sent by the master consensus node. Therefore, by executing these pre-execution transactions in parallel between the master and slave nodes, the waiting time of the two consensus nodes can be compressed at the same time, improving the throughput and execution efficiency of the entire system.

[0284] How to execute the pre-execution transactions in the pre-execution block from the consensus node will be explained in detail in the subsequent implementation and will not be elaborated here.

[0285] The advantage of the above embodiment is that, because the pre-execution transaction is a transaction without conflict in reading and writing, the transactions in the pre-execution block are pre-executed in the master-slave consensus node, which can shorten the waiting time of the master-slave consensus node when the blockchain is on-chain, and improve the blockchain on-chain efficiency of the alliance chain. Therefore, the present invention realizes efficient collaboration between the master and slave nodes by predicting the conflict matrix and the generation and broadcasting of the pre-execution block, thereby improving the performance of the entire blockchain system.

[0286] Detailed description of step 350

[0287] In step 350, the pre-execution transaction is executed, and based on multiple transactions, a target block is generated and sent to the slave consensus node.

[0288] The specific representation of the pre-execution transaction, the target block and the slave formula node has been described in the above embodiment, and will not be repeated here. How the slave consensus node specifically executes multiple transactions in the target block will be described in detail in subsequent implementations, and will not be repeated here.

[0289] In one embodiment, Fig. 22 As shown, the pre-execution transaction is executed, including:

[0290] Step 2210: Determine the number of matching processes based on the number of pre-executed transactions;

[0291] Step 2220: based on the second difference between the number of matching processes and the number of enabled processes, add an enabled process;

[0292] Step 2230: Allocate the pre-execution transaction to the added start process or the start process of the completed transaction for execution.

[0293] In step 2210, a process refers to a computing node or participant participating in a blockchain network. Each process can perform some specific tasks, such as verifying transactions, packaging blocks, consensus algorithms, etc., and communicate with other processes to maintain the consistency and security of the network.

[0294] The number of matching processes refers to the number of processes used to execute pre-execution transactions. If the number of pre-execution transactions is small, that is, the load in the blockchain network is low, the main consensus node can choose a smaller number of matching processes. If the number of pre-execution transactions is large, that is, the load in the blockchain network is high, the main consensus node may need to increase the number of matching processes to improve the processing capacity of the system. For example, when the number of pre-execution transactions is 20, the number of matching processes is determined to be 10. For another example, when the number of pre-execution data is 20, in order to increase the execution speed of pre-execution transactions, the number of matching processes can be determined to be 20.

[0295] The process that executes the transaction is stored in the blockchain network process pool. The process pool is a resource pool used to manage multiple processes. It is responsible for creating, maintaining, scheduling, and recycling processes. The process pool can improve the concurrent performance of the system because it allows multiple tasks to be executed simultaneously in different processes. In the blockchain system, the process pool can be used to handle concurrent transaction requests and improve the efficiency of contract execution, thereby achieving efficient use of contract execution resources.

[0296] In step 2220, the number of open processes refers to the number of processes that have been started in the current blockchain network. The second difference refers to the difference between the number of matching processes and the number of open processes. The second difference is a negative number (such as -1, -2, etc.) or 0, indicating that the currently opened process can meet the process requirements for the execution of the pre-execution transaction. The second difference is a positive number (such as 1, 2, etc.), indicating that the currently opened process is not enough to meet the process requirements for the execution of the pre-execution transaction. At this time, it is necessary to increase the open process to meet the process requirements for the execution of the pre-execution transaction.

[0297] In step 2230, the pre-execution transaction is assigned to the added start process or the start process of the completed transaction for execution. That is, when there are transactions being executed in the start process, the pre-execution transaction is assigned to the added start process. When the transaction to be executed in an start process has been completed, the pre-execution transaction is assigned to the start process of the completed transaction for execution. For example, Fig.23As shown, the pre-execution transactions recorded in the pre-execution block include transaction 1, transaction 2, transaction 4, and transaction 5. At this time, the number of pre-execution transactions is 4. In order to improve the execution speed of pre-execution transactions in the blockchain network, the number of matching processes can be determined to be 4, so that a corresponding start process is assigned to each pre-execution transaction. The current start process includes start process 1, start process 2, and start process 3. At this time, the number of start processes is 3, and the second difference between the number of matching processes and the number of start processes is 4-3=1. Therefore, the currently started process is not enough to meet the process requirements for the execution of pre-execution transactions. In other words, the main consensus node needs to start adding a new start process from the process pool to meet the process requirements for the execution of pre-execution transactions. At this time, the start process includes start process 1, start process 2, start process 3, and the added start process 4. Next, assign transaction 1 to start process 1 for execution, assign transaction 2 to start process 2 for execution, assign transaction 3 to start process 3 for execution, and assign transaction 4 to start process 4 for execution. For another example, when assigning a process to transaction 4, process 1 has already completed transaction 1. In this case, transaction 4 can be assigned to process 1 that has completed the transaction for execution.

[0298] In one embodiment, when the pre-execution transaction is successfully executed in the corresponding start process, the corresponding start process will return the execution success information to the main consensus node and record the execution result in the pre-execution block.

[0299] In another embodiment, when a pre-execution transaction fails to execute in a corresponding start process, the corresponding start process returns execution failure information to the main consensus node and records the execution result in the pre-execution block.

[0300] The multiple transactions received from the transaction generation node are packaged to generate a target block, and the target block is sent to other slave consensus nodes through broadcasting.

[0301] The advantage of the embodiment of step 2210-step 2230 is that the pre-execution transaction is assigned to the added start process or the start process of the completed transaction for execution, which can optimize the process allocation process of the blockchain network for the pre-execution transaction, and also improve the scalability and resource utilization of the blockchain network.

[0302] Detailed description of step 360

[0303] In step 360, transactions other than the pre-executed transactions in the multiple transactions are executed, and the target block is put on the chain.

[0304] Reference Fig.24 , step 360 can be specifically divided into step 360a of executing transactions other than pre-executed transactions in multiple transactions, and step 360b of putting the target block on the chain.

[0305] In step 360a, the transaction executed at this time refers to the remaining transactions after removing the pre-execution transactions from the multiple transactions to be packaged into the target block. After all the pre-execution transactions in the pre-execution block are executed, the transaction scheduler of the blockchain main consensus node begins to schedule transactions that may conflict in parallel. For example, the transactions to be packaged into the target block include transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, transaction 6, and transaction 7. Based on the read variable set and write variable set of the transaction, it is determined that the pre-execution transactions in the multiple transactions that have no conflicts in variable reading and writing include transaction 1, transaction 2, transaction 4, and transaction 5. At this time, the transactions other than the pre-execution transactions in the multiple transactions include transaction 3, transaction 6, and transaction 7.

[0306] In one embodiment, continue to refer to Figure 4 , after executing transactions other than the pre-executed transactions in the multiple transactions, the blockchain on-chain method further includes:

[0307] Step 2410: Execute the determined transaction and determine the relationship dependency graph between the acquired transactions;

[0308] Step 2420: Based on the relationship dependency graph, correct the execution of the determined transaction.

[0309] In step 2410, the determined transaction is the transaction other than the pre-executed transaction in the multiple transactions in the above embodiment, which has been explained in the above embodiment and will not be repeated here.

[0310] The relationship dependency graph between transactions refers to a data structure used to represent the dependency relationship between transactions. The relationship dependency graph is represented in the form of a directed acyclic graph (DAG). In the relationship dependency graph between transactions, each transaction is represented as a node, and if a transaction depends on another transaction, there will be a directed edge connecting the two nodes. At this time, because there is a clear dependency relationship between transactions, the relationship between transactions is directed, and each node depends on one or more previous nodes, thus forming a directed acyclic graph structure. The relationship dependency graph between transactions can ensure that transactions are processed in the correct order, thereby maintaining the consistency and reliability of the entire blockchain network. The information that can be displayed in the relationship dependency graph includes: connection information between transactions (the relationship dependency graph represents the connection relationship between transactions in the blockchain network and can display the communication path between transactions), transaction and block propagation path information (the relationship dependency graph can display the propagation path of transactions and blocks in the network, and display the routing information of transactions and blocks from one node to another), dependency information (the relationship dependency graph can display the dependency relationship between nodes, such as whether a node depends on the verification or authorization of other nodes), etc.

[0311] In step 2420, after all pre-execution transactions in the pre-execution block are executed, the transaction scheduler of the blockchain main consensus node begins to schedule transactions that may conflict for parallel execution. If a conflict occurs, re-execution may be required. Therefore, it is necessary to correct the execution of the determined transaction based on the relationship dependency graph.

[0312] The advantage of the embodiment of step 2410-step 2420 is that the relationship dependency graph can better understand and analyze the interactions and dependencies between the various participants in the blockchain network, which helps to reveal the characteristics of the network structure, performance, and security. This is of great significance for designing and optimizing blockchain networks, as well as conducting network analysis and attack detection.

[0313] In step 360b, adding the target block to the chain refers to the process of adding a newly generated block to the blockchain network. In the main consensus node, the first blockchain is linked to the previous block through mechanisms such as consensus algorithms and cryptographic hash algorithms to form an unalterable chain structure. The target block contains a batch of transaction records, and adding the target block to the chain means adding this newly generated block to the existing first blockchain to make it part of the first blockchain.

[0314] In one embodiment, Fig.25 As shown, putting the target block on the chain includes:

[0315] Step 2510: Receive a consensus success message from the slave consensus node;

[0316] Step 2520: put the target block on the chain and record the status information associated with the target block.

[0317] In step 2510, after the master consensus node sends the generated target block to other slave consensus nodes, it waits for the slave consensus nodes to reach a consensus result on the transactions in the target block. The consensus result includes a consensus success message and a consensus failure message.

[0318] The consensus success message refers to the prompt information that the transaction in the target block is successfully added from the consensus node to the second blockchain of the slave consensus node. In the blockchain network, when a new block is successfully added to the blockchain, other nodes in the network will receive a consensus success message.

[0319] A consensus failure message is a prompt message from a consensus node that a transaction in a target block has not been successfully added to the secondary blockchain of a slave consensus node. In a blockchain network, when a master consensus node receives a consensus failure message, it may re-verify the transaction that failed to reach consensus, trying to find out the cause of the consensus failure. This may involve re-executing the transaction verification process to confirm whether the transaction is really invalid or whether there are other problems. At the same time, after a slave consensus node fails to reach consensus on a transaction, it will forward the consensus failure transaction information to other nodes in the network so that other nodes can also know the status of the transaction. This helps maintain the consistency and reliability of the network.

[0320] In step 2520, after the master consensus node receives the consensus success message sent by the slave consensus node, the master consensus node appends the target block to the corresponding block ledger and updates the data in the block to the status information. The block ledger is used to store confirmed blocks, thereby recording the historical information of the entire blockchain. The block ledger provides an unalterable data storage for the entire system.

[0321] The state information associated with the target block refers to the state-related information contained in each block in the blockchain. This state information can be various data in the blockchain network, including account balance status, contract status, multi-signature transaction status, etc.

[0322] The advantage of the embodiment of step 2510-step 2520 is that putting the target block on the chain and recording relevant status information can ensure the reliability, transparency and immutability of the data, while providing traceability of the status and maintaining the consistency of the network.

[0323] The overall description of the embodiment of the present disclosure from the consensus node

[0324] Slave consensus nodes are in the consensus network and serve as auxiliary nodes to the main consensus nodes. They participate in the consensus process but do not have direct decision-making power and privileges. Slave consensus nodes are used to receive transactions sent by the main consensus node to be uploaded to the chain and record them in a module of the second blockchain. The second blockchain records transactions verified by the slave consensus node and can be accessed by nodes other than the slave consensus node. The slave consensus node can be an independent device, such as a separate computer or server, or it can be part of an independent device, such as a virtual machine partitioned from a server. The main task of the slave consensus node is to verify the blocks and transactions generated by the main consensus node and ensure the consistency and security of the network. The number of slave consensus nodes is usually large, and they can disperse the verification and decision-making power of the network and improve the degree of decentralization of the network.

[0325] like Fig.26 As shown, according to one embodiment of the present disclosure, the blockchain on-chain method includes:

[0326] Step 2610: Receive a pre-execution block from the main consensus node, where the pre-execution block includes multiple pre-execution transactions, where the pre-execution transaction is a transaction that has no conflicts in variable reading and writing among multiple transactions to be packaged into the target block;

[0327] Step 2620: Execute multiple pre-execution transactions;

[0328] Step 2630: Receive the target block from the main consensus node;

[0329] Step 2640: remove multiple pre-executed transactions from multiple transactions of the target block to obtain remaining transactions;

[0330] Step 2650: Execute the remaining transactions and put the target block on the chain.

[0331] The above steps 2610 to 2650 are the implementation process of the blockchain on-chain method applied to the slave consensus node. The following is a detailed description of steps 2610 to 2650.

[0332] In step 2610, the pre-execution block broadcasted by the master consensus node is received from the master consensus node. Therefore, since the pre-execution transaction is a transaction without conflict in reading and writing, the transaction in the pre-execution block is pre-executed in the master-slave consensus node, which can shorten the waiting time of the master-slave consensus node when the blockchain is on-chain, and improve the blockchain on-chain efficiency of the alliance chain. The pre-execution block and pre-execution transaction have been described in detail in the above embodiment, and will not be repeated here to save space.

[0333] In one embodiment, Fig. 27 As shown, after receiving the pre-execution block from the main consensus node, the blockchain on-chain method also includes:

[0334] Step 2710: Allocate multiple parallel verification processes for multiple pre-execution transactions;

[0335] Step 2720: Verify multiple pre-execution transactions using multiple parallel verification processes.

[0336] In step 2710, before executing the pre-execution transaction from the consensus node, each pre-execution transaction needs to be verified to confirm the authenticity and integrity of the transaction.

[0337] The verification process refers to the process used to verify the authenticity and integrity of pre-execution transactions. Assigning multiple parallel verification processes to multiple pre-execution transactions means that in the blockchain network, the verification process of multiple pre-execution transactions can be carried out at the same time, and the verification of these transactions can be performed in parallel to improve the verification efficiency of transactions.

[0338] In step 2720, multiple pre-execution transactions may be verified simultaneously using multiple parallel verification processes. Each verification process may independently verify the validity of the pre-execution transaction and feed back the result to the master consensus node or other consensus nodes in the network after the verification is completed.

[0339] In one embodiment, Fig.28 As shown, the pre-execution transaction has the first signature of the main consensus node, and multiple parallel verification processes are used to verify multiple pre-execution transactions, including:

[0340] Step 2810: for a pre-execution transaction, verify the first signature using the verification process assigned to the pre-execution transaction;

[0341] Step 2820: Utilize the verification process assigned to the pre-execution transaction to obtain the permission data of the main consensus node, and perform permission verification on the transaction based on the permission data.

[0342] In step 2810, in order to ensure the validity and security of the transaction, the transaction is first signed. The first signature has been specifically described in the embodiment of step 810 above, and will not be repeated here.

[0343] The process of verifying the first signature using the verification process assigned to the pre-execution transaction includes: obtaining the public key of the transaction generation node; decrypting the first signature using the public key to obtain the decryption result; recalculating the summary of the transaction using a predetermined summary algorithm; if the decryption result is consistent with the recalculated summary, it is determined that the verification is successful. Therefore, the process of verifying the first signature is the same as steps 910 to 940 of the above embodiment, except that the verification process assigned to the pre-execution transaction by the slave consensus node is used here, and steps 910 to 940 are the verification processes assigned to the transaction by the master consensus node, which will not be repeated here.

[0344] In step 2820, the permission data of the master consensus node refers to data used to confirm the types of transactions that the master consensus node can upload to the chain. The permission data of the master consensus node may include: node type, node permission identifier, etc. Verifying the transaction based on the permission data refers to verifying the transaction initiator to determine whether it has the permission required to generate the transaction, thereby ensuring that only nodes with corresponding permissions can perform specific operations or access specific resources.

[0345] The advantage of the embodiment of step 2810-step 2820 is that the integrity and authenticity of the transaction can be verified by verifying the first signature using the public key of the transaction generation node. After the first signature is successfully verified, the transaction is verified based on the permission data of the main consensus node to ensure that only nodes with corresponding permissions can perform specific operations, prevent unauthorized users from performing malicious operations or tampering with data, and ensure the legitimacy and credibility of the operation.

[0346] In step 2620, multiple pre-execution transactions are executed (from the consensus node). The pre-execution transactions have been described in detail in the above embodiments, and will not be repeated here to save space.

[0347] In one embodiment, Fig.29 As shown, multiple pre-execution transactions are executed, including:

[0348] Step 2910: sequentially extract the pre-execution transaction from the plurality of pre-execution transactions, and if there is a completed process in the start process pool, call the completed process to execute the pre-execution transaction;

[0349] Step 2920: If there is no completed process in the open process pool, add an open process to the open process pool to execute the pre-execution transaction.

[0350] In step 2910, the process pool is a resource pool for storing multiple open processes. The process pool allows multiple tasks to be executed simultaneously in different open processes to improve the concurrency performance of the blockchain system, thereby improving the efficiency of contract execution and achieving efficient use of contract execution resources.

[0351] A completed process refers to an open process that has completed the transaction execution in the process. If there is a completed process in the open process pool, the completed process is called to execute the pre-execution transaction. For example, the pre-execution transactions in the pre-execution block include transaction 1, transaction 2, transaction 4, and transaction 5, and the open processes in the open process pool include open process 1, open process 2, and open process 3. Therefore, open process 1 is called to execute transaction 1, open process 2 is called to execute transaction 2, and open process 3 is called to execute transaction 4. When the process is assigned to transaction 5, open process 1 has already executed transaction 1. At this time, open process 1 is a completed process, and open process 1 is called to execute transaction 5.

[0352] In step 2920, if there is no completed process in the start process in the start process pool, in order to improve the execution speed of the pre-execution transaction in the blockchain network, an open process is added to the start process pool to execute the pre-execution transaction. For example, the pre-execution transactions in the pre-execution block include transaction 1, transaction 2, transaction 4, and transaction 5, and the start process in the start process pool includes start process 1, start process 2, and start process 3. Therefore, start process 1 is called to execute transaction 1, start process 2 is called to execute transaction 2, and start process 3 is called to execute transaction 4. When the process is assigned to transaction 5, there is no completed process in the start process in the start process pool. At this time, a new start process is added to the start process pool to call the new start process to execute transaction 5.

[0353] The advantage of the embodiment of step 2910-step 2920 is that the pre-execution transaction is assigned to the added start process or the start process of the completed transaction for execution, which can optimize the process allocation process of the blockchain network for the pre-execution transaction, and also improve the scalability and resource utilization of the blockchain network.

[0354] In step 2630, (slave consensus node) receives the target block from the master consensus node. The present invention places the selected conflict-free pre-execution transactions into the pre-execution block, and broadcasts the pre-execution block to other slave consensus nodes before the master node executes the transactions in the pre-execution block. This allows the slave consensus node to complete the verification and execution of the pre-execution transaction at an early stage, compresses the waiting time of the two consensus nodes, and improves the blockchain execution efficiency. Therefore, the master and slave consensus nodes execute the pre-execution transactions in parallel at the same time, and the slave consensus node receives the target block generated by the master consensus node only after the master and slave consensus nodes have executed the pre-execution block.

[0355] In step 2640, multiple pre-executed transactions are removed from multiple transactions of the target block (from the consensus node) to obtain remaining transactions. Remaining transactions refer to the remaining conflicting transactions after removing multiple pre-executed transactions from multiple transactions of the target block. For example, Fig.30 As shown, the transactions in the target block received from the consensus node include transaction 1, transaction 2, transaction 3, transaction 4, transaction 5, and transaction 6, and the pre-execution transactions in the pre-execution block received from the consensus node include transaction 1, transaction 2, transaction 4, and transaction 5. Therefore, the slave consensus node has completed the verification and execution of the pre-execution transactions at an early stage. At this time, the slave consensus node removes multiple pre-execution transactions from multiple transactions in the target block, and the remaining transactions include transaction 3 and transaction 6.

[0356] In step 2650, the remaining transactions are executed (from the consensus node) and the target block is put on the chain.

[0357] Reference Fig.31 , step 2650 can be specifically divided into step 2650a (from the consensus node) to execute the remaining transactions, and step 2650b (from the consensus node) to put the target block on the chain.

[0358] In one embodiment, continue to refer to Fig.31 , step 2650a executes the remaining transactions, including:

[0359] Step 3110: sequentially extract the remaining transactions from the plurality of remaining transactions, and if there is a completed process in the open process pool, call the completed process to execute the remaining transactions;

[0360] Step 3120: If there is no completed process in the open process pool, add an open process to the open process pool to execute the remaining transactions.

[0361] In step 3110, the start process pool has been described in the above embodiment and will not be described again. For example, the remaining transactions include transaction 3 and transaction 6, and the start processes in the start process pool include start process 1, start process 2, and start process 3. At this time, the completed processes in the start process pool include start process 2 and start process 3, so the start process 2 is called to execute transaction 3, and the start process 3 is called to execute transaction 6.

[0362] In step 3120, if there is no completed process in the open process in the open process pool, in order to improve the execution speed of the pre-executed transaction in the blockchain network, an open process is added to the open process pool to execute the remaining transactions. For example, the remaining transactions include transaction 3 and transaction 6, and the open processes in the open process pool include open process 1, open process 2, and open process 3. At this time, the completed process in the open process pool includes open process 2, and open process 2 is called to execute transaction 3. However, when the process is assigned to transaction 6, there is no completed process in the open process in the open process pool. At this time, a new open process is added to the open process pool to call the new open process to execute transaction 6.

[0363] The advantage of the embodiment of step 3110-step 3120 is that the remaining transactions are allocated to the added start process or the start process of the completed transaction for execution, which can optimize the process allocation process of the blockchain network for the remaining transactions, and also improve the scalability and resource utilization of the blockchain network.

[0364] In one embodiment, Fig.32 As shown, step 2650b puts the target block on the chain, including:

[0365] Step 3210: perform integrity verification on the pre-executed transaction and the remaining transactions;

[0366] Step 3220: If the integrity verification is successful, a consensus success message is sent to the main consensus node, and the target block is put on the chain.

[0367] In step 3210, integrity verification is performed on the pre-executed transaction and the remaining transaction to ensure the integrity of the transaction to prevent tampering or forgery.

[0368] The integrity verification for the pre-execution transaction and the remaining transaction includes: obtaining the pre-execution transaction and the remaining transaction for integrity verification; calculating the content summary of the pre-execution transaction according to a predetermined summary algorithm (such as a hash algorithm) to generate a summary value of the pre-execution transaction; comparing the generated hash value of the pre-execution transaction with the summary value recorded in the pre-execution transaction; if the two are consistent, the integrity verification of the pre-execution transaction is successful; using the integrity verification result of the pre-execution transaction and the original data of the remaining transaction, reconstructing the content of the remaining transaction; calculating the summary of the reconstructed remaining transaction content according to a predetermined summary algorithm (such as a hash algorithm) to generate a summary value of the remaining transaction; comparing the generated summary value of the remaining transaction with the summary value recorded in the remaining transaction. If the two are consistent, the integrity verification of the remaining transaction is successful. Therefore, if the integrity verification of the pre-execution transaction and the remaining transaction is successful, it means that the transaction in the target block has not been tampered with or forged during the transmission process.

[0369] In step 3220, integrity verification success means that the integrity verification of both the pre-executed transaction and the remaining transaction is successful. If the integrity verification is successful, the slave consensus node sends a consensus success message to the master consensus node and puts the target block on the chain.

[0370] An advantage of the embodiment of step 3210-step 3220 is that the security and credibility of the blockchain network can be improved by verifying the integrity of pre-executed transactions and remaining transactions.

[0371] In one embodiment, Fig.33 As shown, receiving the target block from the main consensus node includes:

[0372] Step 3310: Receive the target block and the relationship dependency graph between multiple transactions from the main consensus node.

[0373] At this point, after executing the remaining transactions, the blockchain on-chain method also includes:

[0374] Step 3320: Based on the relationship dependency graph, correct the execution of the pre-executed transaction and the remaining transactions.

[0375] In step 3310, the target block and the relationship dependency graph have been described in detail in the above embodiments, and will not be repeated here to save space.

[0376] In step 3320, after the pre-executed transactions and remaining transactions in the target block are executed, the transaction scheduler of the main consensus node starts scheduling the transactions that may conflict in parallel. If a conflict occurs, it may need to be re-executed. Therefore, it is necessary to correct the execution of the pre-executed transactions and remaining transactions based on the relationship dependency graph.

[0377] The advantage of the above embodiment is that the relationship dependency graph can better understand and analyze the interactions and dependencies between the various participants in the blockchain network, which helps to reveal the characteristics of the network structure, performance and security. This is of great significance for designing and optimizing blockchain networks, as well as conducting network analysis and attack detection.

[0378] The advantage of the embodiment of step 2610-step 2650 is that, since the pre-execution transaction is conflict-free in reading and writing, the execution operation of the pre-execution transaction by the master-slave consensus node can shorten the waiting time of the master-slave consensus node when the blockchain is put on the chain. The slave consensus node receives the target block sent by the master consensus node, and after the slave consensus node executes the pre-execution transaction, the slave consensus node executes the transaction other than the pre-execution transaction in multiple transactions, and puts the target block on the chain. In this way, in the embodiment of the present disclosure, the transactions in the pre-execution block are pre-executed in the master-slave consensus node, which can shorten the waiting time of the master-slave consensus node when the blockchain is put on the chain, improve the execution efficiency of the consensus node on the transaction, and improve the blockchain on-chain efficiency of the alliance chain.

[0379] Implementation details of the blockchain on-chain method of the disclosed embodiment

[0380] Refer to the following Fig.34A and Fig.34B , which illustrates in detail and by way of example, the complete implementation details of the blockchain on-chain method executed by the transaction generation node and the master-slave consensus node of the embodiment of the present disclosure.

[0381] In step 310, it is divided into step 310a-step 310b. The two steps have the same meaning, but the execution subjects are different. In step 310a, the transaction generation node sends the transaction to the main consensus node. At the same time, in step 310b, it is divided into step 310ba-step 310bc. In step 310ba, the main consensus node receives the transaction from the transaction generation node (step 410). In step 310bb, the transaction is placed in the transaction pool (step 420). In step 310bc, multiple transactions to be packaged into the target block are taken out from the transaction pool according to predetermined standards (step 430).

[0382] After receiving the transaction to be packaged into the target block from the transaction generation node in step 410, the blockchain on-chain method also includes: verifying the first signature (step 810), obtaining the permission data of the transaction generation node, and verifying the transaction based on the permission data (step 820). In step 810, it is divided into steps 810a-810d. In step 810a, the public key of the transaction generation node is obtained (step 910). In step 810b, the first signature is decrypted using the public key to obtain the decryption result (step 920). In step 810c, the transaction is recalculated using a predetermined summary algorithm (step 930). In step 810d, if the decryption result is consistent with the recalculated summary, it is determined that the signature verification is successful (step 940). In step 810a, it is divided into steps 810aa-810ab, and the meanings of these two steps are the same, but there is a difference in the execution subject. In step 810aa, the transaction generation node sends the public key to the main consensus node. At the same time, in step 810ab, the main consensus node obtains the public key of the transaction generation node. In step 820, it is divided into steps 820a-820b. In step 820a, the transaction generation node sends permission data to the main consensus node. At the same time, in step 820b, the main consensus node obtains the permission data of the transaction generation node and performs permission verification on the transaction based on the permission data.

[0383] In step 320, (the primary consensus node) obtains the read variable set and the write variable set of the transaction.

[0384] In step 330, it is divided into step 330a-step 330b. In step 330a, based on the read variable set and the write variable set, the predicted conflict matrix between multiple transactions is determined (step 1410). In step 330b, based on the predicted conflict matrix, the pre-execution transaction without conflict in variable reading and writing among the multiple transactions is determined (step 1420).

[0385] In step 340, it is divided into step 340a-step 340b. In step 340a, the master consensus node packages the determined pre-execution transaction into a pre-execution block and sends it to the slave consensus node for execution. In step 340b, the slave consensus node receives the pre-execution block, which includes multiple pre-execution transactions (step 2610).

[0386] After receiving the pre-execution block from the master consensus node in step 340b (step 2610), the blockchain on-chain method further includes, in the slave consensus node: in step 2710, assigning multiple parallel verification processes to multiple pre-execution transactions. In step 2720, it is divided into step 2720a-step 2720b. In step 2720a, for a pre-execution transaction, the first signature is verified using the verification process assigned to the pre-execution transaction (step 2810). In step 2720b, the permission data of the master consensus node is obtained using the verification process assigned to the pre-execution transaction, and the transaction is verified based on the permission data. In step 2620, it is divided into step 2610a-step 2610b. In step 2610a, the pre-execution transaction is sequentially taken out from the multiple pre-execution transactions, and if there is a completed process in the opening process pool, the completed process is called to execute the pre-execution transaction (step 2910). In step 2610b, if there is no completed process in the open process pool, add an open process to the open process pool to execute the pre-execution transaction (step 2920).

[0387] In step 350, it is divided into step 350a-step 350c. In 350a, it is divided into step 350aa-step 350ac. In step 350aa, based on the number of pre-executed transactions, the number of matching processes is determined (step 2210). In step 350ab, based on the second difference between the number of matching processes and the number of open processes, the open process is increased (step 2220). In step 350ac, the pre-executed transaction is assigned to the increased open process or the open process of the completed transaction for execution (step 2230). In step 350b, based on multiple transactions, a target block is generated and sent to the slave consensus node. At the same time, in step 2630, the target block is received from the master consensus node. Afterwards, in step 2640, multiple pre-executed transactions are removed from multiple transactions of the target block to obtain remaining transactions. In step 3110, the remaining transactions are sequentially taken out from the multiple remaining transactions. If there is a completed process in the open process pool, the completed process is called to execute the remaining transactions. In step 3120, if there is no completed process in the open process pool, add an open process to the open process pool to execute the remaining transactions.

[0388] In step 360, it is divided into step 360a-step 360b. After executing transactions other than pre-executed transactions in multiple transactions in step 360a, in step 2410, the main consensus node executes the determined transaction and determines the relationship dependency graph between the acquired transactions. At the same time, in step 3310, it is divided into 3310a and 3310b. In step 3310a, the main consensus node sends the relationship dependency graph to the slave consensus node. In step 3310b, the slave consensus node receives the relationship dependency graph between multiple transactions. In step 2420, the main consensus node corrects the execution of the determined transaction based on the relationship dependency graph. At the same time, after receiving the relationship dependency graph between multiple transactions, the slave consensus node corrects the execution of the pre-executed transaction and the remaining transactions based on the relationship dependency graph in step 3320. In step 3210, integrity verification is performed on the pre-executed transaction and the remaining transactions. In step 3220, if the integrity verification is successful, a consensus success message is sent to the main consensus node, and the target block is put on the chain. In step 360b, it is divided into step 360ba-step 360bb. In step 360ba, the master consensus node receives a consensus success message from the slave consensus node (step 2510). In step 360bb, the target block is put on the chain, and the status information associated with the target block is recorded (step 2520).

[0389] The advantages of this embodiment include but are not limited to: since the pre-execution transaction is conflict-free in reading and writing, the execution operation of the pre-execution transaction by the master-slave consensus node can shorten the waiting time of the master-slave consensus node when the blockchain is put on the chain. At the same time, after sending the pre-execution block to the slave consensus node for execution, the master consensus node executes the pre-execution transaction, and based on multiple transactions, generates a target block and sends it to the slave consensus node. After the master consensus node executes the pre-execution transaction, the master consensus node executes transactions other than the pre-execution transaction in multiple transactions, and puts the target block on the chain. In this way, in the disclosed embodiment, the transactions in the pre-execution block are pre-executed in the master-slave consensus node, which can shorten the waiting time of the master-slave consensus node when the blockchain is put on the chain, improve the execution efficiency of the master-slave consensus node on the transaction, and improve the blockchain on-chain efficiency of the alliance chain.

[0390] Description of the apparatus and device of the present disclosure

[0391] In each specific implementation of the present application, when it comes to the need to perform relevant processing based on data related to object characteristics such as object attribute information or attribute information sets, the permission or consent of the object will be obtained first, and the collection, use and processing of these data will comply with relevant laws, regulations and standards. In addition, when the embodiment of the present application needs to obtain object attribute information, the object's separate permission or separate consent will be obtained through a pop-up window or jump to a confirmation page. After clearly obtaining the object's separate permission or separate consent, the necessary object-related data for the normal operation of the embodiment of the present application will be obtained.

[0392] Reference Fig.35 , Fig.35 A schematic diagram of the structure of a blockchain on-chain device 3500 provided in an embodiment of the present disclosure, which is used as a master consensus node. The blockchain on-chain device 3500 includes:

[0393] A first acquisition unit 3510 is used to acquire multiple transactions to be packaged into a target block;

[0394] A second acquisition unit 3520, configured to acquire a read variable set and a write variable set of a transaction;

[0395] A first determining unit 3530 is used to determine, based on the read variable set and the write variable set, a pre-execution transaction having no conflict in variable reading and writing among the multiple transactions;

[0396] The first sending unit 3540 is used to package the determined pre-execution transaction into a pre-execution block and send it to the slave consensus node for execution;

[0397] The second sending unit 3550 is used to execute the pre-execution transaction, and based on multiple transactions, generate a target block and send it to the slave consensus node;

[0398] The first on-chain unit 3560 is used to execute transactions other than pre-executed transactions in multiple transactions and to chain the target block.

[0399] Optionally, the first determining unit 3530 is specifically configured to:

[0400] Determine a prediction conflict matrix between the plurality of transactions based on the read variable set and the write variable set;

[0401] Based on the predicted conflict matrix, pre-executed transactions with no conflicts in variable reading and writing among multiple transactions are determined.

[0402] Optionally, reading the variable set includes reading the first contract identifier based on it and the first variable identifier; writing the variable set includes writing the second contract identifier based on it and the second variable identifier;

[0403] The first determining unit 3530 is further specifically configured to:

[0404] If multiple transactions include a first transaction and a second transaction, the first contract identifier in the read variable set of the first transaction is the same as the second contract identifier in the write variable set of the second transaction, and the first variable identifier in the read variable set of the first transaction is the same as the second variable identifier in the write variable set of the second transaction, then the conflict value associated with the first transaction and the second transaction in the predicted conflict matrix is ​​set to the first value.

[0405] Optionally, the first determining unit 3530 is further specifically configured to:

[0406] If the conflict value commonly associated with a transaction and any other transaction in the predicted conflict matrix is ​​not the first value, the transaction is determined as the first pre-execution transaction;

[0407] If the transaction has only a read variable set, the transaction is determined to be a second pre-execution transaction;

[0408] The first pre-execution transaction and the second pre-execution transaction are integrated into a pre-execution transaction.

[0409] Optionally, the first determining unit 3530 is further specifically configured to:

[0410] Determine that a plurality of transactions contain only write variable sets, or contain neither read variable sets nor write variable sets;

[0411] Combine transactions containing only write variables set into pre-execution transactions.

[0412] Optionally, the second acquiring unit 3520 is specifically configured to:

[0413] If the transaction includes a read, obtaining a first contract identifier of a first contract based on which the read is based, and a first variable identifier of a first variable of the read, and writing the first contract identifier and the first variable identifier into a read variable set, wherein if the read does not have a determined first variable, writing a set of variables in the first contract into the read variable set;

[0414] If the transaction includes a write, obtain the second contract identifier of the second contract on which the write is based and the second variable identifier of the second variable that was read, and write the second contract identifier and the second variable identifier into a write variable set, wherein, if the write does not have a determined second variable, write a set of variables in the second contract into the write variable set.

[0415] Optionally, the first acquiring unit 3510 is specifically configured to:

[0416] Receive transactions from transaction generation nodes;

[0417] Put the transaction into the transaction pool;

[0418] From the transaction pool, multiple transactions to be packaged into the target block are taken out according to predetermined standards.

[0419] Optionally, the first acquiring unit 3510 is further specifically configured to:

[0420] From the transaction pool, take out the transaction with the priority mark;

[0421] Determine the first difference between the maximum number of transactions that can be accommodated by the target block and the number of transactions with priority flags;

[0422] From the remaining transactions in the transaction pool, take the first difference transaction in the order of receiving timestamps from first to last.

[0423] Optionally, the transaction includes a first signature of the transaction generation node; after receiving the transaction from the transaction generation node, the blockchain on-chain device further includes:

[0424] A first signature verification unit (not shown), configured to verify the first signature;

[0425] The first authority verification unit (not shown) is used to obtain the authority data of the transaction generation node and perform authority verification on the transaction based on the authority data.

[0426] Optionally, the first signature is obtained by the transaction generation node obtaining a digest of the transaction using a predetermined digest algorithm and encrypting the digest using a private key of the transaction generation node;

[0427] The first signature verification unit (not shown) is specifically used for:

[0428] Get the public key of the transaction generation node;

[0429] Decrypting the first signature using the public key to obtain a decryption result;

[0430] Recalculate the digest of the transaction using a predetermined digest algorithm;

[0431] If the decryption result is consistent with the recalculated digest, the signature verification is successful.

[0432] Optionally, the second sending unit 3550 is specifically configured to:

[0433] Determine the number of matching processes based on the number of pre-executed transactions;

[0434] Based on the second difference between the number of matching processes and the number of opened processes, adding an opened process;

[0435] Assign the pre-execution transaction to the added start process or the start process of the completed transaction for execution.

[0436] Optionally, after executing transactions other than the pre-executed transactions in the multiple transactions, the blockchain on-chain device further includes:

[0437] A second determining unit (not shown), configured to execute the determined transaction and determine a relationship dependency graph between the acquired transactions;

[0438] The first correction unit (not shown) is used to correct the execution of the determined transaction based on the relationship dependency graph.

[0439] Optionally, the first uplink unit 3560 is specifically used for:

[0440] Receive consensus success message from the consensus node;

[0441] Put the target block on the chain and record the status information associated with the target block.

[0442] Reference Fig.36 , Fig.36 A schematic diagram of the structure of a blockchain on-chain device 3600 provided in an embodiment of the present disclosure, which is used from a consensus node. The blockchain on-chain device 3600 includes:

[0443] The first receiving unit 3610 is used to receive a pre-execution block from the main consensus node, where the pre-execution block includes multiple pre-execution transactions, and the pre-execution transaction is a transaction that has no conflict in variable reading and writing among multiple transactions to be packaged into the target block;

[0444] A first execution unit 3620, configured to execute a plurality of pre-execution transactions;

[0445] The second receiving unit 3630 is used to receive the target block from the main consensus node;

[0446] A third acquisition unit 3640 is used to remove multiple pre-executed transactions from multiple transactions of the target block to obtain remaining transactions;

[0447] The second execution unit 3650 is used to execute the remaining transactions and put the target block on the chain.

[0448] Optionally, after receiving the pre-execution block from the main consensus node, the blockchain on-chain device further includes:

[0449] A first allocation unit (not shown), configured to allocate multiple parallel verification processes to multiple pre-execution transactions;

[0450] The first transaction verification unit (not shown) is used to verify multiple pre-execution transactions using multiple parallel verification processes.

[0451] Optionally, the pre-execution transaction has a first signature of the primary consensus node;

[0452] The first transaction verification unit (not shown) is specifically used for:

[0453] For a pre-execution transaction, verify the first signature using the verification process assigned to the pre-execution transaction;

[0454] Utilize the verification process assigned to the pre-execution transaction to obtain the permission data of the main consensus node, and perform permission verification on the transaction based on the permission data.

[0455] Optionally, the first execution unit 3620 is specifically configured to:

[0456] Sequentially take out pre-execution transactions from multiple pre-execution transactions, and if there is a completed process in the start process pool, call the completed process to execute the pre-execution transaction;

[0457] If there is no completed process in the open process pool, add an open process to the open process pool to execute the pre-execution transaction.

[0458] Optionally, the second execution unit 3650 is specifically configured to:

[0459] Sequentially take out the remaining transactions from the multiple remaining transactions. If there is a completed process in the start process pool, call the completed process to execute the remaining transactions.

[0460] If there is no completed process in the open process pool, add an open process to the open process pool to execute the remaining transactions.

[0461] Optionally, the second execution unit 3650 is further specifically configured to:

[0462] Perform integrity verification on pre-execution transactions and remaining transactions;

[0463] If the integrity verification is successful, a consensus success message is sent to the main consensus node and the target block is put on the chain.

[0464] Optionally, the second receiving unit 3630 is specifically configured to:

[0465] Receive the target block and the relationship dependency graph between multiple transactions from the main consensus node;

[0466] After executing the remaining transactions, the blockchain on-chain device also includes:

[0467] The second correction unit (not shown) is used to correct the execution of the pre-executed transaction and the remaining transaction based on the relationship dependency graph.

[0468] Reference Fig.37 , Fig.37The structural block diagram of the terminal 210 for implementing the blockchain on-chain method of the embodiment of the present disclosure includes: a radio frequency (RF) circuit 3710, a memory 3715, an input unit 3730, a display unit 3740, a sensor 3750, an audio circuit 3760, a wireless fidelity (WiFi) module 3770, a processor 3780, and a power supply 3790. Those skilled in the art can understand that Fig.37 The structure of the terminal 210 shown in the figure does not constitute a limitation on a mobile phone or a computer, and may include more or less components than those shown in the figure, or combine certain components, or arrange the components differently.

[0469] The RF circuit 3710 can be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information from the base station, it is sent to the processor 3780 for processing; in addition, the designed uplink data is sent to the base station.

[0470] The memory 3715 may be used to store software programs and modules. The processor 3780 executes various functional applications and data processing of the terminal by running the software programs and modules stored in the memory 3715 .

[0471] The input unit 3730 may be used to receive input digital or character information and generate key signal input related to the terminal's settings and function control. Specifically, the input unit 3730 may include a touch panel 3731 and other input devices 3732 .

[0472] The display unit 3740 may be used to display input information or provided information and various menus of the terminal. The display unit 3740 may include a display panel 3741.

[0473] The audio circuit 3760, the speaker 3761, and the microphone 3762 may provide an audio interface.

[0474] In this embodiment, the processor 3780 included in the terminal 210 can execute the blockchain on-chain method of the previous embodiment.

[0475] The terminals of the embodiments of the present disclosure include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. The embodiments of the present invention can be applied to various scenarios, including but not limited to input methods, intelligent input products, human-computer interaction processing, etc.

[0476] Fig.38A block diagram of the structure of a portion of a server for implementing the blockchain on-chain method of an embodiment of the present disclosure. The server may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 3382 (for example, one or more processors) and memory 3832, and one or more storage media 3830 (for example, one or more mass storage devices) storing application programs 3842 or data 3844. Among them, the memory 3832 and the storage medium 3830 can be short-term storage or permanent storage. The program stored in the storage medium 3830 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server 3800. Furthermore, the central processing unit 3822 can be configured to communicate with the storage medium 3830 and execute a series of instruction operations in the storage medium 3830 on the server 3800.

[0477] The server 3800 may also include one or more power supplies 3826, one or more wired or wireless network interfaces 3850, one or more input and output interfaces 3858, and / or one or more operating systems 3841, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0478] The processor in the server 3800 can be used to execute the blockchain on-chain method of the embodiment of the present disclosure.

[0479] The embodiments of the present disclosure also provide a computer-readable storage medium, which is used to store program code, and the program code is used to execute the blockchain on-chain method of each of the aforementioned embodiments.

[0480] The present disclosure also provides a computer program product, which includes a computer program. The processor of the computer device reads and executes the computer program, so that the computer device executes the above-mentioned blockchain on-chain method.

[0481] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "comprises" and "comprising" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0482] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0483] It should be understood that in the description of the embodiments of the present disclosure, the meaning of multiple (or multiple items) is more than two, greater than, less than, exceed, etc. are understood to not include the number, and above, below, within, etc. are understood to include the number.

[0484] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0485] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0486] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0487] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

[0488] It should also be understood that the various implementations provided in the embodiments of the present disclosure can be combined arbitrarily to achieve different technical effects.

[0489] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.

Claims

1. A blockchain on-chain method, characterized in that: For the main consensus node, the blockchain on-chain method includes: Get multiple transactions to be packaged into the target block; Obtaining a read variable set and a write variable set of the transaction; Based on the read variable set and the write variable set, determining a pre-execution transaction in the plurality of transactions that has no conflict in variable reading and writing; Packing the determined pre-execution transaction into a pre-execution block and sending it to the slave consensus node for execution; Execute the pre-execution transaction, and based on a plurality of the transactions, generate the target block, and send it to the slave consensus node; Execute the transactions other than the pre-executed transactions among the multiple transactions, and put the target block on the chain.

2. The blockchain on-chain method according to claim 1, characterized in that: The determining, based on the read variable set and the write variable set, a pre-execution transaction in the plurality of transactions that has no conflict in variable reading and writing, comprises: Determining a prediction conflict matrix between a plurality of the transactions based on the read variable set and the write variable set; Based on the predicted conflict matrix, pre-execution transactions without conflicts in variable reading and writing are determined among the multiple transactions.

3. The blockchain on-chain method according to claim 2, characterized in that: The read variable set includes a first contract identifier based on which the reading is performed, and a first variable identifier; the write variable set includes a second contract identifier based on which the writing is performed, and a second variable identifier; The step of determining a prediction conflict matrix between a plurality of the transactions based on the read variable set and the write variable set comprises: If the multiple transactions include a first transaction and a second transaction, the first contract identifier in the read variable set of the first transaction is the same as the second contract identifier in the write variable set of the second transaction, and the first variable identifier in the read variable set of the first transaction is the same as the second variable identifier in the write variable set of the second transaction, then the conflict value commonly associated with the first transaction and the second transaction in the prediction conflict matrix is ​​set to the first value.

4. The blockchain method according to claim 3, characterized in that: The step of determining, based on the predicted conflict matrix, a pre-execution transaction among the plurality of transactions that has no conflict in variable reading and writing, comprises: If the conflict value commonly associated with one of the transactions and any other transactions in the predicted conflict matrix is ​​not the first value, determining the transaction as a first pre-execution transaction; If the transaction has only the read variable set, determining the transaction as a second pre-execution transaction; The first pre-execution transaction and the second pre-execution transaction are integrated into the pre-execution transaction.

5. The blockchain method according to claim 4, characterized in that: The step of determining, based on the predicted conflict matrix, a pre-execution transaction among the plurality of transactions that has no conflict in variable reading and writing, further comprises: Determining that a plurality of the transactions contain only the write variable set, or contain neither the read variable set nor the write variable set; The transaction containing only the set of write variables is integrated into the pre-execution transaction.

6. The blockchain method according to claim 3, characterized in that: The obtaining of the read variable set and the write variable set of the transaction comprises: If the transaction includes the read, obtaining the first contract identifier of the first contract on which the read is based and the first variable identifier of the first variable read, and writing the first contract identifier and the first variable identifier into the read variable set, wherein if the read does not have the determined first variable, writing the set of variables in the first contract into the read variable set; If the transaction includes the write, obtain the second contract identifier of the second contract on which the write is based and the second variable identifier of the read second variable, and write the second contract identifier and the second variable identifier into the write variable set, wherein if the write does not have a determined second variable, write the set of variables in the second contract into the write variable set.

7. The blockchain method according to claim 1, characterized in that: The obtaining of multiple transactions to be packaged into a target block includes: receiving the transaction from a transaction generation node; Put the transaction into a transaction pool; From the transaction pool, a plurality of transactions to be packaged into the target block are taken out according to a predetermined standard.

8. The blockchain method according to claim 7, characterized in that: The taking out the plurality of transactions to be packaged into the target block from the transaction pool according to a predetermined standard comprises: Taking out the transaction with a priority mark from the transaction pool; Determine a first difference between a maximum number of transactions that can be accommodated by the target block and the number of transactions with the priority flag; From the remaining transactions in the transaction pool, the first difference transaction is taken out in the order of receiving timestamps from earliest to latest.

9. The blockchain method according to claim 7, characterized in that: The transaction includes a first signature of the transaction generating node; After receiving the transaction from the transaction generation node, the blockchain on-chain method further includes: Verifying the first signature; The authority data of the transaction generation node is obtained, and the authority verification of the transaction is performed based on the authority data.

10. The blockchain method according to claim 9, characterized in that: The first signature is obtained by the transaction generation node obtaining a digest of the transaction using a predetermined digest algorithm and encrypting the digest using a private key of the transaction generation node; The verifying the first signature includes: Obtaining the public key of the transaction generation node; Decrypting the first signature using the public key to obtain a decryption result; Recalculating a digest of the transaction using the predetermined digest algorithm; If the decryption result is consistent with the recalculated digest, it is determined that the signature verification is successful.

11. The blockchain method according to claim 1, characterized in that: The executing the pre-execution transaction includes: Determining the number of matching processes based on the number of pre-executed transactions; Based on the second difference between the number of matching processes and the number of enabled processes, adding an enabled process; The pre-execution transaction is assigned to the added start process or the start process of the completed transaction for execution.

12. The blockchain method according to claim 1, characterized in that: After executing the transaction other than the pre-executed transaction among the multiple transactions, the blockchain on-chain method further includes: Execute the determined transaction, and determine a relationship dependency graph between the acquired transactions; Based on the relationship dependency graph, the execution of the transaction is modified.

13. A blockchain on-chain method, characterized in that: For use from a consensus node, the blockchain on-chain method includes: Receive a pre-execution block from the master consensus node, wherein the pre-execution block includes multiple pre-execution transactions, and the pre-execution transactions are transactions that have no conflicts in variable reading and writing among multiple transactions to be packaged into the target block; executing a plurality of the pre-execution transactions; Receiving the target block from the master consensus node; Removing a plurality of the pre-executed transactions from a plurality of the transactions of the target block to obtain remaining transactions; Execute the remaining transactions and put the target block on the chain.

14. The blockchain method according to claim 13, characterized in that: After receiving the pre-execution block from the master consensus node, the blockchain on-chain method further includes: Allocating multiple parallel verification processes for multiple pre-execution transactions; A plurality of the pre-execution transactions are verified using a plurality of the parallel verification processes.

15. The blockchain method according to claim 14, characterized in that: The pre-execution transaction has a first signature of the master consensus node; The using a plurality of the parallel verification processes to verify a plurality of the pre-execution transactions comprises: For one of the pre-execution transactions, verifying the first signature by using the verification process assigned to the pre-execution transaction; The verification process assigned to the pre-execution transaction is used to obtain the permission data of the main consensus node, and the transaction is verified based on the permission data.

16. A blockchain on-chain device, characterized in that: For the main consensus node, the blockchain on-chain device includes: A first acquisition unit, used to acquire multiple transactions to be packaged into a target block; A second acquisition unit, configured to acquire a read variable set and a write variable set of the transaction; A first determining unit, configured to determine, based on the read variable set and the write variable set, a pre-execution transaction having no conflict in variable reading and writing among the plurality of transactions; A first sending unit, configured to package the determined pre-execution transaction into a pre-execution block, and send the pre-execution block to a slave consensus node for execution; A second sending unit is used to execute the pre-execution transaction, and based on a plurality of the transactions, generate the target block and send it to the slave consensus node; The first on-chain unit is used to execute the transactions other than the pre-executed transactions among the multiple transactions, and to chain the target block.

17. A blockchain on-chain device, characterized in that: For use from a consensus node, the blockchain on-chain device includes: A first receiving unit is used to receive a pre-execution block from a master consensus node, wherein the pre-execution block includes a plurality of pre-execution transactions, and the pre-execution transaction is a transaction in which there is no conflict in variable reading and writing among the plurality of transactions to be packaged into a target block; A first execution unit, configured to execute a plurality of the pre-execution transactions; A second receiving unit, configured to receive the target block from the master consensus node; A third acquisition unit, configured to remove the plurality of pre-executed transactions from the plurality of transactions of the target block to obtain remaining transactions; The second execution unit is used to execute the remaining transactions and put the target block on the chain.

18. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the blockchain on-chain method described in any one of claims 1 to 15 is implemented.

19. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the blockchain on-chain method described in any one of claims 1 to 15 is implemented.

20. A computer program product, comprising a computer program, wherein the computer program is read and executed by a processor of a computer device, so that the computer device executes the blockchain on-chain method described in any one of claims 1 to 15.

Images