Consensus network optimization method and device, computer device and storage medium

Abstract

The application relates to a consensus network optimization method and device, computer equipment, a storage medium and a computer program product. The application can be applied to the field of maps. In the scheme, when a node receives a view switching message, the node can directly search for corresponding preparation message data according to a first preparation message hash value in the view switching message, when the corresponding preparation message data is not found, the node can also request other nodes to feed back the preparation message data by broadcasting a preparation message data request message, and after the original preparation message data fed back by the other nodes is obtained, the preparation message data is verified according to a second preparation message hash value corresponding to the original preparation message data and the first preparation message hash value, so that the validity of the data is ensured. Therefore, in the application, the original preparation message data does not need to be carried in the view switching message, so that the memory overhead of the consensus algorithm can be effectively saved in the view switching stage.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a consensus network optimization method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] With the development of computer and network technologies, blockchain technology has emerged and continues to evolve. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer. In the blockchain world, due to its decentralized design, nodes are scattered and parallel. Therefore, a system must be designed to maintain the system's operational order and fairness, unify the blockchain version, reward users who provide resources to maintain the blockchain, and punish malicious actors. Such a system must rely on some means to prove who has obtained the right to package (or record) a block in the blockchain and can obtain the reward for packaging that block; or who intends to cause harm and will be punished accordingly. This is the consensus mechanism. In distributed systems or peer-to-peer networks, a consensus mechanism is an algorithmic mechanism that reaches a consensus on a transaction, proposal, or task. In the blockchain industry, it refers to an algorithm that reaches a consensus on a packaged proposal of a block's transaction set.

[0003] Currently, the Practical Byzantine Fault Tolerance (PBFT) algorithm is a relatively common consensus mechanism algorithm. However, when entering the view switching phase, the PBFT algorithm needs to carry the original proposals of each blockchain node in the broadcast consensus message, which increases memory overhead and increases the pressure on the blockchain communication process. Summary of the Invention

[0004] Therefore, it is necessary to provide a consensus network optimization method, apparatus, computer equipment, storage medium, and computer program product that can effectively reduce the pressure on the blockchain communication process, addressing the aforementioned technical problems.

[0005] Firstly, this application provides a consensus network optimization method. The method includes:

[0006] When a view switching message is received in the consensus network, the hash value of the first preparation message in the view switching message is obtained;

[0007] Based on the hash value of the first preparation message, a data lookup is performed locally. If no preparation message data corresponding to the hash value of the first preparation message is found, a preparation message data request message is generated based on the hash value of the first preparation message and broadcast within the consensus network.

[0008] When a preparation message data is received in response to a request message based on the preparation message data, the second preparation message hash value corresponding to the preparation message data is obtained;

[0009] The preparation message data is verified based on the hash value of the first preparation message and the hash value of the second preparation message.

[0010] Secondly, this application also provides a consensus network optimization device. The device includes:

[0011] The message receiving module is used to obtain the hash value of the first preparation message in the view switching message when it receives a view switching message in the consensus network.

[0012] The data lookup module is used to perform a local data lookup based on the hash value of the first preparation message. When no preparation message data corresponding to the hash value of the first preparation message is found, a preparation message data request message is generated based on the hash value of the first preparation message, and the preparation message data request message is broadcast within the consensus network.

[0013] The data extraction module is used to obtain the second preparation message hash value corresponding to the preparation message data when it receives preparation message data feedback based on the preparation message data request message;

[0014] The data verification module is used to verify the preparation message data based on the first preparation message hash value and the second preparation message hash value.

[0015] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0016] When a view switching message is received in the consensus network, the hash value of the first preparation message in the view switching message is obtained;

[0017] Based on the hash value of the first preparation message, a data lookup is performed locally. If no preparation message data corresponding to the hash value of the first preparation message is found, a preparation message data request message is generated based on the hash value of the first preparation message and broadcast within the consensus network.

[0018] When a preparation message data is received in response to a request message based on the preparation message data, the second preparation message hash value corresponding to the preparation message data is obtained;

[0019] The preparation message data is verified based on the hash value of the first preparation message and the hash value of the second preparation message.

[0020] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0021] When a view switching message is received in the consensus network, the hash value of the first preparation message in the view switching message is obtained;

[0022] Based on the hash value of the first preparation message, a data lookup is performed locally. If no preparation message data corresponding to the hash value of the first preparation message is found, a preparation message data request message is generated based on the hash value of the first preparation message and broadcast within the consensus network.

[0023] When a preparation message data is received in response to a request message based on the preparation message data, the second preparation message hash value corresponding to the preparation message data is obtained;

[0024] The preparation message data is verified based on the hash value of the first preparation message and the hash value of the second preparation message.

[0025] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0026] When a view switching message is received in the consensus network, the hash value of the first preparation message in the view switching message is obtained;

[0027] Based on the hash value of the first preparation message, a data lookup is performed locally. If no preparation message data corresponding to the hash value of the first preparation message is found, a preparation message data request message is generated based on the hash value of the first preparation message and broadcast within the consensus network.

[0028] When a preparation message data is received in response to a request message based on the preparation message data, the second preparation message hash value corresponding to the preparation message data is obtained;

[0029] The preparation message data is verified based on the hash value of the first preparation message and the hash value of the second preparation message.

