Consensus authentication method and device based on block chain, electronic equipment and program product

Abstract

The invention discloses a block chain-based consensus authentication method and device, electronic equipment and a program product, and relates to the technical field of block chains, and the method comprises the steps: generating a pre-preparation message based on a financial transaction request initiated by a client through a main node, and broadcasting the pre-preparation message to all consensus nodes, part of preparation messages returned by consensus nodes are received through a main node, signatures in the part of preparation messages are aggregated into batch signatures under the condition that the validity verification of the messages is passed, submission information is generated based on the batch signatures, and the submission information is broadcasted to all the consensus nodes. And counting the number of the consensus nodes which pass verification of the aggregated batch signatures, and completing the consensus authentication process of the current batch transaction under the condition that the number of the consensus nodes reaches a preset node number threshold value. According to the method and the device, the technical problems of low consensus efficiency and complex verification process when the alliance chain adopts a batch processing signature mechanism to perform batch processing in a high-concurrency transaction processing scene in the related technology are solved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology or other related fields, and specifically to a consensus authentication method and device, electronic equipment, and program product based on blockchain. Background Art

[0002] In consortium blockchains, consensus mechanisms are key technologies for ensuring transaction validity and network stability. Consensus algorithms are responsible for reaching consensus among network nodes and determining which transactions can be added to the blockchain. This directly impacts the performance of consortium chains, including transaction speed, throughput, latency, and resource consumption. Traditional blockchain consensus mechanisms, such as Proof of Work (PoW) and Proof of Stake (PoS), are inefficient in consortium blockchain scenarios and are unsuitable for high-frequency transaction processing.

[0003] In related technologies, batch signature mechanisms (such as PBFT, Practical Byzantine Fault Tolerance) combine multiple transactions received over a period of time into a single batch for unified processing. This mechanism can significantly reduce the number of signatures and communications required during transaction processing, particularly in high-concurrency scenarios. It can significantly improve the throughput and response speed of consortium chains, reduce network latency, and is currently a key direction for optimizing consortium chain consensus mechanisms. However, this batch signature mechanism involves a large number of inter-node message exchanges during the consensus process. Especially during the pre-prepare, prepare, and commit phases, multiple network-wide broadcasts and verifications are required. This can lead to a surge in network communication load when the number of nodes is large, significantly reducing consensus efficiency. Furthermore, since PBFT can only process one transaction per consensus round, in high-concurrency scenarios, a large number of pending transactions can accumulate, forming a transaction queue and impacting overall transaction processing speed. Furthermore, during the consensus process, each node needs to verify the signatures of other nodes. This verification process is complex and computationally intensive, especially when using standard multi-signature schemes.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0005] The embodiments of the present invention provide a consensus authentication method and device, electronic device, and program product based on blockchain, so as to at least solve the technical problems in the related technology that when the alliance chain adopts a batch signature mechanism for batch processing in high-concurrency transaction processing scenarios, the consensus efficiency is low and the verification process is complicated.

[0006] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a consensus authentication method based on blockchain is provided, which is applied to a blockchain network, wherein the blockchain network includes N blockchain nodes, and when each blockchain node serves as the master node corresponding to the block generation operation, the other N-1 blockchain nodes are consensus nodes, where N is a positive integer greater than 1, including: generating a pre-prepared message based on a financial transaction request initiated by a client by the master node, and broadcasting the pre-prepared message to all consensus nodes, wherein the pre-prepared message includes: multiple financial transaction requests, a block summary generated after aggregating the financial transaction content, and a signature result of the block summary, each of the consensus nodes The identification node generates preparation information after signing the block summary in the pre-prepare message; receives the partial preparation message returned by the consensus node through the master node, and when the message legitimacy verification is passed, aggregates the signatures in the partial preparation message into a batch signature, generates submission information based on the batch signature, and broadcasts the submission information to all consensus nodes, wherein the consensus node verifies the batch signature in the submission information after receiving the submission information; counts the number of consensus nodes that pass the verification of the aggregated batch signature, and completes the consensus authentication process for the current batch of transactions when the total number of consensus nodes that pass the signature verification reaches a first preset node number threshold.

[0007] Optionally, the step of generating a pre-prepared message based on a financial transaction request initiated by a client by the master node, and broadcasting the pre-prepared message to all consensus nodes includes: receiving multiple financial transaction requests initiated by the client by the master node, and performing a legitimacy verification on the multiple financial transaction requests; aggregating the financial transaction contents in the multiple financial transaction requests by the master node when the legitimacy verification of the financial transaction requests passes, and generating a target transaction block corresponding to the current batch of transactions; verifying the correctness of the target transaction block by the master node, and calculating a unified block summary for all financial transaction contents in the target transaction block when the correctness verification of the target transaction block succeeds; signing the block summary by the master node using a node private key to obtain a signature result; generating the pre-prepared message by the master node based on the block summary of the target transaction block and the signature result, and broadcasting the pre-prepared message to all consensus nodes.

[0008] Optionally, the step of calculating a unified block summary for all financial transaction contents in the target transaction block includes: calculating a leaf node corresponding to each financial transaction request in the target transaction block, generating a Merkle tree, and using the root node of the Merkle tree as the block summary; or; performing a hash calculation on the current batch of transactions corresponding to the target transaction block, and generating a batch block summary corresponding to the target transaction block based on the hash value corresponding to each financial transaction request.

[0009] Optionally, after broadcasting the pre-prepared message to all consensus nodes, it also includes: extracting the public key of the master node through each consensus node, and using the public key to verify the legitimacy of the block summary in the pre-prepared message, wherein the content of the legitimacy verification includes: format verification and transaction validity verification; when the legitimacy verification of the pre-prepared message passes, each consensus node uses a preset multi-signature strategy to sign the block summary based on its own private key; each consensus node generates a prepare message based on the summary signature result, and sends the prepare message to the master node.

[0010] Optionally, the preset multi-signature strategy is a MuSig multi-signature algorithm.

[0011] Optionally, the master node receives a partial prepare message returned by the consensus node, and if the message legitimacy verification passes, the signatures in the partial prepare message are aggregated into a batch signature, and the step of generating submission information based on the batch signature includes: counting the number of consensus nodes that return the prepare message by the master node, and if the number of consensus nodes exceeds a second preset node number threshold, using the public key of each consensus node to verify the legitimacy of the prepare message; if the message legitimacy verification passes, aggregating the signatures in the returned partial prepare message through a preset multi-signature strategy to obtain the batch signature; and generating the submission information based on the batch signature and transaction-related messages by the master node.

[0012] Optionally, after completing the consensus authentication process for the current batch of transactions, it also includes: submitting all financial transactions in the batch signatures to the state machine for execution through the consensus node in the order of the global serial numbers broadcast by the master node; and appending the generated target transaction block to the local ledger through the consensus node.

