Consensus method and device in multi-party frequent service transaction scenarios based on blockchain

Abstract

The present invention discloses a consensus method for frequent multi-party service transactions based on blockchain: a subnetwork is constructed in the blockchain with business as the establishment unit, each subnetwork includes a service user node and a service user node; the service user calls the service to generate a service call record; in chronological order, the service user and the corresponding service provider package the service call record into blocks; the service provider node with the largest idle computing power weight in the subnetwork serves as the referee node; the service user sends the blocks to the referee node in the order of packaging, and the blocks carry the information tags of the corresponding service providers; the referee node requests blocks with the same information tags from the corresponding service providers and compares them to determine that the same blocks are consensus blocks; in the order in which consensus is achieved, the referee node broadcasts the consensus blocks to the blockchain network. This method can shorten the consensus time, improve the consensus efficiency, and ensure the confirmation and verification of transactions by the participating parties.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain and data processing technology, and in particular relates to a consensus method and device in a blockchain-based multi-party frequent service transaction scenario. Background Art

[0002] With the development of blockchain technology, more and more people are recognizing the flaws of existing consensus mechanisms and actively proposing solutions. For example, the SPBFT algorithm proposed by Beijing Jiaotong University introduces a points and upgrade / downgrade mechanism, enabling the algorithm to execute an optimized consensus protocol most of the time. This algorithm optimizes the consensus protocol of the PBFT algorithm by selecting nodes to participate in consensus based on their stake voting. This reduces the number of participating nodes and reduces the amount of communication between nodes during the consensus process. While this method of selecting participating nodes can reduce the number of participating nodes in large-scale service call scenarios, it does not address large-scale service transaction scenarios and does not take into account the participation of transaction participants. Transaction participants should prioritize block verification and confirmation to effectively ensure the trustworthiness of service transactions.

[0003] In service market transactions, multiple service users and service providers participate in service API calls, resulting in frequent multi-party service transactions. The multi-party and multi-organizational nature of these transactions dictates the preference for a consortium blockchain architecture to achieve record keeping, traceability, and trustworthiness of service transactions. Existing consortium blockchain consensus protocols include BFT-based consensus protocols, PBFT-based consensus protocols, and Raft-based consensus protocols. For example, Chinese Patent Publication No. CN114697344A discloses a blockchain consensus node determination method, a blockchain, and a blockchain node. The blockchain includes multiple second nodes and a first node. The method comprises: the first node and the multiple second nodes each determine their respective access delay information to other nodes; the multiple second nodes each transmit their respective access delay information to the first node; and the first node determines, based on the access delay information of the first node and each second node, a plurality of third nodes from the plurality of first nodes and the plurality of second nodes, the third nodes being used to determine the consensus node. For example, Patent Publication No. CN113872961A discloses a blockchain consensus method, a consensus node, and an electronic device. The method includes: the target consensus node selects a transaction set that has not yet been synchronized in the local transaction pool to execute the RBC protocol, uses the erasure code algorithm to split the transaction set into N data blocks corresponding to the consensus nodes of the blockchain, and sends the corresponding data blocks to other consensus nodes based on the Rval message. Other consensus nodes respond to the RBC protocol, forward the data blocks obtained from the Rval message in the blockchain through the Echo message, and after receiving a certain number of Echo messages, restore the data blocks to the transaction set based on the erasure code algorithm. When the target consensus node becomes the consensus master node, it selects the Merkle tree proof in sequence from the local consensus execution queue to initiate the consensus proposal of the PBFT protocol, and the consensus execution queue stores the Merkle tree proof generated by the target consensus node in sequence. Each consensus node matches the transaction corresponding to the Merkle tree proof that has reached consensus from the local transaction set to perform a write block operation on it.

[0004] These protocols must wait for the majority of all nodes in the blockchain network to agree before reaching consensus. The nodes participating in the consensus are mostly nodes. As the number of nodes increases, the consensus time also increases. On the other hand, in the scenario of large-scale service transactions, in fact, except for the two parties to the service transaction, other nodes do not care whether the transaction messages are credible. For the scenario of large-scale service calls, a consensus protocol based on service participants is needed to improve the time and efficiency of consensus. Summary of the Invention