[0030] The aforementioned consensus network optimization method, apparatus, computer device, storage medium, and computer program product, wherein the method involves, upon receiving a view switching message in the consensus network, obtaining a first preparation message hash value from the view switching message; performing a local data lookup based on the first preparation message hash value; if no preparation message data corresponding to the first preparation message hash value is found, generating a preparation message data request message based on the first preparation message hash value and broadcasting the preparation message data request message within the consensus network; upon receiving preparation message data as feedback based on the preparation message data request message, obtaining a second preparation message hash value corresponding to the preparation message data; and verifying the preparation message data based on the first preparation message hash value and the second preparation message hash value. In the scheme of this application, when a node receives a view switching message, it can directly look up the corresponding preparation message data locally based on the hash value of the first preparation message in the view switching message. If it cannot find the data, it can also request other nodes to provide the preparation message data by broadcasting a proposal request message. After receiving the preparation message data, it verifies the preparation message data based on the hash value of the second preparation message and the hash value of the first preparation message, thereby ensuring the validity of the data. Therefore, the view switching message does not need to carry the original preparation message data, which can effectively save the memory overhead of the consensus algorithm during the view switching phase. Attached Figure Description

[0031] Figure 1 This is a schematic diagram illustrating the structure of a distributed system applied to a blockchain system in one embodiment;

[0032] Figure 2 This is a schematic diagram of the block structure in one embodiment;

[0033] Figure 3 This is a flowchart illustrating a consensus network optimization method in one embodiment;

[0034] Figure 4 This is a flowchart illustrating the steps of generating and broadcasting a view switching message in one embodiment;

[0035] Figure 5 A flowchart illustrating the steps for preparing message data for feedback in one embodiment;

[0036] Figure 6 This is a flowchart illustrating the steps of a master node broadcasting a new view message in one embodiment;

[0037] Figure 7 This is a flowchart illustrating the steps for a non-master node to verify a new view message in one embodiment.

[0038] Figure 8 This is a flowchart illustrating the consensus network optimized verification method in another embodiment;

[0039] Figure 9 This is a structural block diagram of a consensus network optimization device in one embodiment;

[0040] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0042] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Furthermore, under authorization, it monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information using a consensus algorithm (consensus management). After encryption, the data is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). According to the contract terms, the key or other events are invoked to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization output during product release, such as alarms, network monitoring, and monitoring of node device health status.

[0043] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0044] The system described in this application can be a distributed system formed by connecting a client and multiple nodes (any form of computing device accessing the network, such as a server or user terminal) through network communication. User terminals include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, and in-vehicle terminals.

[0045] Taking a distributed system as an example, see blockchain system. Figure 1 , Figure 1 This is an optional structural diagram of the distributed system 100 provided in this application embodiment applied to a blockchain system. It consists of multiple nodes (any form of computing device in the network, such as servers or user terminals) and clients, forming a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the distributed system, any machine, such as a server or terminal, can join and become a node. A node includes a hardware layer, a middleware layer, an operating system layer, and an application layer.

[0046] See Figure 1 The functions of each node in the blockchain system shown include:

[0047] 1) Routing: A basic function of nodes used to support communication between nodes.

[0048] In addition to routing capabilities, nodes can also have the following functions:

[0049] 2) Applications are deployed in the blockchain to implement specific business needs. They record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system. When other nodes successfully verify the source and integrity of the record data, they add the record data to a temporary block.

[0050] For example, the business logic implemented by the application includes:

[0051] 2.1) A wallet is used to provide the function of conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system; after other nodes successfully verify the transaction, they store the transaction record data in the temporary block of the blockchain as a response to acknowledge the validity of the transaction; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0052] 2.2) Shared ledger, used to provide functions such as storage, query and modification of ledger data. It sends the record data of the operation on the ledger data to other nodes in the blockchain system. After the other nodes verify the validity, as a response to acknowledge the validity of the ledger data, they store the record data in a temporary block. They can also send confirmation to the node that initiated the operation.

[0053] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented through code deployed on a shared ledger that executes when certain conditions are met. Based on actual business needs, the code is used to complete automated transactions, such as querying the logistics status of goods purchased by a buyer and transferring the buyer's electronic money to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts for processing received information.

[0054] 3) A blockchain consists of a series of blocks that are sequentially generated. Once a new block is added to the blockchain, it will not be removed. The blocks contain the data submitted by the nodes in the blockchain system.

[0055] See Figure 2 , Figure 2 This is an optional schematic diagram of the block structure provided in this application embodiment. Each block includes the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected through their hash values ​​to form a blockchain. Additionally, the block may include information such as a timestamp when it was generated. A blockchain is essentially a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains relevant information used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0056] The Practical Byzantine Fault Tolerance (PBT) algorithm is a common consensus mechanism applied to blockchains. It's a fault-tolerant three-phase commit consensus mechanism. When using PBT, if a consensus round fails to reach an agreement for an extended period due to voting disagreements or other reasons, each participating node will broadcast a view switch message within the consensus network. To ensure the soon-to-be-elected master node has a comprehensive understanding of the current consensus phase and to accurately and securely verify the view switch message, the view switch message broadcast by the consensus node, in addition to carrying the proposal's sequence number and view number, also checks all local consensus instances that have reached the voting state, writing the preparation messages and all voting messages received by those instances in previous consensus phases into the view switch message.