[0013] According to another aspect of an embodiment of the present invention, a consensus authentication device based on blockchain is provided, which is applied to a blockchain network, wherein the blockchain network includes N blockchain nodes, and when each blockchain node serves as a master node corresponding to a block generation operation, the other N-1 blockchain nodes are consensus nodes, where N is a positive integer greater than 1. The consensus authentication device based on blockchain includes: a pre-preparation unit, which is used to generate a pre-preparation message based on a financial transaction request initiated by a client through the master node, and broadcast the pre-preparation message to all consensus nodes, wherein the pre-preparation message includes: a plurality of the financial transaction requests, a block summary generated after aggregating the financial transaction content, and a signature result of the block summary, and each of the consensus nodes The node generates preparation information after signing the block summary in the pre-prepare message; a submission information generation unit is used to receive the partial preparation message returned by the consensus node through the master node, and when the message legitimacy verification is passed, aggregate the signatures in the partial preparation message into a batch signature, generate submission information based on the batch signature, and broadcast the submission information to all consensus nodes, wherein the consensus node verifies the batch signature in the submission information after receiving the submission information; the consensus unit is used to count the number of consensus nodes that have passed the verification of the aggregated batch signature, and complete the consensus authentication process for the current batch of transactions when the total number of consensus nodes that pass the signature verification reaches a first preset node number threshold.

[0014] Optionally, the pre-preparation unit includes: a transaction verification module, which is used to receive multiple financial transaction requests initiated by the client through the master node, and perform legitimacy verification on the multiple financial transaction requests; a first aggregation module, which is used to aggregate the financial transaction contents in the multiple financial transaction requests through the master node if the legitimacy verification of the financial transaction requests is passed, and generate a target transaction block corresponding to the current batch of transactions; a block verification module, which is used to verify the correctness of the target transaction block through the master node, and if the correctness verification of the target transaction block is successful, calculate a unified block summary for all financial transaction contents in the target transaction block; a summary signature module, which is used to sign the block summary using the node private key through the master node to obtain a signature result; a pre-prepared message generation module, which is used to generate the pre-prepared message based on the block summary of the target transaction block and the signature result through the master node, and broadcast the pre-prepared message to all consensus nodes.

[0015] Optionally, the block verification module includes: a first block summary generation module, used to calculate the leaf node corresponding to each financial transaction request in the target transaction block, generate a Merkle tree, and use the root node of the Merkle tree as the block summary; or; a second block summary generation module, used to perform hash calculation on the current batch of transactions corresponding to the target transaction block, and generate a batch block summary corresponding to the target transaction block based on the hash value corresponding to each financial transaction request.

[0016] Optionally, the blockchain-based consensus authentication device also includes: a master node public key extraction unit, which is used to extract the public key of the master node through each consensus node after broadcasting the pre-prepared message to all consensus nodes, and use the public key to verify the legitimacy of the block summary in the pre-prepared message, wherein the content of the legitimacy verification includes: format verification and transaction validity verification; a multi-signature unit, which is used to sign the block summary based on its own private key by each consensus node using a preset multi-signature strategy when the legitimacy verification of the pre-prepared message passes; a preparation message generation unit, which is used to generate a preparation message based on the summary signature result by each consensus node, and send the preparation message to the master node.

[0017] Optionally, the preset multi-signature strategy is a MuSig multi-signature algorithm.

[0018] Optionally, the submission information generation unit includes: a prepare message legitimacy verification module, which is used to count the number of consensus nodes that return the prepare message through the master node, and when the number of consensus nodes exceeds a second preset node number threshold, use the public key of each consensus node to verify the legitimacy of the prepare message; a signature aggregation module, which is used to aggregate the signatures in the returned partial prepare message through a preset multi-signature strategy to obtain the batch signature when the message legitimacy verification passes; a submission information generation module, which is used to generate the submission information based on the batch signature and transaction-related message through the master node.

[0019] Optionally, the blockchain-based consensus authentication device also includes: a transaction execution unit, which is used to submit all financial transactions in the batch signatures to the state machine for execution in the order of the global serial numbers broadcast by the master node through the consensus node after completing the consensus authentication process for the current batch of transactions; and a block appending unit, which is used to append the generated target transaction block to the local ledger through the consensus node.

[0020] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is also provided, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned blockchain-based consensus authentication methods.

[0021] According to another aspect of an embodiment of the present invention, an electronic device is also provided, comprising one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the above-mentioned blockchain-based consensus authentication methods.

[0022] According to another aspect of an embodiment of the present invention, a computer program product is also provided, including a computer program, which, when executed by a processor, implements the steps of any one of the above-mentioned blockchain-based consensus authentication methods.

[0023] In the present disclosure, a pre-prepared message can be generated by a master node based on a financial transaction request initiated by a client, and the pre-prepared message can be broadcast to all consensus nodes, wherein the pre-prepared message includes: multiple financial transaction requests, a block summary generated after aggregating the financial transaction content, and a signature result of the block summary. Each consensus node generates preparation information after signing the block summary in the pre-prepared message; the master node receives part of the preparation message returned by the consensus node, and when the message legitimacy verification passes, the signature in the part of the preparation message is aggregated into a batch signature, and submission information is generated based on the batch signature, and the submission information is broadcast to all consensus nodes. After receiving the submission information, the consensus node verifies the batch signature in the submission information, counts the number of consensus nodes that have passed the verification of the aggregated batch signature, and completes the consensus authentication process for the current batch transaction when the total number of consensus nodes that pass the signature verification reaches the first preset node number threshold.

[0024] Based on the above public content, multiple transaction requests from the client can be aggregated into a transaction batch through the master node (block generation node). The block summary generated by aggregating the financial transaction content of the entire batch and the signature result of the block summary are completed. The batch processing mechanism enables each consensus round to process more transactions, enhancing the system's ability to handle large-scale transactions. Combined with the aggregate signature mechanism (the verification of the aggregate signature is simplified to the verification of a batch signature), the number of messages broadcast across the entire network is greatly reduced, the network bandwidth occupancy is reduced, and the time to reach consensus is significantly shortened, thereby solving the technical problems in related technologies that when the alliance chain uses a batch signature mechanism for batch processing in high-concurrency transaction processing scenarios, the consensus efficiency is low and the verification process is complex. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0026] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a consensus authentication method based on blockchain is shown;

[0027] Figure 2 is a flowchart of an optional blockchain-based consensus authentication method according to an embodiment of the present invention;

[0028] Figure 3 is a schematic diagram of an optional blockchain-based consensus authentication device according to an embodiment of the present invention;

[0029] Figure 4 This is a structural block diagram of an electronic device that executes a blockchain-based consensus authentication method according to an embodiment of the present application. DETAILED DESCRIPTION

[0030] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0031] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention 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 numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" 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 clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0032] To facilitate those skilled in the art to understand the present invention, some of the terms or nouns involved in the embodiments of the present invention are explained below:

[0033] Practical Byzantine Fault Tolerance (PBFT) is a fault-tolerant consensus algorithm suitable for scenarios with high performance and security requirements, such as consortium blockchains. It ensures that the majority of nodes in the network can reach consensus even when some nodes fail or engage in malicious behavior. PBFT offers low communication complexity and high efficiency, making it particularly suitable for environments with a relatively fixed and controllable number of nodes, such as inter-enterprise consortium blockchain networks.

[0034] The MuSig multiple signature algorithm, also known as MuSig Multiple Signatures (MuSig), is a multi-signature protocol that generates a single signature generated by the private keys of multiple participants, corresponding to a single public key. This signature mechanism improves security and efficiency, particularly in scenarios requiring verification or signatures by multiple participants, such as blockchain transactions. By reducing the number of signatures and increasing the parallelism of the signing process, MuSig reduces communication and computational costs, thereby improving overall system performance.