[0005] The purpose of the present invention is to provide a consensus method and device for frequent multi-party service transactions based on blockchain, which can shorten the consensus time and improve the consensus efficiency and ensure the confirmation and verification of the transaction by the participating parties.

[0006] The present invention provides the following technical solutions:

[0007] A consensus method for a multi-party frequent service transaction scenario based on blockchain, comprising the following steps:

[0008] (1) Divide the business according to the needs of service users, and build sub-networks in the blockchain with the business as the establishment unit. Each sub-network includes a service user node and several service user nodes;

[0009] (2) The service provider user calls the service and generates a service call record;

[0010] (3) In chronological order, the service user and the corresponding service provider package the service call records into blocks;

[0011] (4) Calculate the idle computing power weights of the service providing nodes in the sub-network, and the node with the largest idle computing power weight serves as the referee node;

[0012] (5) The service user sends the blocks in step (3) to the referee node in the order of packaging, and the blocks carry the information tag of the service provider corresponding to the blocks;

[0013] (6) After receiving the block sent by the service user, the referee node requests the block with the same information tag from the corresponding service provider and compares them. After confirming that they are the same, the participants involved in the service have reached a consensus and determined that this block is the consensus block;

[0014] (7) In the order in which consensus is completed, the referee node broadcasts the consensus block in step (6) to the blockchain network.

[0015] In this context, a business refers to a service user's activity flow that may require the collaboration of multiple services. These services collectively constitute a business. A blockchain subnetwork contains a service user node and the service provider nodes for the services involved in the business. Multiple businesses have multiple subnetworks. These subnetworks ensure that only the parties involved in service invocations maintain trustworthy records, improving resource utilization. For example, let's assume service caller A's business requires services provided by providers a1, a2, a3, a4, and a5. The nodes in the blockchain subnetwork for this business include the service caller's node A and the service provider nodes a1, a2, a3, a4, and a5.

[0016] In step (2), the number of records in a block in the blockchain is agreed upon. If the number of service calls by a certain service provider reaches the record number, step (3) is performed; otherwise, step (2) is repeated.

[0017] In step (2), it is agreed that the number of records in a block of the blockchain is Nt. If a service provider's service is called Nt times, then step (3) is performed, otherwise step (2) is repeated. For example, the service call records provided by a provider are packaged based on Nt times; in chronological order, the service provider node locally packages Nt records of the service it provides being called, and the service user locally packages Nt call records of the service provided by a provider. The size of Nt is related to the size of each block of the blockchain and the size of the call record, that is, how many records each block can accommodate.

[0018] In step (4), the idle computing power weight of the node refers to the proportion of idle computing power of each node in the computing power network. The higher this proportion, the more idle computing power the node has, and the more computing resources it can provide to the entire network.

[0019] In step (4), the referee node has the broadcasting rights in the blockchain network that other non-referee nodes do not have. Each referee node has the right to broadcast k blocks. The number of broadcasts k is related to the user of the consensus protocol and can be determined by the user.

[0020] In step (5), when the number of blocks packaged by the service user and the service provider reaches k, the service user sends k blocks in the order of packaging, and these blocks will carry the information tags of the service provider corresponding to the blocks.

[0021] In step (5), the format of the information tag is "business number + service provider number - block number". For example, the provider information tag carried on the block may be a4-100, which represents the 100th block packaged by the a4 provider.

[0022] In step (6), an example is given for explaining this step: when the referee node receives a block with an information tag of "a4-100", the referee node will request the packaged block numbered 100 from the service provider a4.

[0023] The consensus method further includes setting a limit on the number of rounds for the referee node determined in step (4). If the referee node in this round cannot become a referee in the next certain number of rounds, the process of election, consensus and broadcasting for this round ends. If the referee node cannot become a referee in the next m rounds, m is set according to actual needs.