[0057] During the view switching phase, each consensus node in the consensus network acts as both a broadcaster and receiver of messages. Therefore, each consensus node receives view switching messages from all other consensus nodes. For each received view switching message, a consensus node extracts the preparation message and its corresponding voting message, and performs signature verification, legality checks, and correlation checks on these messages. After passing the checks, these messages are mapped to their respective senders and stored locally. For any consensus node, after receiving 2f+1 view switching messages, it can enter the next phase, the new view phase. In the new view phase, the consensus node increments the view number by 1 from the view number of the previous round of consensus that failed to reach an agreement, obtaining the view number for the new round of consensus. Based on this view number, it can determine whether it is the master node for the new round of consensus. If not, it waits for the master node's new view message. If it is the master node, it constructs the new view message. When constructing the new view message, the master node writes all the view switching messages it received during the view switching phase into the new view message and then broadcasts the new view message. The reason for writing all view switching messages into the new view is to allow other consensus nodes to verify each view switching message, ensuring that the new master node has not acted maliciously. Furthermore, after determining the new consensus view during the new view phase, the new master node will select the latest proposal (those with the largest sequence number) from all received view switching messages as the proposal for the new round of consensus—if the proposal is not empty (if empty, the new master node will repackage the proposal from the transaction pool). Therefore, writing all view switching messages received by the master node into the new view message during the new view phase also allows other consensus nodes to verify the legitimacy of the proposal proposed by the new master node in the new round of consensus. During this process, because the consensus message needs to carry the original proposal, the consensus network incurs increased memory overhead during view switching, and the view switching message and the new view message have a multiplier effect on top of the existing overhead. For example, suppose a block proposal is 64MB in size, and 40 nodes participate in the consensus vote. Assuming that during a view switch, all consensus nodes have only one consensus instance that has reached the voting completion phase, then each consensus node will only broadcast a preparation message for the view switch, carrying only one block proposal. After all consensus nodes have broadcast their view switch messages, each node will receive 40 view switch messages (including its own). Mapping and storing these proposals will consume 2.56GB (64MB * 40) of memory. Therefore, the practical Byzantine fault-tolerant algorithm requires a significant amount of memory during both the view switch and new view phases.

[0058] The consensus network optimization method provided in this application can be applied to, for example, Figure 1In the application environment shown, the distributed system 100 includes multiple blockchain nodes (hereinafter referred to as nodes) 200. These nodes communicate with each other in a peer-to-peer manner. Any node corresponding to a user can respond to the user's operation and execute the consensus network optimization method of this application. When a user needs to process the consensus mechanism through the blockchain node 200, after the consensus network enters the view switching phase, each participating node will broadcast a view switching message within the consensus network. When node 200 receives a view switching message in the consensus network, it obtains the first preparation message hash value in the view switching message; it performs a data search locally based on the first preparation message hash value; if the preparation message data corresponding to the first preparation message hash value is not found, it generates a preparation message data request message based on the first preparation message hash value and broadcasts the preparation message data request message within the consensus network; when it receives the preparation message data fed back according to the preparation message data request message, it obtains the second preparation message hash value corresponding to the preparation message data; and it verifies the preparation message data based on the first preparation message hash value and the second preparation message hash value.

[0059] In one embodiment, such as Figure 3 As shown, a consensus network optimization method is provided, which is applied to... Figure 1 Taking blockchain node 200 as an example, the explanation includes the following steps:

[0060] Step 302: When a view switching message is received in the consensus network, obtain the hash value of the first preparation message in the view switching message.

[0061] The consensus network in this application refers to the blockchain network, which consists of multiple consensus nodes. Blockchain, as a data structure that stores data in chronological order, supports different consensus mechanisms. The consensus mechanism is a crucial component of blockchain technology. The goal of a blockchain consensus mechanism is to ensure that all honest nodes maintain a consistent view of the blockchain, satisfying two properties: 1) Consistency: The prefix portion of the blockchain maintained by all honest nodes is identical; 2) Validity: Information published by an honest node will eventually be recorded in the blockchains of all other honest nodes. A consensus mechanism refers to an algorithmic mechanism that reaches a consensus on a transaction, proposal, or task within a distributed system or peer-to-peer network. In the blockchain field, it refers to an algorithm that reaches a consensus on the packaged proposal of a block's transaction set. The view change message is the ViewChange message. During the view change phase of the practical Byzantine fault-tolerant algorithm, when consensus fails to reach an agreement on a proposal for an extended period, a view change occurs. The view number is incremented by 1 to distinguish it from the original view. During this phase, consensus nodes broadcast view change messages to negotiate the view change and elect a new master node. This is to allow the soon-to-be-elected master node to have a more comprehensive understanding of the current consensus phase and to accurately and securely verify the view change message. In a consensus network, the view switching message broadcast by a consensus node carries not only the proposal's sequence number and view number, but also checks all local consensus instances that have reached the voting state. It writes the preparation messages received by each instance during previous consensus phases and all voting messages into the view switching message, which contains the consensus proposal. The hash value of the first preparation message is the hash value calculated based on the preparation message data in the view switching message. A hash, or pre-image, is a function that transforms an input of arbitrary length into a fixed-length output. This transformation is a compression mapping; that is, the space of hash values ​​is usually much smaller than the space of inputs. Different inputs may hash to the same output, so it's impossible to determine a unique input value from the hash value. Simply put, it's a function that compresses a message of arbitrary length into a message digest of a fixed length. Therefore, there is a one-to-one correspondence between the hash value of the first preparation message and the proposal, and the corresponding consensus proposal can be determined based on the hash value of the first preparation message. The preparation message, also known as the PrePrepare message, is sent by the master node and carries the consensus proposal. This application can replace the original text of the consensus proposal preparation message (including sequence number, consensus message type, node ID, consensus round number, and consensus proposal, etc.) with the preparation message hash value in the view switching message, thereby reducing the memory consumption during the view switching message transmission process.