[0035] The Batch Signature Mechanism allows for batch processing of multiple transaction requests within a consensus round, rather than generating and verifying signatures for each transaction individually. By generating a unified summary representing the transaction batch and signing the entire batch with a single aggregate signature, this mechanism reduces the number of signatures and verifications, thereby lowering communication and computational overhead and improving consensus throughput and efficiency.

[0036] It should be noted that the blockchain-based consensus authentication method and device thereof in the present disclosure can be used in the field of blockchain technology. When financial transaction consensus authentication is implemented based on a multi-signature mechanism, it can also be used in any field other than the field of blockchain technology. When financial transaction consensus authentication is implemented based on a multi-signature mechanism, the present disclosure does not limit the application field of the blockchain-based consensus authentication method and device thereof.

[0037] It should be noted that the information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) collected by this disclosure are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or institution through the interface, and obtain relevant information after receiving the consent information fed back by the aforementioned user or institution.

[0038] It should be noted that in this disclosure, when collecting and analyzing customer information, the corresponding operation entrance is provided for users to choose to agree or reject the automated decision-making results; if the user chooses to reject, the expert decision-making process will be entered.

[0039] The following embodiments of the present invention can be applied to various blockchain-based consensus authentication systems, applications, and devices. This invention can be applied to consortium blockchain environments within the financial industry, as well as any distributed system requiring efficient consensus mechanisms and secure transaction processing. Specific application scenarios include, but are not limited to, interbank clearing and settlement, supply chain finance, asset securitization, insurance claims, and cross-border payments. These scenarios involve high transaction volumes and numerous participants, placing extremely high demands on system throughput, latency, and security.

[0040] By integrating a multi-signature algorithm with a batch processing mechanism, this invention significantly improves the consensus efficiency and overall performance of consortium chains. Compared to the traditional PBFT consensus algorithm, this invention only broadcasts messages once during the pre-prepare and commit phases, significantly reducing the number of communications between nodes, alleviating bandwidth pressure in large-scale networks, and improving system communication efficiency. Furthermore, by generating an aggregate signature through the multi-signature algorithm, the process that originally required multiple signatures and verifications is simplified to a single one, significantly reducing the computational complexity of signature generation and verification and accelerating the speed of consensus.

[0041] Furthermore, the batch processing mechanism provided by this invention allows the system to process more transactions within a single consensus round. Combined with parallelized signature processing, this significantly improves the consortium chain's ability to process transactions per second, enabling rapid response times under high concurrency demands. Even with an increase in the number of network nodes, this invention maintains stable and efficient consensus performance, reduces system overhead, and enhances support for large-scale distributed networks.

[0042] The block generation node (i.e., master node) in this invention aggregates multiple transaction requests from clients into a single transaction batch. By calculating a unified summary (such as a Merkle root or hash value) for the entire batch, it effectively represents and manages batch transactions, significantly reducing the amount of information required for each consensus round and improving processing efficiency. The introduction of a batch signature mechanism uses a multi-signature algorithm to generate an aggregate signature for the transaction batch. This not only reduces the number of signatures but also simplifies the signature generation and verification process. In particular, by parallelizing the generation of signature shares and asynchronous reporting, it avoids delays caused by serial waiting and greatly improves the efficiency of signature generation.

[0043] Each consensus node starts generating parallel temporary signature shares immediately after receiving the block summary. This can be done simultaneously on all nodes, effectively utilizing the parallel computing resources in the network. The signature shares generated by each node can be sent to the master node asynchronously without waiting for all nodes to complete. This means that even in high-concurrency scenarios, the first batch of generated shares can start the aggregation process as early as possible, further shortening the consensus latency.

[0044] The present invention will be described in detail below with reference to various embodiments.

[0045] Example 1

[0046] According to an embodiment of the present invention, an embodiment of a consensus authentication method based on blockchain is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in an order different from that shown here.

[0047] The blockchain-based consensus authentication method embodiment provided in Example 1 of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The following is a hardware block diagram of a computer terminal (or mobile device) for implementing a consensus authentication method based on blockchain. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more ( Figure 1The computer 102 includes a processor 102 (the processor 102 may include but is not limited to a microcontroller unit (MCU) or a programmable logic device (FPGA)), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, the computer 102 may include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS), a network interface, a power supply, and / or a camera. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0048] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry". The data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuitry may be a single independent processing module, or may be incorporated in whole or in part into any of the other components of the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuitry serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0049] Memory 104 can be used to store software programs and modules for application software, such as the program instructions / data storage device corresponding to the blockchain-based consensus authentication method in the embodiments of the present application. Processor 102 executes the software programs and modules stored in memory 104 to perform various functional applications and data processing, thereby implementing the above-mentioned blockchain-based consensus authentication method. Memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 104 may further include memory remotely located relative to processor 102, and these remote memories may be connected to computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0050] The transmission device 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of the computer terminal 10. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is configured to communicate with the Internet wirelessly.

[0051] The display may be, for example, a touch screen liquid crystal display (LCD), which enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0052] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a blockchain-based consensus authentication method is provided, which is applied to a blockchain network. The blockchain network includes N blockchain nodes. When each blockchain node serves as the master node corresponding to the block generation operation, the other N-1 blockchain nodes are consensus nodes, and N is a positive integer greater than 1.

[0053] At any given moment, a client-initiated financial transaction request is received. The node to be used for batch transaction consensus verification is selected as the master node responsible for block generation operations, while the remaining N-1 blockchain nodes play the role of consensus nodes, jointly participating in the block verification and consensus process. Among them, the master node (also known as the block generation node) is responsible for block proposal and preliminary verification, as well as initiating tasks in the subsequent pre-preparation phase. After receiving the transaction request, the master node aggregates these requests to form a transaction batch and calculates a unified summary or representation of the batch, such as a Merkle tree root or hash value. The main responsibility of the consensus node is to verify the block summary proposed by the master node. Once the verification is passed, the MuSig multi-signature algorithm is immediately used to generate temporary signature shares for the batch. This embodiment allows all consensus nodes to calculate individual signature shares simultaneously, and then asynchronously send these shares to the master node or other designated signature aggregation nodes without waiting for all nodes to complete, thereby significantly reducing the waiting time before consensus is reached and improving the system response speed.

[0054] Under the above operating environment, this application provides Figure 2 The blockchain-based consensus authentication method shown. Figure 2 is a flowchart of an optional blockchain-based consensus authentication method according to an embodiment of the present invention, such as Figure 2 As shown, the method includes the following steps:

[0055] In step S201, the master node generates a pre-prepare message based on the financial transaction request initiated by the client, and broadcasts the pre-prepare message to all consensus nodes. The pre-prepare message includes: multiple financial transaction requests, a block digest generated by aggregating the financial transaction content, and a signature result of the block digest. Each consensus node generates preparation information after signing the block digest in the pre-prepare message.

[0056] In this embodiment, step S201 involves a block generation node (referred to as a master node) generating a pre-prepared message based on a financial transaction request from a client and broadcasting this pre-prepared message to all consensus nodes. The master node receives and aggregates multiple transaction requests from clients, integrating them into a single batch, significantly improving the efficiency of each round of consensus processing and reducing network communication and processing overhead. The block digest generated by aggregating the financial transaction content ensures that the status of the entire transaction batch can be quickly and accurately represented even when the number of transactions increases. The generation of the block digest facilitates operations in the subsequent signing phase. After generating the block digest, the master node uses a multi-signature algorithm to sign the block digest and generate a signature result.