[0024] The consensus method further includes that after step (7) is completed, if there are still unconsensus blocks, jump to step (4) to perform the next round of election, consensus and broadcast until there are no unbroadcast blocks.

[0025] The present invention also provides a consensus device in a blockchain-based multi-party frequent service transaction scenario, including a memory and one or more processors, wherein the memory stores executable code, and when the one or more processors execute the executable code, they are used to implement the above-mentioned consensus method in the blockchain-based multi-party frequent service transaction scenario.

[0026] The present invention also provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, is used to implement the consensus method in the above-mentioned blockchain-based multi-party frequent service transaction scenario.

[0027] In response to the shortcomings of the current API service transaction settlement methods, the present invention provides specific solutions to the problems in the existing methods based on blockchain technology, which mainly include the following points.

[0028] (1) In order to solve the problem that the existing consensus protocol requires more than half of all nodes to agree to reach a consensus, the present invention narrows the scope of consensus to include participants in service transactions, namely, service provider and service user nodes. This can effectively shorten the consensus time and improve the efficiency of blockchain consensus in high-frequency service transaction scenarios.

[0029] (2) In view of the fact that the improved protocol based on the alliance chain does not combine the scenario of service transactions and does not take into account the verification of the participants, the present invention sets the consensus nodes as the service provider node, the service user node, and the referee node. The three-party consensus can not only ensure the confirmation and verification of the transaction by the participants, but also the existence of the referee node to prevent any node from doing evil.

[0030] Therefore, compared with the prior art, the present invention has the following technical effects:

[0031] The present invention uses blockchain as a foundation to build an environment and ensure that transactions are trustworthy. It divides the blockchain network into business units to form blockchain subnets. On the one hand, by narrowing the scope of nodes participating in consensus, the number of nodes participating in consensus is reduced, thereby reducing the resources and time consumed by consensus, and ensuring the efficiency of data on the chain when frequent transactions occur. On the other hand, by setting up referee nodes, the nodes serving as transaction participants serve as consensus nodes, ensuring that the blocks packaged by the participants are consistent before broadcasting, and using referee nodes for supervision to prevent the occurrence of malicious nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 A flowchart of a consensus method in a blockchain-based multi-party frequent service transaction scenario provided in an embodiment. DETAILED DESCRIPTION

[0033] In order to better understand the technical solution of the present application, the following describes the implementation of the invention with reference to an example, taking the weather forecasting service as an example. The service includes a data set extraction service, a data set training service, and a data forecasting service.

[0034] It should be clear that the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0035] The terms used in the embodiments of the present application are for the purpose of describing specific embodiments only and are not intended to limit the present application. The singular forms "a", "an", "the" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise.

[0036] The consensus method in a blockchain-based multi-party frequent service transaction scenario provided by the present invention includes the following steps:

[0037] (1) Divide the business according to the needs of service users, and build sub-networks in the blockchain with the business as the establishment unit. Each sub-network includes a service user node and several service user nodes;

[0038] (2) The service provider user calls the service and generates a service call record;

[0039] (3) In chronological order, the service user and the corresponding service provider package the service call records into blocks;

[0040] (4) Calculate the idle computing power weights of the service providing nodes in the sub-network, and the node with the largest idle computing power weight serves as the referee node;

[0041] (5) The service user sends the blocks in step (3) to the referee node in the order of packaging, and the blocks carry the information tag of the service provider corresponding to the blocks;

[0042] (6) After receiving the block sent by the service user, the referee node requests the block with the same information tag from the corresponding service provider and compares them. After confirming that they are the same, the participants involved in the service have reached a consensus and determined that this block is the consensus block;

[0043] (7) In the order in which consensus is completed, the referee node broadcasts the consensus block in step (6) to the blockchain network.

[0044] like Figure 1 As shown, the consensus method in the blockchain-based multi-party frequent service transaction scenario provided by this embodiment specifically includes the following steps:

[0045] Step 1: Create a weather forecast service based on the needs of service user su1. The weather forecast service includes a dataset extraction service, a dataset training service, and a data prediction service. These three services together constitute a service. The providers of these three services are sp1, sp2, and sp3.