[0062] Specifically, the consensus network optimization method of this application is applied to the view switching phase of the consensus network to reduce memory consumption during this phase. Therefore, when blockchain node 200 determines that the consensus network has entered the view switching phase and receives a view switching message from the consensus network, the original preparation message in the view switching message it obtains has been replaced with the preparation message hash value. If blockchain node 200 needs to sign and verify the preparation message in the view switching message, it needs to first obtain the original preparation message data corresponding to the first preparation message hash value. Therefore, when blockchain node 200 receives the view switching message from the consensus network, it first extracts the transformed preparation message from the view switching message and then obtains the transformed first preparation message hash value.

[0063] Step 304: Perform a data search locally based on the hash value of the first preparation message. If no preparation message data corresponding to the hash value of the first preparation message is found, generate a preparation message data request message based on the hash value of the first preparation message and broadcast the preparation message data request message within the consensus network.

[0064] Since the current blockchain node 200 may have previously received a preparation message carried in the view switching message, the preparation message data in the preparation message may have been stored locally on the blockchain node 200. Therefore, it can perform a data lookup locally based on the first preparation message hash value to determine whether the preparation message data corresponding to the first preparation message hash value exists locally. The preparation message data request message is used to request preparation message data from other nodes in the consensus network. Because the current blockchain node 200 does not know which node stores the preparation message data, it can broadcast the preparation message data request message within the consensus network to request preparation message data from other nodes.

[0065] Specifically, after blockchain node 200 extracts the hash value of the first preparation message, it needs to verify the view switch message by signing and verifying the preparation message within it. During verification, since the view switch message only contains the hash value of the first preparation message, not the preparation message itself, the hash value of the first preparation message needs to be verified. This verification can be done by searching the local database for the hash value to determine if a preparation message with the same hash value has been received locally. If not, a request message needs to be constructed using that hash value and sent to other nodes to obtain the original proposal content. If a preparation message with the same hash value exists locally, the view switch message can be directly signed and verified.

[0066] Step 306: When the preparation message data is received in response to the preparation message data request message, the second preparation message hash value corresponding to the preparation message data is obtained.

[0067] Step 308: Verify the preparation message data based on the first preparation message hash value and the second preparation message hash value.

[0068] The second preparation message hash value is similar to the first preparation message hash value; the first and second are simply used to refer to different data sources. The verification specifically refers to checking whether the first and second preparation message hash values ​​are the same, thereby determining whether the obtained preparation message data is correct.

[0069] Specifically, after blockchain node 200 broadcasts a preparation message data request message within the consensus network, other nodes will send corresponding original preparation message data back to blockchain node 200 based on the first preparation message hash value carried in the preparation message data request message. At this point, blockchain node 200 needs to verify the preparation message data to prevent other nodes from maliciously sending false preparation message data. Therefore, after receiving the preparation message data returned based on the preparation message data request message, it can calculate whether the second preparation message hash value of the original preparation message data returned by other nodes matches the first preparation message hash value. If they match, it means that the preparation message data has passed verification and can be saved for use in subsequent processes.

[0070] The aforementioned consensus network optimization method, upon receiving a view switching message in the consensus network, obtains the first preparation message hash value from the view switching message; performs a local data search based on the first preparation message hash value; if no preparation message data corresponding to the first preparation message hash value is found, a preparation message data request message is generated based on the first preparation message hash value and broadcast within the consensus network; upon receiving preparation message data as feedback based on the preparation message data request message, obtains the second preparation message hash value corresponding to the preparation message data; and verifies the preparation message data based on the first and second preparation message hash values. In this application's scheme, when a node receives a view switching message, it can directly search for the corresponding preparation message data locally based on the first preparation message hash value in the view switching message. If not found, it can also request other nodes to provide preparation message data by broadcasting a preparation message data request message. After receiving the original preparation message data from other nodes, it verifies the preparation message data based on the second and first preparation message hash values ​​corresponding to the original preparation message data from other nodes, thereby ensuring the validity of the data. Therefore, by using the method of this application embodiment, the view switching message does not need to carry the original preparation message data, thereby effectively saving the memory overhead of the consensus algorithm during the view switching phase.

[0071] In one embodiment, such as Figure 4As shown, before step 302, the following steps are also included:

[0072] Step 401: When it is detected that the consensus network has entered the view switching phase, obtain the local consensus instance that is in the voting completion phase.

[0073] Step 403: Extract the hash value of the first prepared message corresponding to the prepared message data in the consensus instance.

[0074] Step 405: Generate a view switching message based on the hash value of the first preparation message, and broadcast the view switching message carrying the hash value of the first preparation message.

[0075] The practical Byzantine fault-tolerant algorithm comprises two phases: a pre-voting phase and a voting completion phase. The pre-voting phase, or PrePrepare phase, involves only the master node sending a preparation message containing the consensus proposal. The voting completion (but not yet committed) phase, or Prepare phase, involves all consensus nodes, upon receiving the preparation message from the master node, checking the consensus proposal carried in that message, obtaining the corresponding check results, and then broadcasting the voting message based on those results. The consensus instance of the current blockchain node contains both the preparation message and the voting message received by the current blockchain node; the preparation message carries the consensus proposal.