[0057] Optionally, the steps of generating a pre-prepared message based on a financial transaction request initiated by a client by a master node and broadcasting the pre-prepared message to all consensus nodes include: receiving multiple financial transaction requests initiated by the client by the master node, and performing a legitimacy verification on the multiple financial transaction requests; aggregating the financial transaction contents in the multiple financial transaction requests by the master node when the legitimacy verification of the financial transaction requests is passed, and generating a target transaction block corresponding to the current batch of transactions; verifying the correctness of the target transaction block by the master node, and calculating a unified block summary for all financial transaction contents in the target transaction block when the correctness verification of the target transaction block is successful; signing the block summary by the master node using the node private key to obtain a signature result; generating a pre-prepared message by the master node based on the block summary of the target transaction block and the signature result, and broadcasting the pre-prepared message to all consensus nodes.

[0058] In this embodiment, the master node receives multiple financial transaction requests from clients and performs a validity check on each transaction request to ensure compliance with pre-set transaction rules and requirements. This validation may include, but is not limited to, checking the reasonableness of the transaction amount, the legitimacy of the accounts of both parties involved in the transaction, the validity of the transaction time, and the correctness of the transaction request data format. This validation is key to ensuring transaction security and network stability. By preemptively filtering out invalid or suspicious transaction requests, it can prevent resource waste in subsequent processing stages and improve overall network efficiency.

[0059] After financial transaction requests pass legality verification, the masternode aggregates the financial transaction content within these requests and generates the target transaction block corresponding to the current batch of transactions. The batching mechanism allows the masternode to combine multiple transaction requests into a single block. This not only physically consolidates the transaction requests but also optimizes the integration of logic and data structures. By calculating a unified block digest, such as the Merkle tree root or block hash value, the masternode accurately represents the transaction content of the batch, providing critical information support for subsequent consensus and signature generation. This increases the transaction volume per consensus round and provides efficient support for high-concurrency transaction processing scenarios.

[0060] Optionally, the step of calculating a unified block summary for all financial transaction contents in the target transaction block includes: calculating a leaf node corresponding to each financial transaction request in the target transaction block, generating a Merkle tree, and using the root node of the Merkle tree as the block summary; or; performing a hash calculation on the current batch of transactions corresponding to the target transaction block, and generating a batch block summary corresponding to the target transaction block based on the hash value corresponding to each financial transaction request.

[0061] This embodiment provides two strategies for generating block digests. The first involves generating a Merkle tree and calculating the root node as the block digest. This involves generating a hash value for each financial transaction request within the block, corresponding to a leaf node in the Merkle tree. Subsequently, through a series of hash operations, the Merkle tree is gradually constructed until the root node is reached. This root node serves as the digest for the target transaction block, uniquely identifying all transactions in that batch and enabling efficient transaction verification. The integrity of any transaction within the block can be verified by comparing it with the hash values along the tree path. The second strategy generates a block digest based on the hash values of batched transactions. This strategy directly hashes the current batch of transactions within the target transaction block, generating a hash value representing the batch. This hash value, serving as the block digest, can also be used to verify the integrity of all transactions within the block. However, this method is more direct, avoids the overhead of building a Merkle tree, and may be more suitable for certain high-performance scenarios.

[0062] After the transaction content is aggregated, the master node needs to verify the correctness of the generated target transaction block to ensure the integrity and correctness of the block content. This verification can include secondary verification of transaction data, checking the integrity of the block structure, and ensuring that all transaction requests are correctly included in the target block. After the correctness of the target transaction block is successfully verified, the master node will use the node private key to sign the block summary, generating a preliminary signature result.

[0063] Finally, the master node generates a pre-prepared message based on the block summary and signature result of the target transaction block. The master node then broadcasts the pre-prepared message to all consensus nodes to ensure that each node in the network can obtain the information and preliminary signature of the target transaction block for subsequent consensus decision-making and signature share generation.

[0064] Optionally, after broadcasting the pre-prepared message to all consensus nodes, it also includes: extracting the public key of the master node through each consensus node, and using the public key to verify the legitimacy of the block summary in the pre-prepared message, wherein the legitimacy verification includes: format verification and transaction validity verification; when the legitimacy verification of the pre-prepared message passes, each consensus node uses a preset multi-signature strategy to sign the block summary based on its own private key; each consensus node generates a prepare message based on the summary signature result, and sends the prepare message to the master node.

[0065] After the master node broadcasts the pre-prepared message to all consensus nodes, each consensus node first extracts the master node's public key (each blockchain node participating in the aggregate signature pre-publishes its public key) to verify the legitimacy of the block digest in the pre-prepared message. This legitimacy verification includes two main aspects: first, message format verification, ensuring that the message structure conforms to the protocol specifications; second, transaction validity verification, confirming that transactions within the block comply with the consortium chain's business rules, such as sufficient account balances and transaction compliance.

[0066] After verification, the consensus node uses a pre-set multi-signature strategy to sign the block digest using its own private key. After signing, the consensus node sends the digest signature back to the master node as part of the prepare message. Optionally, the pre-set multi-signature strategy is the MuSig multi-signature algorithm. The MuSig algorithm's advantage lies in its ability to generate a single signature representing all signers, which can be verified by a verifier using the public key of any individual signer. This algorithm is implemented through the following steps: Public key aggregation: First, the public keys of all participating nodes are sorted and aggregated to generate an aggregated public key representing all public keys. Temporary signature share generation: Each consensus node independently generates a temporary signature share based on its own private key and the block digest in the prepare message. Digest signature aggregation: The master node collects the signature shares of all consensus nodes and aggregates them into a complete block digest signature using the MuSig algorithm. Aggregated signatures are equivalent to standard Schnorr signatures, offering the same verification efficiency and security. The consensus node includes the generated signature share in the prepare message and sends it asynchronously to the master node without waiting for all nodes to complete the signature, thereby improving the parallelism and efficiency of the consensus process.

[0067] Step S202: The master node receives a partial prepare message returned by the consensus node. If the message is legitimate, the signatures in the partial prepare message are aggregated into a batch signature. A commit message is generated based on the batch signature, and the commit message is broadcast to all consensus nodes. After receiving the commit message, the consensus node verifies the batch signature in the commit message.

[0068] Optionally, a partial prepare message returned by the consensus node is received through the master node, and if the legitimacy of the message is verified, the signatures in the partial prepare message are aggregated into a batch signature, and the step of generating submission information based on the batch signature includes: counting the number of consensus nodes that return the prepare message through the master node, and if the number of consensus nodes exceeds a second preset node number threshold, using the public key of each consensus node to verify the legitimacy of the prepare message; if the legitimacy of the message is verified, aggregating the signatures in the returned partial prepare message through a preset multi-signature strategy to obtain the batch signature; and generating submission information based on the target batch signature result and the transaction-related message through the master node.

[0069] In this embodiment, after the consensus node completes signing the block digest, the master node receives the partial prepare message returned by the consensus node through step S202. The consensus node sends the signature share and related preparation information (i.e., the partial prepare message) back to the master node. After receiving these messages, the master node first counts the number of consensus nodes that have received the partial prepare message. This counting step ensures that a sufficient number of consensus nodes participate in the signing process to meet the preset fault tolerance and security requirements. The preset first node number threshold can be 2f+1 (where f is the maximum number of nodes that may fail or be malicious in the network). This ensures that even when malicious behavior exists in the network, consensus can be reached through the correct behavior of the majority of nodes.