[0046] Step 2: Create a blockchain subnetwork based on the weather forecast business created by service user su1. The blockchain subnetwork of this business includes a service user su1 node, a service provider sp1 node, a service provider sp2 node, and a service provider sp3 node.

[0047] For steps 1 and 2, the blockchain subnetwork is based on business units, and businesses are created by service users. For example, if service user su1 establishes a commodity purchase business and a weather forecast business, then there will be two corresponding subnetworks: a commodity purchase business subnetwork and a weather forecast business subnetwork.

[0048] Step 3: Service user su1 calls the dataset extraction service and dataset training service in the weather forecast business to generate corresponding service call records.

[0049] Step 4: In this embodiment, the number of records in a block of the blockchain is agreed to be 3,000. If any service in the business is called 3,000 times, proceed to step 5, otherwise loop through step 3.

[0050] Specifically, in this embodiment, when the dataset training service is called 3000 times, the process proceeds to step 5, otherwise the process loops to step 3; when the dataset extraction service is called 3000 times, the process proceeds to step 5, otherwise the process loops to step 3.

[0051] Step 5: In chronological order, the service user and the corresponding service provider package the service call records into blocks:

[0052] Specifically, when the service provided by service provider sp1 is called 3000 times, service user su1 will package the 3000 service call records of the dataset extraction service into a block in chronological order, and service provider sp1 will also package the 3000 service call records of the dataset extraction service into a block; similarly, when the dataset training service of service provider sp2 is called 3000 times, service user su1 will package the 3000 service call records of the dataset training service into a block, and service provider sp2 will package the 3000 service call records of the dataset training service into a block.

[0053] Step 6: Based on the service provider nodes in the created blockchain sub-network, the system selects referee nodes according to the idle computing power weight of each service provider node. The node with a large idle computing power weight serves as the referee node. If it is found after calculation that the computing power of the service provider sp3 node is sufficient, the node can be selected as the referee node. In the subsequent process, the referee node has the broadcasting right that other non-referee nodes do not have in the blockchain network. Each referee node has the right to broadcast k blocks.

[0054] Step 7: In this example, the number of blocks, k, is set to 100. Based on the blocks packaged by the nodes of both the service provider and service user, namely, the blocks packaged by service user su1, when the number of packaged blocks reaches 100, the service user sends 100 blocks in the order of packaging through the service user node. These blocks carry the information tags of the corresponding service provider, in the format of "service number + provider number - block number".

[0055] For example, sp1-100 represents the 100th block packaged by service provider sp1. In the following steps, the block labeled "sp1-100" is used as an example.

[0056] Step 8: Based on each block sent by the service user su1, the referee node will request the block with the same information label from the corresponding service provider node. When the referee node receives a block with the information label "sp1-100", the referee node will request the packaged block numbered 100 from the service provider sp1.

[0057] Step 9: The referee node, that is, the node of the service provider sp3, will label the block from the service provider su1 as "sp1-100" and compare it with the block from the service user sp1. Once they are confirmed to be the same, the participants involved in the service (dataset extraction service) have reached a consensus.

[0058] Similarly, by performing steps 7-9, consensus can be reached on the data set training service in the business.

[0059] Step 10: Based on the block that has reached consensus, that is, the block labeled "sp1-100", the referee node broadcasts the consensus block. The referee node broadcasts all 100 blocks to the blockchain network in the order in which the consensus was reached.

[0060] Step 11: To prevent the long-term use of a referee node from causing the node's own transactions to be unable to be uploaded to the chain, a restriction is set that the referee node in this round cannot become a referee node in the next 5 rounds, and the election, consensus, and broadcast process for this round ends.

[0061] Step 12: If there are still unconsensed blocks, jump to step 6 and proceed to the next round of election, consensus, and broadcast until there are no unbroadcasted blocks.