[0076] Specifically, when a block proposal fails to reach consensus for an extended period, the consensus network enters a view switching phase. Consensus nodes within the network each construct and broadcast view switching messages. When constructing a view switching message, a consensus node checks all local consensus instances that have reached the voting completion phase. However, in this application, the received preparation message is transformed, replacing the preparation message data with the corresponding first preparation message hash value, and then writing the first preparation message hash value into the view switching message, instead of writing the complete preparation message data. All other voting messages corresponding to the preparation message are still written. After construction, the view switching message is broadcast to the consensus network for reception and verification by other nodes.

[0077] Currently, when broadcasting view switching messages, a communication message needs to be constructed first. This requires extracting and serializing the transactions and signatures from the proposal and writing them into the message, which undoubtedly increases processing complexity. Correspondingly, the receiver also needs to deserialize each transaction in the message to reconstruct the proposal and perform signature verification and legality checks on the transactions and proposal. Moreover, when broadcasting view switching messages, the content to be transmitted needs to be copied to the buffer for each receiver, resulting in a multiplier effect. As long as the block proposal in the view switching message becomes slightly larger, the pressure on communication transmission increases exponentially. In this application, the preparation message data in the preparation message is replaced with the first preparation message hash value corresponding to the preparation message data. Only the first preparation message hash value corresponding to the preparation message needs to be broadcast, thus eliminating the need for complex serialization / deserialization and verification processing, and effectively avoiding the huge buffering overhead during broadcasting.

[0078] In one embodiment, such as Figure 5 As shown, the consensus network optimization method of this application also includes:

[0079] Step 502: When a preparation message data request message is received in the consensus network, obtain the first preparation message hash value carried in the preparation message data request message.

[0080] Step 504: Perform a local data lookup based on the hash value of the first preparation message carried in the preparation message data request message.

[0081] Step 506: When the preparation message data corresponding to the hash value of the first preparation message is found, request the broadcast node corresponding to the preparation message data to send back the preparation message data.

[0082] Specifically, the current blockchain node 200 may also receive preparation message data request messages broadcast by other nodes. In this case, blockchain node 200 needs to determine whether it has the corresponding preparation message data stored locally based on the first preparation message hash value carried in the preparation message data request message. Only when the corresponding preparation message data is stored locally can it directly reply to the request message. Therefore, when receiving a preparation message data request message from another node in the consensus network, blockchain node 200 can parse the first preparation message hash value carried in it and compare it with the hash value of the preparation message data stored locally. When the preparation message data corresponding to the first preparation message hash value is found, it can directly send the preparation message data back to the broadcast node corresponding to the preparation message data request message. If the preparation message data corresponding to the first preparation message hash value is not found, the preparation message data request message can be ignored. The broadcast node can receive preparation message data from multiple other nodes. After receiving and verifying the first preparation message data, it will automatically ignore the preparation message data from subsequent nodes.

[0083] In this embodiment, upon receiving a preparation message data request message from the consensus network, the system sends corresponding preparation message data back to the requesting broadcast node based on whether such data exists locally. By sending preparation message data separately, it effectively ensures that nodes within the consensus network can verify the preparation message data in the view switching message during the view switching phase, while also alleviating communication pressure during this phase. This embodiment also adds a mechanism for consensus nodes to autonomously obtain corresponding preparation message data based on local conditions, rather than having the message sender uniformly and forcibly bind it in the message. This refines the communication classification in the consensus process and improves the flexibility of consensus interaction.

[0084] In one embodiment, after step 308, the method further includes: performing signature verification on the view switching message; when the signature verification is successful, saving the view switching message and the sending node identifier corresponding to the view switching message.

[0085] Specifically, after receiving a view switching message, blockchain node 200 can verify the message's signature. This verification includes signing the view switching message itself to ensure it hasn't been intercepted, tampered with, or resent by a third party. The signature verification process involves extracting all voting messages within the message and signing them individually to ensure that the voting messages received by the node sending the message are secure and legitimate. Once the signature verification is successful, it indicates that the view switching message and its source are not problematic. At this point, the corresponding view switching message and the sending node's identifier can be saved locally for retrieval in subsequent processes.

[0086] In a specific embodiment, in addition to signature verification, blockchain nodes can also perform corresponding checks on view switching messages, including legality checks and correlation checks. Only after the checks pass will these view switching messages and their respective sending node mappings be saved locally. In this embodiment, by saving the view switching messages and the corresponding sending node identifiers, a data foundation can be effectively laid for subsequent new view phases, ensuring the effectiveness of consensus network view switching.

[0087] In one embodiment, such as Figure 6 As shown, after step 308, the following steps are also included:

[0088] Step 601: When the consensus network is identified to have entered the new view phase, obtain the cached node identity identifier.

[0089] Step 603: When the node determines itself to be the master node based on the cached node identity, a new view message is generated based on the received view switching message, and the new view message is broadcast.