[0070] Once the number of consensus nodes reaches a pre-set threshold, the master node uses the public keys of each consensus node to verify the legitimacy of the returned partial prepare message. This verification process includes checking the integrity of the message content and the validity of the signature sent by the consensus node. Specifically, the master node verifies that the prepare message is formatted correctly and that the signature of the consensus node matches the corresponding public key.

[0071] When the message legitimacy verification passes, the master node starts the signature aggregation process and aggregates the signatures in some prepared messages into batch signatures. The aggregation process is based on a preset multi-signature strategy (such as the MuSig multi-signature algorithm), which integrates multiple independent signature shares into a unified signature representing the entire transaction batch, ensuring that the aggregated signature has the same verification strength as a single signature. At the same time, since the number of signatures is reduced, the network communication overhead and the node's computational burden are also reduced.

[0072] Based on the aggregated batch signature results, the master node further generates a submission message. The submission message contains not only the batch signature but also transaction-related information such as the node bitmap. The master node then broadcasts the submission message to all consensus nodes. This broadcast action marks the key transition from signature generation to consensus confirmation in the consensus process. After receiving the submission message, all consensus nodes will verify the batch signature to confirm whether there are any inconsistencies or abnormalities.

[0073] It should be noted that the specific steps of MuSig signature aggregation include: public key aggregation: The master node collects the public keys of all participating nodes, arranges and integrates them in a pre-set order, and generates an aggregated public key representing all nodes. Signature share merging: The master node combines the signature shares received from the partial prepare messages and calculates a batch signature using the specific formula of the MuSig algorithm. This calculation relies on the signatures of all participating nodes and the aggregated public key, ensuring the accuracy and unforgeability of the final signature. Commit message generation: The master node generates a commit message containing all necessary information based on the calculated batch signature results and, if included, the node bitmap and other transaction metadata. The node bitmap can be used to identify the participating nodes in the signing process, helping the recipient confirm the legitimacy of the signature.

[0074] Step S203: Count the number of consensus nodes that have passed the verification of the aggregated batch signatures. When the total number of consensus nodes that have passed the signature verification reaches a first preset node number threshold, the consensus authentication process for the current batch of transactions is completed.

[0075] In this embodiment, after the master node completes the generation of the batch signature and broadcasts it to all consensus nodes by submitting information, each consensus node begins to verify the received batch signature. The verification process involves checking the validity of the signature, whether the signature matches the aggregated public key, and whether the signature correctly reflects the content of the batch transaction.

[0076] When the total number of consensus nodes that have passed signature verification reaches the first preset node number threshold, the consensus authentication process for the batch signature is completed. It should be noted that the first preset node number threshold can be set arbitrarily (to ensure that even if some nodes have problems, the decision-making of the entire network can still be effectively guaranteed). For example, it can be set to more than two-thirds of the total number of consensus nodes in the network (2f+1, where f represents the maximum number of potentially failed or malicious nodes in the network). This is because the consensus mechanism of the consortium chain needs to ensure that even if there is a certain proportion of failed or malicious nodes in the network, the network can still operate normally and maintain data integrity and consistency. Reaching this threshold means that the majority of nodes have confirmed the correctness of the signature, and it can be safely determined that the batch of transactions has passed the consensus process and met the network confirmation standard.

[0077] By setting and reaching a first preset node number threshold to complete consensus authentication, this embodiment not only improves the decision-making efficiency of the consortium chain when processing transactions, but also strengthens the security and robustness of the network. Compared with the traditional node-by-node verification mechanism, this method significantly reduces the time required to confirm transactions and the amount of network communication, lowering operating costs. It also ensures that the system can continue to operate normally even in the event of network attacks or failures, protecting the interests of all parties involved.

[0078] Optionally, after completing the consensus authentication process for the current batch of transactions, it also includes: submitting all financial transactions in the batch signature to the state machine for execution through the consensus node in the order of the global serial numbers broadcast by the master node; and appending the generated target transaction block to the local ledger through the consensus node.

[0079] After the consensus authentication process is complete, all financial transactions in the batch signature are submitted to the state machine for execution in the order of transaction processing through the consensus node, thereby ensuring the determinism and consistency of transactions. State machine execution is a key step in ensuring the correctness of state updates in the consortium chain architecture. The transaction processing order can prevent conflicts and inconsistencies during transaction execution, ensuring the correctness of fund flows and the complete execution of transaction logic.

[0080] Once a transaction is confirmed, the consensus node adds the newly generated transaction block to its local ledger, updating the entire ledger to reflect the latest transaction status. This update process is distributed, with each consensus node executing independently. Ultimately, the consensus mechanism ensures the consistency of all node ledgers. After the ledger is updated, all participating nodes will have the same transaction record, increasing the transparency and credibility of the system.

[0081] That is, once the consensus node verifies the aggregate signature, it can be considered that the transaction batch has reached consensus. The consensus node then submits all transactions in the batch to the state machine for execution in the order of the global sequence numbers broadcast by the master node, and appends the new transaction block to the local ledger.

[0082] It should be noted that to ensure consistency across the entire network, each node must check whether there is a submitted batch with the same serial number in its local log before submitting a transaction. If so, it will be executed directly; if not, it will wait for network synchronization.

[0083] At the same time, the embodiments of the present invention also introduce a zero-knowledge proof-assisted verification mechanism. By counting the number of consensus nodes that have successfully verified the aggregated batch signature, the consensus authentication process for the current batch of transactions is completed when the total number of consensus nodes that have passed signature verification reaches a first preset node number threshold. This ensures that the aggregate signature is indeed generated by a sufficient number of consensus nodes without exposing the specific signatory information. When all nodes complete the execution of the batch, the system automatically enters the next consensus round and continues to process subsequent transaction batches.

[0084] This embodiment significantly improves transaction processing efficiency by combining a batch processing mechanism with the MuSig multi-signature algorithm. The client node confirms that the transaction request has been confirmed by the network through a counting mechanism, avoiding the traditional transaction-by-transaction confirmation method, reducing waiting time, and improving user experience.

[0085] Through the above steps, a pre-prepared message can be generated by the master node based on the financial transaction request initiated by the client, and the pre-prepared message can be broadcast to all consensus nodes, wherein the pre-prepared message includes: multiple financial transaction requests, a block summary generated after aggregating the financial transaction content, and a signature result of the block summary. Each consensus node generates preparation information after signing the block summary in the pre-prepared message; the master node receives part of the preparation message returned by the consensus node, and when the legitimacy of the message is verified, the signature in the part of the preparation message is aggregated into a batch signature, and submission information is generated based on the batch signature. The submission information is broadcast to all consensus nodes, and the number of consensus nodes that have passed the verification of the aggregated batch signature is counted. When the total number of consensus nodes that pass the signature verification reaches the first preset node number threshold, the consensus authentication process for the current batch transaction is completed. Complete the consensus authentication process for the current batch of transactions. In this embodiment, the master node (block generation node) can aggregate multiple transaction requests from the client into a transaction batch. The block summary generated by aggregating the financial transaction content of the entire batch and the signature result of the block summary are completed. The batch processing mechanism enables each consensus round to process more transactions, enhances the system's ability to handle large-scale transactions, and combines with the aggregate signature mechanism (the verification of the aggregate signature is simplified to the verification of a batch signature), greatly reducing the number of messages broadcast across the entire network, reducing the network bandwidth usage, and significantly shortening the time to reach consensus, thereby solving the technical problems in related technologies of low consensus efficiency and complex verification process when the batch signature mechanism is used for batch processing in high-concurrency transaction processing scenarios.