[0062] An embodiment of the present invention further provides a consensus device for a blockchain-based multi-party frequent service transaction scenario, comprising one or more processors, and a memory storing executable code. When the processor executes the executable code, it is used to implement the consensus method for the blockchain-based multi-party frequent service transaction scenario described in the above embodiment. Taking software implementation as an example, as a logical device, it is formed by the processor of any device with data processing capabilities in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and executing it. From a hardware perspective, in addition to the processor, memory, network interface, and non-volatile memory, the device with data processing capabilities in which the device in the embodiment is located may also include other hardware based on the actual functions of the device with data processing capabilities, which will not be described in detail.

[0063] An embodiment of the present invention further provides a computer-readable storage medium having a program stored thereon. When executed by a processor, the program implements the consensus method in the blockchain-based multi-party frequent service transaction scenario described in the above embodiments: the computer-readable storage medium can be an internal storage unit of any device with data processing capabilities described in any of the above embodiments, such as a hard disk or memory. The computer-readable storage medium can also be any device with data processing capabilities, such as a plug-in hard disk, smart media card (SMC), SD card, flash memory card (Flash8 Card), etc. equipped on the device. Furthermore, the computer-readable storage medium can also include both an internal storage unit of any device with data processing capabilities and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by any device with data processing capabilities, and can also be used to temporarily store data that has been output or is about to be output.

[0064] The foregoing is merely an embodiment of the present invention and is not intended to limit the present invention. It will be apparent to those skilled in the art that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention are intended to be included within the scope of the claims of the present invention.

Claims

1. A consensus method for frequent multi-party service transactions based on blockchain, characterized by: The consensus method comprises the following steps: (1) Divide the business according to the needs of service users, and build sub-networks in the blockchain based on the business as the establishment unit. Each sub-network includes a service user node and several service provider nodes; (2) The service user calls the service and generates a service call record; (3) In chronological order, the service user and the corresponding service provider package the service call records into blocks; (4) Calculate the idle computing power weight of the service provider nodes in the sub-network, and the node with the largest idle computing power weight serves as the referee node; (5) The service user sends the blocks in step (3) to the referee node in the order of packaging, and the blocks carry the information tag of the service provider corresponding to the blocks; (6) After receiving the block sent by the service user, the referee node requests the block with the same information tag from the corresponding service provider and compares them. After confirming that they are the same, the participants involved in the service have reached a consensus and determined that this block is the consensus block; (7) In the order in which the consensus is completed, the referee node broadcasts the consensus block in step (6) to the blockchain network; In step (4), the referee node has the broadcasting right that other non-referee nodes do not have in the blockchain network. Each referee node has the right to broadcast k blocks; The consensus method also includes setting a limit on the number of rounds for the referee node determined in step (4), so that the referee node in this round cannot become a referee in the next certain number of rounds, and the process of election, consensus and broadcasting in this round ends.

2. The consensus method in a multi-party frequent service transaction scenario based on blockchain according to claim 1 is characterized in that: In step (2), the number of records in a block in the blockchain is agreed upon. If the number of service calls by a certain service provider reaches the record number, step (3) is performed; otherwise, step (2) is repeated.

3. The consensus method in a multi-party frequent service transaction scenario based on blockchain according to claim 1 is characterized in that: In step (5), the format of the information tag is "business number + service provider number - block number".

4. The consensus method in a multi-party frequent service transaction scenario based on blockchain according to claim 1 is characterized in that: The consensus method further includes that after step (7) is completed, if there are still unconsensus blocks, jump to step (4) to perform the next round of election, consensus and broadcast until there are no unbroadcast blocks.

5. A consensus device in a blockchain-based multi-party frequent service transaction scenario, comprising a memory and one or more processors, wherein the memory stores executable code, and when the one or more processors execute the executable code, they are used to implement the consensus method in the blockchain-based multi-party frequent service transaction scenario described in any one of claims 1-4.

6. A computer-readable storage medium having a program stored thereon, which, when executed by a processor, is used to implement the consensus method in the blockchain-based multi-party frequent service transaction scenario described in any one of claims 1-4.

Images