[0090] The NewView phase involves electing a master node during the view switching phase. Once the master node in the new view receives 2f+1 view switching messages, it broadcasts the NewView message to confirm its entry into the new view, preparing for a new round of consensus. Here, f represents the maximum number of faults the Practical Byzantine Fault Tolerance (PBT) consensus algorithm can tolerate, calculated using (n-1) / 3, and n represents the total number of nodes participating in the consensus network. The cached node identity identifier is used to represent the node's identity. In one embodiment, this identifier can be a View Number, assigned to each consensus instance to distinguish it from other nodes. When the consensus mechanism reaches an agreement on a proposal and generates a new node, the View Number increments by 1. Similarly, if a view switch occurs due to a prolonged failure to reach an agreement on a proposal, the View Number also increments by 1 to differentiate it from the original view. Writing all view switching messages into the NewView message allows other consensus nodes to verify each message, ensuring the new master node is not malicious.

[0091] Specifically, after the view switching phase ends and a new master node is elected in the consensus network, the new view phase begins. At this point, nodes in the consensus network can be divided into master nodes and non-master nodes. That is, when a consensus node receives more than 2f+1 view switching messages, it can check whether it is a master node based on the updated view number. If it determines itself to be a master node, it can construct a new view message. The master node will write all received view switching messages into the new view message. After writing, the master node can broadcast the new view message in the consensus network, and non-master nodes will receive the corresponding new view message. In this scheme, since the preparation message data in the view switching message has been replaced with the corresponding hash value, unless in very special circumstances, the master node can keep the memory overhead within a very small range when sending the new view message, thereby avoiding node crashes and network paralysis. By decomposing the content of the view switching message and the new view message, and replacing the preparation message in the view switching message and the new view message with the preparation message hash value, consensus communication and proposal acquisition are decoupled, reducing the complexity of consensus message processing.

[0092] In one embodiment, such as Figure 7 As shown, after step 308, the following steps are also included:

[0093] Step 702: When a new view message is received, obtain the node flag of the sending node corresponding to the new view message. The new view message carries view switching messages sent by different nodes during the view switching phase.

[0094] Step 704: When the node flag indicates that the sending node is the master node, obtain the view switching message from the new view message.

[0095] Step 706: Perform signature verification on the view switching message and obtain the signature verification result corresponding to the view switching message.

[0096] Step 708: Obtain the signature verification result of the new view message based on the signature verification result corresponding to the view switching message.

[0097] The node identifier is used to verify whether the sending node is the master node. Specifically, the node identifier includes the sending node's own identity identifier (replica ID), which can be used to verify the sending node's identity based on the new view number and its own identity identifier. The new view message contains all view switch messages received by the master node; therefore, verifying the new view message specifically involves verifying the view switch messages contained within it. The combined signature verification results of all view switch messages constitute the signature verification result of the new view message.

[0098] Specifically, when blockchain node 200 is not a master node, it needs to receive new view messages broadcast by the master node. First, it checks whether the new view message originates from the master node based on the node identifier and new view number in the message. If the message originates from the master node, it is processed. During this process, all view switching messages carried in the new view message are retrieved and checked one by one. When checking each view switching message, the hash value of the first prepared message carried in the message is used to check if the corresponding consensus proposal exists locally. After the view switching phase, most consensus nodes should have the same consensus instance, but inconsistencies among a small number of nodes cannot be ruled out. This is because in any phase of the practical Byzantine fault-tolerant algorithm, the next phase begins after receiving 2f+1 view switching messages, not after receiving all view switching messages. The acquisition and verification of consensus proposals based on the hash value within the view switching message, whether obtained locally or through external requests, follows the same process as the view switching phase: local data lookup is performed based on the hash value of the first preparation message. If no preparation message data corresponding to the hash value is found, a preparation message data request message is generated and broadcast within the consensus network. When preparation message data is received based on the preparation message data request message, the second preparation message hash value is obtained. The view switching message is then signed and verified using both the first and second preparation message hash values. In this embodiment, upon entering the new view phase, non-master nodes can directly verify the view switching message within the new view message by signing it. This means only the hash value of the first preparation message corresponding to the preparation message data in the view switching message needs to be verified, thus reducing memory consumption during new view message transmission and increasing the block size expansion limit. The proposed solution renders view switching messages and new view messages almost insensitive to block size, thereby greatly expanding the block capacity and significantly improving the system throughput performance of the blockchain.

[0099] This application also provides an application scenario in which the above-described consensus network optimization method is applied.

[0100] Specifically, the consensus network optimization method is applied in this application scenario as follows:

[0101] When a block proposal is processed within the consensus network, and consensus is not reached within the preset time limit, the network needs to enter a view switching phase and a new view phase, according to the network rules, to switch views. The consensus network optimization method described in this application can be used to optimize the network during the view switching and new view phases. The specific process can be found in [reference needed]. Figure 8As shown, when the consensus network enters the view switching phase, each node in the consensus network needs to construct and broadcast a view switching message. Therefore, when a node recognizes that the consensus network has entered the view switching phase, it directly obtains the local consensus instance that is in the voting completion phase; extracts the first prepared message hash value corresponding to the prepared message data in the consensus instance; generates a view switching message based on the first prepared message hash value, and broadcasts the view switching message. When a node receives a view switching message in the consensus network, it obtains the first prepared message hash value in the view switching message; performs a data lookup locally based on the first prepared message hash value; if the prepared message data corresponding to the first prepared message hash value is not found, it generates a prepared message data request message based on the first prepared message hash value and broadcasts the prepared message data request message within the consensus network; when it receives prepared message data as feedback based on the prepared message data request message, it obtains the second prepared message hash value corresponding to the prepared message data; and verifies the prepared message data based on the first and second prepared message hash values. At the same time, it performs signature verification processing on the view switching message; when the signature verification passes, it saves the view switching message and the sending node identifier corresponding to the view switching message. Furthermore, during the view switching phase, when a node receives a preparation message data request message from the consensus network, it obtains the first preparation message hash value carried in the preparation message data request message; it then performs a local data lookup based on the first preparation message hash value; when the preparation message data corresponding to the first preparation message hash value is found, it sends the preparation message data back to the broadcast node corresponding to the preparation message data request message. When the consensus network elects a master node and enters the new view phase, the node first needs to determine if it is indeed the master node, i.e., obtain the cached node identity identifier; when it confirms itself as the master node based on the cached node identity identifier, it generates a new view message based on the received view switching message and broadcasts the new view message. When the node is not the master node, it waits for the master node to broadcast the new view message. When a new view message is received, it obtains the node identifier of the sending node corresponding to the new view message. The new view message carries view switching messages sent by different nodes during the view switching phase. When the node identifier indicates that the sending node is the master node, it obtains the view switching message from the new view message. It then performs signature verification processing on the view switching message and obtains the signature verification result corresponding to the view switching message. Based on the signature verification result corresponding to the view switching message, it obtains the signature verification result of the new view message. This completes the message transmission between the view switching phase and the new view phase. In this process, the original preparation message in the view switching message is replaced with the hash value of the preparation message, which can greatly reduce the amount of data transmitted and save memory overhead for the consensus algorithm.

[0102] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0103] Based on the same inventive concept, this application also provides a consensus network optimization apparatus for implementing the consensus network optimization method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more consensus network optimization apparatus embodiments provided below can be found in the limitations of the consensus network optimization method described above, and will not be repeated here.

[0104] In one embodiment, such as Figure 9 As shown, a consensus network optimization device is provided, comprising:

[0105] The message receiving module 902 is used to obtain the hash value of the first preparation message in the view switching message when it receives a view switching message in the consensus network.

[0106] The data lookup module 904 is used to perform a local data lookup based on the hash value of the first preparation message. When no preparation message data corresponding to the hash value of the first preparation message is found, a preparation message data request message is generated based on the hash value of the first preparation message and broadcast within the consensus network.

[0107] The data extraction module 906 is used to obtain the second preparation message hash value corresponding to the preparation message data when it receives preparation message data as a feedback of preparation message data request message.

[0108] The signature verification module 908 is used to verify the preparation message data based on the hash value of the first preparation message and the hash value of the second preparation message.

[0109] The aforementioned consensus network optimization device, upon receiving a view switching message in the consensus network, obtains the first preparation message hash value from the view switching message; performs a local data lookup based on the first preparation message hash value; if no preparation message data corresponding to the first preparation message hash value is found, a preparation message data request message is generated based on the first preparation message hash value and broadcast within the consensus network; upon receiving preparation message data as feedback based on the preparation message data request message, obtains the second preparation message hash value corresponding to the preparation message data; and verifies the preparation message data based on the first and second preparation message hash values. In this application's scheme, when a node receives a view switching message, it can directly search for the corresponding preparation message data locally based on the first preparation message hash value in the view switching message. If not found, it can also request other nodes to provide preparation message data by broadcasting a preparation message data request message. After receiving the original preparation message data from other nodes, it verifies the preparation message data based on the second and first preparation message hash values ​​corresponding to the original preparation message data from other nodes, thereby ensuring the validity of the data. Therefore, the apparatus of this application embodiment does not need to carry the original preparation message data in the view switching message, thereby effectively saving the memory overhead of the consensus algorithm during the view switching phase.

[0110] In one embodiment, a message generation module is further included, configured to: when the consensus network is identified to have entered the view switching phase, obtain a local consensus instance that is in the voting completion phase; extract the first preparation message hash value corresponding to the preparation message data in the consensus instance; generate a view switching message based on the first preparation message hash value; and broadcast the view switching message carrying the first preparation message hash value.

[0111] In one embodiment, a resource feedback module is further included, configured to: when a preparation message data request message is received in the consensus network, obtain a first preparation message hash value carried in the preparation message data request message; perform a local data lookup based on the first preparation message hash value carried in the preparation message data request message; and when preparation message data corresponding to the first preparation message hash value is found, feed back the preparation message data to the broadcast node corresponding to the preparation message data request message.

[0112] In one embodiment, a message storage module is also included, which is used to: perform signature verification processing on the view switching message; and when the signature verification is successful, save the view switching message and the sending node identifier corresponding to the view switching message.

[0113] In one embodiment, a node self-checking module is also included, which is used to: obtain the cached node identity identifier when the consensus network is detected to have entered the new view phase; and when it is determined to be the master node based on the cached node identity identifier, generate a new view message based on the received view switching message and broadcast the new view message.

[0114] In one embodiment, a new view message verification module is further included, configured to: when a new view message is received, obtain the node identifier of the sending node corresponding to the new view message, wherein the new view message carries view switching messages sent by different nodes during the view switching phase; when the node identifier indicates that the sending node is the master node, obtain the view switching message in the new view message; perform signature verification processing on the view switching message to obtain the signature verification result corresponding to the view switching message; and obtain the signature verification result of the new view message based on the signature verification result corresponding to the view switching message.

[0115] Each module in the aforementioned consensus network optimization device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0116] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores trajectory image data. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a consensus network optimization method or a consensus network optimization verification method.