[0086] The following describes in detail another optional specific implementation.

[0087] Compared with existing solutions, the PBFT solution reduces the signature size in a single round of consensus, but it still faces performance bottlenecks when facing massive transactions and large-scale node deployment: the communication load is still high, the transaction volume processed by a single round of consensus is limited, and the signature generation process usually needs to be completed synchronously, resulting in increased consensus latency. The present invention proposes a consortium chain consensus optimization method based on the MuSig multi-signature and batch processing mechanism. By batch processing transaction requests and parallelizing signature calculations, the number of consensus rounds is reduced, and the communication and verification overhead is reduced, thereby improving system throughput and resource utilization in large-scale networks. At the same time, it supports parallel node signatures and asynchronous processing of some signatures to significantly reduce communication load, improve signature verification efficiency, and enhance overall consensus throughput.

[0088] To achieve the above object, the present invention proposes the following technical solutions:

[0089] 1. Transaction Request Aggregation: The system consists of one block generation node (master node) and N-1 consensus nodes. The block generation node receives multiple transaction requests from clients, aggregates these transactions into a batch, and calculates a unified block digest for all transactions in the batch (for example, using a Merkle root or hash aggregation to generate a batch digest) to uniquely identify the batch.

[0090] 2. Pre-Prepare phase: The block generation node broadcasts the block digest of the transaction batch to all consensus nodes via the Pre-Prepare message. During this phase, the master node can sign the digest itself (e.g., using its private key as the first step of MuSig signing), but the main purpose is to ensure that all nodes have the same information about the batch to be agreed upon.

[0091] 3. Prepare Phase: After receiving the block digest, each consensus node first verifies the digest's legitimacy (verifying format and transaction validity). Once verified, the node uses the MuSig multi-signature scheme to generate partial signatures for the batch of digests in parallel. Specifically, each node uses its private key to generate a signature share for the digest (signature random numbers can be generated in parallel) and, after completing the signature calculation locally, immediately and asynchronously sends the signature share to the master node (or designated signature aggregation node). All consensus nodes can perform signature calculations in parallel, without waiting for other nodes to complete, fully utilizing parallel computing resources to reduce signature latency.

[0092] 4. Commit Phase: After receiving at least 2f+1 valid signature shares, the masternode uses the MuSig algorithm to aggregate these partial signatures into a complete batch signature (this aggregate signature is equivalent to a standard Schnorr signature). The masternode broadcasts this final aggregate signature and related information (such as the signer bitmap) to all consensus nodes via a Commit message. Upon receipt, each consensus node verifies the aggregate signature. Since the verification process for an aggregate signature is the same as for a standard single signature, nodes only need to verify it once to confirm the signature is valid.

[0093] 5. Consensus and Execution: Once the consensus node verifies the aggregate signature, consensus is reached for the transaction batch. The node then submits all transactions in the batch to the state machine for execution, following the global sequence number broadcast by the master node, and appends the new block to the local ledger. To ensure network-wide consistency, each node checks its local log for a submitted batch with the same sequence number before submitting a transaction. If so, the transaction is executed directly; otherwise, it waits for network synchronization.

[0094] It should be noted that this embodiment of the present invention also incorporates a zero-knowledge proof-assisted verification mechanism. By counting the number of consensus nodes that have successfully verified the aggregated batch signature, the consensus authentication process for the current batch of transactions is completed when the total number of consensus nodes that have passed signature verification reaches a first preset node threshold. This ensures that the aggregate signature is indeed generated by a sufficient number of consensus nodes without revealing the specific signatory information. Once all nodes have completed execution of the batch, the system automatically enters the next consensus round and continues processing subsequent transaction batches.

[0095] Through the above-mentioned batch signature mechanism, first, batch processing is introduced in the transaction collection stage, and multiple concurrent transaction requests are packaged into a consensus batch to increase the transaction volume of each round of consensus processing; secondly, the MuSig signature mechanism is retained in the Prepare stage, and each node generates a signature share of the batch summary in parallel and reports it asynchronously, and the multi-round signature feature of MuSig is used to realize signature parallelization; then in the Commit stage, the master node aggregates the signature and broadcasts it, replacing the repeated broadcast of multiple signatures between nodes in the traditional PBFT. It fully utilizes the single signature feature of MuSig and the batching feature of transactions: on the one hand, multiple transactions use one aggregate signature to complete consensus, which significantly reduces the number of signatures and the amount of communication messages; on the other hand, nodes generate signature shares in parallel and asynchronously and report them in a timely manner to avoid delays caused by serial waiting. The present invention achieves a significant improvement in the efficiency of signature and verification in the consensus process through the deep integration of batch processing and MuSig aggregation, and reduces system overhead when deployed on a large scale.

[0096] This solution effectively addresses the inefficiency of PBFT consensus in large-scale consortium blockchain environments by introducing a batch signature mechanism and MuSig aggregate signatures. First, the communication overhead is significantly reduced: the total communication overhead of traditional PBFT in the three-phase process is polynomial, while with aggregate signatures, the communication complexity is approximately linear. This solution only requires broadcasting the digest and aggregate signature messages once each during the Pre-Prepare and Commit phases, which are then collected and forwarded by the master node. This significantly reduces the number of inter-node broadcasts, thereby alleviating network bandwidth pressure.

[0097] Secondly, the efficiency of signing and verification is significantly improved: traditional PBFT requires each node to broadcast and verify 2f+1 independent signatures, while this scheme only needs to verify the aggregate signature once per round. Since the signature generated by MuSig is equivalent to an ordinary single signature, the node only needs to perform a single signature verification with constant complexity, which reduces the computational complexity of signature verification.

[0098] Thirdly, system throughput has been significantly improved: the batching mechanism doubles the number of transactions processed in each consensus round, and combined with parallelized signature processing, this significantly increases the number of transactions that can be confirmed per second. Related research has shown that an improved PBFT solution based on aggregate signature optimization can increase throughput by 65.7% and reduce latency by 38.9% in multi-node scenarios, fully validating the optimization effects of aggregate signatures and batching.

[0099] This invention maintains high throughput and low consensus latency even as node scale increases, significantly enhancing the system's adaptability and scalability to large-scale consortium chains. Compared to existing PBFT, this invention significantly reduces the number of messages and signatures required for consensus through innovations in batch signatures and parallel processing, achieving efficient communication and optimized computing performance.

[0100] The following describes it in detail with reference to another embodiment.

[0101] Example 2

[0102] A blockchain-based consensus authentication device provided in this embodiment includes multiple implementation units, each of which corresponds to each implementation step in the above-mentioned embodiment 1. Its specific implementation methods and beneficial effects can be referred to the above-mentioned method embodiments and will not be repeated here.

[0103] According to another aspect of an embodiment of the present invention, a blockchain-based consensus authentication device is also provided, which is applied to a blockchain network. The blockchain network includes N blockchain nodes. When each blockchain node serves as a master node corresponding to a block generation operation, the other N-1 blockchain nodes are consensus nodes, and N is a positive integer greater than 1.

[0104] Figure 3is a schematic diagram of an optional consensus authentication device based on blockchain according to an embodiment of the present invention, such as Figure 3 As shown, the blockchain-based consensus authentication device may include: a pre-preparation unit 31, a submission information generation unit 32, and a consensus unit 33.

[0105] Among them, the pre-preparation unit 31 is used to generate a pre-preparation message based on the financial transaction request initiated by the client through the master node, and broadcast the pre-preparation message to all consensus nodes. The pre-preparation message includes: multiple financial transaction requests, a block summary generated after aggregating the financial transaction content, and a signature result of the block summary. Each consensus node generates preparation information after signing the block summary in the pre-preparation message.

[0106] The submission information generation unit 32 is used to receive the partial preparation message returned by the consensus node through the master node, aggregate the signatures in the partial preparation message into batch signatures when the message legitimacy verification is passed, generate submission information based on the batch signatures, and broadcast the submission information to all consensus nodes.

[0107] The consensus unit 33 is used to count the number of consensus nodes that have passed the verification of the aggregated batch signatures, and complete the consensus authentication process for the current batch of transactions when the total number of consensus nodes that have passed the signature verification reaches a first preset node number threshold.

[0108] The above-mentioned blockchain-based consensus authentication device can generate a pre-preparation message based on the financial transaction request initiated by the client through the pre-preparation unit 31 through the master node, and broadcast the pre-preparation message to all consensus nodes, wherein the pre-preparation message includes: multiple financial transaction requests, a block summary generated after aggregating the financial transaction content, and a signature result of the block summary. Each consensus node generates preparation information after signing the block summary in the pre-preparation message, and receives the partial preparation message returned by the consensus node through the master node through the submission information generation unit 32. When the message legitimacy verification passes, the signature in the partial preparation message is aggregated into a batch signature, and submission information is generated based on the batch signature. The submission information is broadcast to all consensus nodes. The consensus unit 33 counts the number of consensus nodes that have passed the verification of the aggregated batch signature. When the total number of consensus nodes that pass the signature verification reaches the first preset node number threshold, the consensus authentication process for the current batch transaction is completed. Complete the consensus authentication process for the current batch of transactions. In this embodiment, the master node (block generation node) can aggregate multiple transaction requests from the client into a transaction batch. The block summary generated by aggregating the financial transaction content of the entire batch and the signature result of the block summary are completed. The batch processing mechanism enables each consensus round to process more transactions, enhances the system's ability to handle large-scale transactions, and combines with the aggregate signature mechanism (the verification of the aggregate signature is simplified to the verification of a batch signature), greatly reducing the number of messages broadcast across the entire network, reducing the network bandwidth usage, and significantly shortening the time to reach consensus, thereby solving the technical problems in related technologies of low consensus efficiency and complex verification process when the batch signature mechanism is used for batch processing in high-concurrency transaction processing scenarios.

[0109] Optionally, the pre-preparation unit includes: a transaction verification module, which is used to receive multiple financial transaction requests initiated by the client through the master node, and perform legitimacy verification on the multiple financial transaction requests; a first aggregation module, which is used to aggregate the financial transaction contents in the multiple financial transaction requests through the master node when the legitimacy verification of the financial transaction requests is passed, and generate a target transaction block corresponding to the current batch of transactions; a block verification module, which is used to verify the correctness of the target transaction block through the master node, and when the correctness verification of the target transaction block is successful, calculate a unified block summary for all financial transaction contents in the target transaction block; a summary signature module, which is used to sign the block summary using the node private key through the master node to obtain a signature result; a pre-prepared message generation module, which is used to generate a pre-prepared message based on the block summary of the target transaction block and the signature result through the master node, and broadcast the pre-prepared message to all consensus nodes.

[0110] Optionally, the block verification module includes: a first block summary generation module, used to calculate the leaf node corresponding to each financial transaction request in the target transaction block, generate a Merkle tree, and use the root node of the Merkle tree as the block summary; or; a second block summary generation module, used to perform hash calculation on the current batch of transactions corresponding to the target transaction block, and generate a batch block summary corresponding to the target transaction block based on the hash value corresponding to each financial transaction request.

[0111] Optionally, the blockchain-based consensus authentication device also includes: a master node public key extraction unit, which is used to extract the public key of the master node through each consensus node after broadcasting the pre-prepared message to all consensus nodes, and use the public key to verify the legitimacy of the block summary in the pre-prepared message, wherein the content of the legitimacy verification includes: format verification and transaction validity verification; a multi-signature unit, which is used to sign the block summary based on its own private key by each consensus node using a preset multi-signature strategy when the legitimacy verification of the pre-prepared message passes; a prepare message generation unit, which is used to generate a prepare message based on the summary signature result by each consensus node, and send the prepare message to the master node.

[0112] Optionally, the preset multi-signature strategy is the MuSig multi-signature algorithm.

[0113] Optionally, the submission information generation unit includes: a prepare message legitimacy verification module, which is used to count the number of consensus nodes that return the prepare message through the master node, and when the number of consensus nodes exceeds a second preset node number threshold, use the public key of each consensus node to verify the legitimacy of the prepare message; a signature aggregation module, which is used to aggregate the signatures in the returned partial prepare message through a preset multi-signature strategy to obtain the batch signature when the message legitimacy verification passes; a submission information generation module, which is used to generate submission information based on the target batch signature result and the transaction-related message through the master node.

[0114] Optionally, the blockchain-based consensus authentication device also includes: a transaction execution unit, which is used to submit all financial transactions in the batch signature to the state machine for execution through the consensus node in the order of the global serial numbers broadcast by the master node after completing the consensus authentication process for the current batch of transactions; and a block attachment unit, which is used to attach the generated target transaction block to the local ledger through the consensus node.

[0115] The above-mentioned blockchain-based consensus authentication device may also include a processor and a memory. The above-mentioned pre-preparation unit 31, submission information generation unit 32, consensus unit 33, etc. are all stored in the memory as program units, and the processor executes the above-mentioned program units stored in the memory to realize the corresponding functions.

[0116] The aforementioned processor includes a kernel, which retrieves the corresponding program unit from the memory. One or more kernels can be configured, and by adjusting kernel parameters, consensus authentication for financial transactions based on a multi-signature algorithm can be achieved.

[0117] The above-mentioned memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0118] Example 3

[0119] An embodiment of the present application may provide an electronic device, Figure 4 This is a structural block diagram of an electronic device that executes a consensus authentication method based on blockchain according to an embodiment of the present application. Figure 4 As shown, the electronic device may include: one or more ( Figure 4 Only one is shown) processor 402, memory 404, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0120] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the blockchain-based consensus authentication method and apparatus in the embodiments of the present application. The processor executes the software programs and modules stored in the memory to perform various functional applications and data processing, thereby implementing the aforementioned blockchain-based consensus authentication method. The memory can include high-speed random access memory (RAM) and can also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further include memory remotely located from the processor, and such remote memory can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0121] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: generate a pre-preparation message based on the financial transaction request initiated by the client through the master node, and broadcast the pre-preparation message to all consensus nodes, wherein the pre-preparation message includes: multiple financial transaction requests, a block summary generated after aggregating the financial transaction content, and a signature result of the block summary. Each consensus node generates preparation information after signing the block summary in the pre-preparation message; receive the partial preparation message returned by the consensus node through the master node, and if the message legitimacy verification is passed, aggregate the signature in the partial preparation message into a batch signature, generate submission information based on the batch signature, and broadcast the submission information to all consensus nodes, wherein the consensus node verifies the batch signature in the submission information after receiving the submission information; count the number of consensus nodes that have passed the verification of the aggregated batch signature, and complete the consensus authentication process for the current batch transaction when the total number of consensus nodes that pass the signature verification reaches the first preset node number threshold.