[0117] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0118] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0119] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0120] In one embodiment, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, causing the computer device to perform the steps in the above method embodiments.

[0121] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0122] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0123] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0124] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A consensus network optimization method, characterized in that, The method includes: When a view switching message is received in the consensus network, the hash value of the first preparation message in the view switching message is obtained. The view switching message does not carry preparation message data and is used to negotiate the view switching and elect a new master node. Based on the hash value of the first preparation message, a data lookup is performed locally. If no preparation message data corresponding to the hash value of the first preparation message is found, a preparation message data request message is generated based on the hash value of the first preparation message and broadcast within the consensus network. When a preparation message data is received in response to a request message based on the preparation message data, the second preparation message hash value corresponding to the preparation message data is obtained; The preparation message data is verified based on the hash value of the first preparation message and the hash value of the second preparation message.

2. The method according to claim 1, characterized in that, Before obtaining the hash value of the first preparation message in the view switching message when a view switching message is received in the consensus network, the process further includes: When the consensus network is detected to have entered the view switching phase, obtain the local consensus instance that is in the voting completion phase; Extract the first preparation message hash value corresponding to the preparation message data in the consensus instance; A view switching message is generated based on the hash value of the first preparation message, and the view switching message carrying the hash value of the first preparation message is broadcast.

3. The method according to claim 1, characterized in that, The method further includes: When a preparation message data request message is received in the consensus network, the first preparation message hash value carried in the preparation message data request message is obtained; The data is searched locally based on the first preparation message hash value carried in the preparation message data request message; When the preparation message data corresponding to the first preparation message hash value is found, the broadcast node corresponding to the preparation message data request message is sent back with the preparation message data.

4. The method according to claim 1, characterized in that, The method further includes: Perform signature verification processing on the view switching message; When the signature verification is successful, the view switching message and the sending node identifier corresponding to the view switching message are saved.

5. The method according to claim 4, characterized in that, When the signature verification passes, after saving the view switching message and the sending node corresponding to the view switching message, the method further includes: When the consensus network is detected to have entered a new view phase, the cached node identity identifier is retrieved; When a node determines itself to be the master node based on the cached node identity, it generates a new view message based on the received view switching message and broadcasts the new view message.

6. The method according to claim 1, characterized in that, After verifying the preparation message data based on the first preparation message hash value and the second preparation message hash value, the method further includes: When a new view message is received, the node flag of the sending node corresponding to the new view message is obtained. The new view message carries view switching messages sent by different nodes during the view switching phase. When the node flag indicates that the sending node is the master node, the view switching message in the new view message is obtained; Perform signature verification processing on the view switching message to obtain the signature verification result corresponding to the view switching message; Based on the signature verification result corresponding to the view switching message, obtain the signature verification result of the new view message.

7. A consensus network optimization device, characterized in that, The device includes: The message receiving module is used to obtain the hash value of the first preparation message in the view switching message when it receives a view switching message in the consensus network. The view switching message does not carry preparation message data and is used to negotiate the switching of views and elect a new master node. The data lookup module is used to perform a local data lookup based on the hash value of the first preparation message. When no preparation message data corresponding to the hash value of the first preparation message is found, a preparation message data request message is generated based on the hash value of the first preparation message and the preparation message data request message is broadcast in the consensus network. The data extraction module is used to obtain the second preparation message hash value corresponding to the preparation message data when it receives preparation message data feedback based on the preparation message data request message; The data verification module is used to verify the preparation message data based on the first preparation message hash value and the second preparation message hash value.

8. The apparatus according to claim 7, characterized in that, Before obtaining the hash value of the first preparation message in the view switching message when a view switching message is received in the consensus network, a message generation module is also included, which is used to: obtain the local consensus instance in the voting completion stage when the consensus network is identified to have entered the view switching stage. Extract the first preparation message hash value corresponding to the preparation message data in the consensus instance; A view switching message is generated based on the hash value of the first preparation message, and the view switching message carrying the hash value of the first preparation message is broadcast.

9. The apparatus according to claim 7, characterized in that, It also includes a resource feedback module, used to: when a preparation message data request message is received in the consensus network, obtain the first preparation message hash value carried in the preparation message data request message; The data is searched locally based on the first preparation message hash value carried in the preparation message data request message; When the preparation message data corresponding to the first preparation message hash value is found, the broadcast node corresponding to the preparation message data request message is sent back with the preparation message data.

10. The apparatus according to claim 7, characterized in that, It also includes a message storage module, used for: performing signature verification processing on the view switching message; and when the signature verification is successful, saving the view switching message and the sending node identifier corresponding to the view switching message.

11. The apparatus according to claim 10, characterized in that, It also includes a node self-checking module, which is used to: obtain the cached node identity identifier when the consensus network enters the new view phase; and when it determines itself as the master node based on the cached node identity identifier, generate a new view message based on the received view switching message and broadcast the new view message.

12. The apparatus according to claim 7, characterized in that, It also includes a new view message verification module, which is used to: when a new view message is received, obtain the node flag of the sending node corresponding to the new view message, wherein the new view message carries view switching messages sent by different nodes during the view switching phase; When the node flag indicates that the sending node is the master node, the view switching message in the new view message is obtained; Perform signature verification processing on the view switching message to obtain the signature verification result corresponding to the view switching message; Based on the signature verification result corresponding to the view switching message, obtain the signature verification result of the new view message.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images