[0122] It can be understood by those skilled in the art that Figure 4 The structure shown is for illustration only, and the electronic device may also be a smart phone, a tablet computer, a PDA, a mobile Internet device (MID), a PAD or other terminal device. Figure 4 It does not limit the structure of the above electronic device. For example, the electronic device may also include Figure 4 More or fewer components (such as network interfaces, display devices, etc.) shown in, or with Figure 4 Different configurations shown.

[0123] Those skilled in the art will understand that all or part of the steps in the various blockchain-based consensus authentication methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0124] Example 4

[0125] The embodiment of the present application further provides a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the blockchain-based consensus authentication method provided in the first embodiment.

[0126] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is further provided, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute the blockchain-based consensus authentication method of any one of the above-mentioned embodiments.

[0127] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0128] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the blockchain-based consensus authentication method described in each embodiment of the present application.

[0129] The present application also provides a computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the blockchain-based consensus authentication method described in each embodiment of the present application are implemented.

[0130] The serial numbers of the above embodiments of the present invention are for description only and do not represent the advantages or disadvantages of the embodiments.

[0131] In the above embodiments of the present invention, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0132] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only exemplary. For example, the division of the units can be a logical function division. In actual implementation, there may be other division methods, such as 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 through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

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

[0134] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0135] 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 invention, 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. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk, etc. Various media that can store program codes.

[0136] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as within the scope of protection of the present invention.

Claims

1. A consensus authentication method based on blockchain, characterized in that: Applied to a blockchain network, the blockchain network includes N blockchain nodes, each blockchain node acts as a master node corresponding to a block generation operation, and the other N-1 blockchain nodes are consensus nodes, where N is a positive integer greater than 1, including: The master node generates a pre-prepare message based on a financial transaction request initiated by a client, and broadcasts the pre-prepare message to all consensus nodes, wherein the pre-prepare message includes: multiple financial transaction requests, a block digest generated by aggregating the financial transaction content, and a signature result of the block digest. Each consensus node generates preparation information after signing the block digest in the pre-prepare message; The master node receives a partial prepare message returned by the consensus node. If the message passes the legitimacy verification, the master node aggregates the signatures in the partial prepare message into a batch signature, generates a commit message based on the batch signature, and broadcasts the commit message to all consensus nodes. Upon receiving the commit message, the consensus node verifies the batch signature in the commit message. The number of consensus nodes that have passed the verification of the aggregated batch signatures is counted, and when the total number of consensus nodes that have passed the signature verification reaches a first preset node number threshold, the consensus authentication process for the current batch of transactions is completed.

2. The consensus authentication method according to claim 1, characterized in that: The steps of generating a pre-prepared message based on a financial transaction request initiated by a client by the master node and broadcasting the pre-prepared message to all consensus nodes include: receiving, through the master node, multiple financial transaction requests initiated by the client, and performing a legitimacy check on the multiple financial transaction requests; When the master node passes the legality verification of the financial transaction request, the master node aggregates the financial transaction contents in the multiple financial transaction requests to generate a target transaction block corresponding to the current batch of transactions; Verifying the correctness of the target transaction block through the master node, and if the correctness verification of the target transaction block is successful, calculating a unified block digest for all financial transaction contents in the target transaction block; The master node signs the block summary using the node private key to obtain a signature result; The master node generates the pre-prepared message based on the block summary of the target transaction block and the signature result, and broadcasts the pre-prepared message to all consensus nodes.

3. The consensus authentication method according to claim 2, characterized in that: The step of calculating a unified block digest for all financial transaction contents in the target transaction block includes: Calculating the leaf nodes corresponding to each financial transaction request in the target transaction block, generating a Merkle tree, and using the root node of the Merkle tree as the block summary; or; A hash calculation is performed on the current batch of transactions corresponding to the target transaction block, and a batch block summary corresponding to the target transaction block is generated based on the hash value corresponding to each financial transaction request.

4. The consensus authentication method according to claim 1, characterized in that: After broadcasting the pre-prepare message to all consensus nodes, the method further includes: Extracting the public key of the master node through each consensus node, and using the public key to perform a validity check on the block digest in the pre-prepared message, wherein the validity check includes: format check and transaction validity check; When the pre-prepared message passes the legitimacy check, each consensus node uses a preset multi-signature strategy to sign the block summary based on its own private key; Each of the consensus nodes generates a prepare message based on the summary signature result, and sends the prepare message to the master node.

5. The consensus authentication method according to claim 4, characterized in that: The preset multi-signature strategy is the MuSig multi-signature algorithm.

6. The consensus authentication method according to claim 1, characterized in that: The steps of receiving, through the master node, a partial prepare message returned by the consensus node, aggregating signatures in the partial prepare message into a batch signature if the message legitimacy is verified, and generating submission information based on the batch signature include: Counting, by the master node, the number of consensus nodes that return the prepare message, and when the number of consensus nodes exceeds a second preset node number threshold, using the public key of each consensus node to verify the legitimacy of the prepare message; If the message legitimacy verification passes, the signatures in the returned partial prepared messages are aggregated using a preset multi-signature strategy to obtain the batch signature; The master node generates the submission information based on the batch signature and the transaction association message.

7. The consensus authentication method according to claim 1, characterized in that: After completing the consensus certification process for the current batch of transactions, it also includes: Submit all financial transactions in the batch signature to the state machine for execution through the consensus node in the order of the global serial numbers broadcast by the master node; The generated target transaction block is appended to the local ledger by the consensus node.

8. A consensus authentication device based on blockchain, characterized in that: Applied to a blockchain network, the blockchain network includes N blockchain nodes, each blockchain node serves as a master node corresponding to a block generation operation, and the other N-1 blockchain nodes serve as consensus nodes, where N is a positive integer greater than 1. The blockchain-based consensus authentication device includes: A pre-prepare unit, configured to generate a pre-prepare message based on a financial transaction request initiated by a client through the master node, and broadcast the pre-prepare message to all consensus nodes, wherein the pre-prepare message includes: a plurality of the financial transaction requests, a block digest generated by aggregating the financial transaction contents, and a signature result of the block digest; each consensus node generates preparation information after signing the block digest in the pre-prepare message; a commit message generating unit configured to receive, through the master node, a partial prepare message returned by a consensus node, aggregate the signatures in the partial prepare message into a batch signature if the message passes legitimacy verification, generate commit messages based on the batch signatures, and broadcast the commit messages to all consensus nodes, wherein upon receiving the commit messages, the consensus nodes verify the batch signatures in the commit messages; The consensus unit is used to count the number of consensus nodes that have passed the verification of the aggregated batch signatures, and complete the consensus authentication process for the current batch of transactions when the total number of consensus nodes that have passed the signature verification reaches a first preset node number threshold.

9. An electronic device, characterized in that: The system comprises one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the blockchain-based consensus authentication method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the blockchain-based consensus authentication method described in any one of claims 1 to 7 are implemented.

Images