Value network-oriented block chain consensus system and method, electronic equipment and storage medium

Abstract

The invention discloses a value network-oriented block chain consensus system and method, electronic equipment and a storage medium, and belongs to the technical field of block chains. Comprising a view initialization and leader selection module for determining a leader of a current view from an effective verifier set under the condition that each view starts; the fast path consensus module is used for detecting a network state, initiating a proposal of a new block by a leader under the condition that the network is in a synchronous state and has no Byzantine fault, and submitting the new block to the block chain according to a voting result of each copy node in the effective verifier set for the proposal; and the double-signature detection and punishment module generates and broadcasts the double-signature evidence of the replica node under the condition that the same replica node is detected to sign different blocks at the same height, and moves the replica node out of the effective verifier set. According to the method, the efficiency is maximized under an ideal network, the robustness is maintained under a non-ideal environment, and the delay under unnecessary conditions is reduced.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, specifically relating to a blockchain consensus system, method, electronic device, and storage medium for value networks. Background Technology

[0002] A value network is a blockchain system specifically designed for value exchange and asset transfer. Its core function is to efficiently and securely record and verify transactions involving currencies, digital assets, or smart contracts. In a value network, all participants share the same immutable distributed ledger, ensuring transparency, traceability, and trustworthiness in the transaction process. Typical application scenarios include supply chain finance, cross-border payments, and asset securitization, where multiple participants need to achieve real-time synchronization and consistent confirmation of asset status in the absence of a central trusted entity.

[0003] Taking the metallurgical industry supply chain as an example, steel production involves multiple stages, from iron ore procurement, smelting and processing, multi-level trade and distribution, to its final use in construction projects. These stages include upstream raw material suppliers, midstream steel mills, downstream traders, and end users. If a downstream construction project discovers that a batch of steel fails to meet strength or chemical composition standards, it will directly impact project quality and construction safety. The root cause often lies in information gaps and data opacity within the supply chain. For example, steel mills may use iron ore of non-standard specifications due to rushing production, or fail to strictly control key process parameters during smelting. After leaving the factory, steel undergoes multiple levels of trade and logistics, and crucial information such as its storage environment and transportation routes is not fully recorded or shared. Due to the lack of a unified and reliable data chain across the entire process from raw material procurement, production and processing, logistics and transportation, to end-use, it is difficult to quickly identify the responsible party after quality problems occur, leading to unresolved disputes, delayed recalls, and significant economic losses and reputational risks.

[0004] To address these challenges, blockchain technology has been introduced to build a trustworthy and transparent supply chain traceability system. This system is based on permissioned blockchains and employs a Byzantine fault-tolerant state machine replication protocol as its consensus core to ensure state consistency among nodes under partially synchronized network conditions. The HotStuff protocol, for example, achieves linear communication complexity through a leader-based three-phase voting mechanism (preparation, pre-commit, and commit), exhibiting good scalability in large-scale node networks.

[0005] However, in the process of realizing this invention, the inventors discovered at least the following problems in the prior art: Although HotStuff performs excellently in terms of fault tolerance and scalability, its multi-round voting mechanism is redundant under ideal conditions of a fault-free synchronous network, limiting the improvement of system throughput and further optimization of latency. For example, in high-frequency data generation scenarios such as the metallurgical industry, steel mills continuously generate massive amounts of industrial IoT data during production, such as temperature, composition detection, and equipment status, requiring extremely high real-time data uploading to the blockchain. However, the HotStuff protocol requires each block to go through a complete three-stage voting process, resulting in a consensus delay fixed at the three-stage communication time, making it difficult to meet the real-time traceability requirement of "recording events as they occur." In addition, its inherent limitation on the number of communication rounds also restricts system throughput. When faced with the high-frequency data stream generated by steel mills every minute, it easily becomes a performance bottleneck for the entire supply chain information system, resulting in data recording delays and an inability to support real-time quality intervention and rapid problem tracing. Summary of the Invention

[0006] The purpose of this invention is to provide a blockchain consensus system, method, electronic device, and storage medium for value networks, which can solve the problems existing in the background technology.

[0007] To solve the above-mentioned technical problems, the present invention is implemented as follows: In a first aspect, embodiments of the present invention provide a blockchain consensus system for value networks, comprising: The view initialization and leader selection module determines the leader of the current view from the set of valid validators at the beginning of each view. The fast path consensus module detects the network status and, when the network is synchronized and there is no Byzantine fault, the leader initiates a proposal for a new block and submits the new block to the blockchain based on the voting results of each replica node in the set of valid validators for the proposal. The dual-signature detection and penalty module generates and broadcasts dual-signature evidence for the same replica node when it detects that the same replica node has signed different blocks at the same height, and removes the replica node from the set of valid verifiers.

[0008] Optionally, it also includes: The rollback module determines whether there is a delay in the voting of each replica node in the set of valid validators on the proposal, and whether the double signature detection and penalty module generates double signature evidence. If there is a delay in the voting of the valid validator set on the proposal, or if the double signature detection and penalty module generates double signature evidence, the process will revert to the classic three-phase consensus process and update the failure count of the fast path consensus. The classic three-phase consensus process includes a preparation phase, a pre-commit phase, and a commit phase.

[0009] Optionally, the rollback module is specifically used for: If a timeout period is obtained and no votes for the proposal are received from a preset number of replica nodes in the set of valid validators within the timeout period, it is determined that there is a delay in the voting of the set of valid validators for the proposal. The timeout period is updated using an exponential backoff strategy based on the number of failures in the fast path consensus.

[0010] Optionally, it also includes a heartbeat module and a view switching module; The heartbeat module is used to periodically send heartbeat signals from the leader to each replica node in the set of valid validators; The view switching module, upon the heartbeat signal timeout, switches the current view to a new view and identifies a new leader from the set of valid validators.

[0011] Optionally, the view switching module is specifically used for: In the event of a timeout in the heartbeat signal, new view messages sent by each replica node in the set of valid verifiers are collected. The new view message carries a confirmation certificate for the highest view number stored locally by the corresponding replica node. A new leader is determined from the set of valid validators; The new leader selects the confirmation certificate with the highest view number from the collected new view messages as the starting point to drive consensus and begin a new round of consensus.

[0012] Optionally, the view initialization and leader selection module is specifically used for: At the beginning of each view, the hash value of the current highest quality block is combined with the current view number to obtain the input seed for a verifiable random function; Based on the input seed, the pseudo-random values ​​and corresponding proofs of correctness of each replica node in the set of valid verifiers are calculated using a verifiable random function. The replica node whose pseudo-random value is closest to the preset target value is elected as the leader of the current view.

[0013] Optionally, the fast path consensus module is specifically used for: Receive and verify the votes from each replica node for the proposal, and determine the votes that pass verification as valid votes; If valid votes are collected from more than a preset proportion of replica nodes in the set of valid validators, a confirmation certificate is generated and broadcast to each replica node in the set of valid validators. The confirmation certificate carries the corresponding view number. Based on the confirmation certificate, the new block is submitted to the blockchain.

[0014] Secondly, embodiments of the present invention provide a blockchain consensus method for value networks, comprising: At the start of each view, the leader of the current view is determined from the set of valid validators; The network status is detected, and if the network is synchronized and there is no Byzantine fault, the leader initiates a proposal for a new block, and submits the new block to the blockchain based on the voting results of each replica node in the set of valid validators for the proposal; If the same replica node is detected signing different blocks at the same height, double-signature evidence for that replica node is generated and broadcast, and that replica node is removed from the set of valid validators.

[0015] Thirdly, embodiments of the present invention provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the second aspect.

[0016] Fourthly, embodiments of the present invention provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the second aspect.

[0017] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: In this invention, the leader-driven view initialization and leader selection module ensures the randomness and unpredictability of the leader at the start of each view, laying a fair foundation for fast path consensus, avoiding malicious manipulation, and thus improving robustness in cross-regional networks. Based on this, the fast path module dynamically detects network status and enables single-round voting under fault-free synchronization conditions, optimizing consensus latency from three latency units in the classic three-phase consensus to one latency unit. Meanwhile, the double-signature detection module monitors voting records in real time, generating evidence and penalizing violating nodes upon detecting double signatures, preventing fork risks that may arise from the fast path and forming a secure closed loop. This maximizes system efficiency under ideal network conditions and maintains robustness under non-ideal environments, reducing network latency in unnecessary situations. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the architecture of a blockchain consensus system oriented towards value networks provided in one embodiment of the present invention; Figure 2 This is a schematic diagram of the blockchain consensus process in one embodiment of the present invention; Figure 3 This is a schematic diagram of the end-to-end interaction of the consensus algorithm in one embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the steps of a blockchain consensus method for value networks provided in an embodiment of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0021] This invention applies to distributed ledgers. A value network is a blockchain network specifically designed for value exchange and asset transfer. Its core function is to efficiently and securely record and verify transactions involving currencies, digital assets, or smart contracts. In a value network, a block is the basic unit for storing transaction data. Each block contains multiple verified transaction records, timestamps, hash references to previous blocks, and other metadata. This information constructs an immutable, continuously growing chain-like data structure. In this invention, nodes are the participating entities in the network, including but not limited to financial institutions, enterprises, individual users, or regulatory agencies. Each node holds a complete copy of the ledger and is responsible for verifying transactions, participating in the consensus process, and maintaining the decentralized nature of the network.

[0022] While traditional Byzantine fault-tolerant consensus algorithms can guarantee security, they often face performance bottlenecks in large-scale cross-regional deployments. These bottlenecks include high latency introduced by multiple rounds of voting, centralization risks due to unfair leader selection, and malicious nodes manipulating the consensus process. To address these issues, this invention proposes an improved blockchain consensus system suitable for high-frequency transactions and cross-regional collaboration scenarios in value networks. The following detailed description, in conjunction with the accompanying drawings, through specific embodiments and application scenarios, illustrates a blockchain consensus system, method, electronic device, and storage medium for value networks provided by this invention.

[0023] Figure 1 This is a schematic diagram of the architecture of a blockchain consensus system oriented towards value networks, provided by one embodiment of the present invention. Figure 1 As shown, it includes: The view initialization and leader selection module determines the leader of the current view from the set of valid validators at the start of each view.

[0024] The view initialization and leader selection module determines the leader or consensus committee member responsible for proposing blocks at the beginning of each view (i.e., consensus round). Fairness in leader selection is crucial in value networks because malicious nodes that maintain control over proposal rights for an extended period could launch censorship attacks, delay critical transactions, or manipulate block content.

[0025] In one alternative implementation, the view initialization and leader selection module is specifically used for: At the start of each view, the hash value of the current highest quality block is combined with the current view number to obtain the input seed for a verifiable random function.

[0026] At the start of each view, the view initialization and leader selection module first generates a unique and unpredictable random number as the input seed, which serves as the basis for subsequent leader election. The input seed is composed of two key pieces of data: the hash value of the current highest-quality block and the current view number.

[0027] The hash value of the current highest-quality block refers to the cryptographic hash value corresponding to the block that has gained the broadest consensus in the network and has been confirmed as the heaviest or most authoritative block on the chain. Hash values ​​are unique and collision-resistant, uniquely representing a specific state throughout the entire blockchain history. Using it as part of the input ensures that the generation of the input seed is tightly bound to the latest state of the system. Any attempt to manipulate seed generation must first tamper with the already agreed-upon blockchain history, which is extremely difficult in practice.

[0028] The current view number is a monotonically increasing sequence number with each consensus round, used to uniquely identify each consensus attempt. Introducing view numbers ensures that even if the blockchain state is not updated temporarily, each view generates a different seed, thus preventing seed reuse or pre-computation attacks.

[0029] The view initialization and leader selection module combines the hash value of the current highest quality block and the current view number using a secure hash function, and finally outputs a fixed-length input seed that mixes the blockchain's historical state and consensus process, serving as the cornerstone of the fairness of the entire leader election process.

[0030] Based on the input seed, the pseudo-random values ​​and corresponding proofs of correctness for each replica node in the set of valid verifiers are calculated using a verifiable random function.

[0031] After obtaining the input seed, the view initialization and leader selection module initiates the calculation process of the verifiable random function. Each replica node in the valid verifier set will independently use its own unique private key to perform the verifiable random function calculation on the aforementioned public input seed.

[0032] A verifiable random function computes a deterministic but completely random value (pseudo-random value) for each node. This pseudo-random value is determined by the node's private key and a public input seed. Given the key and seed, the output is fixed; however, without knowing the private key, the output is unpredictable. A proof of correctness for the pseudo-random value is generated along with the value itself. This proof is a mathematical certificate that allows any participant in the network holding the public key of the replica node to verify that the pseudo-random value was indeed correctly computed by the specified node with a given input seed, without needing to know the replica node's private key. This "verifiable" characteristic ensures the transparency and fairness of the election process, preventing nodes from falsely reporting their random values.

[0033] In this way, each candidate node obtains a unique random credential with publicly verifiable proof.

[0034] The replica node whose pseudo-random value is closest to the preset target value is elected as the leader of the current view.

[0035] The target value is a pre-defined, specific value that is difficult to achieve through calculation. For example, within a very large range of values, the target might be the smallest value (i.e., the smallest hash value) or the value closest to a specific point.

[0036] The view initialization and leader selection module compares the pseudo-random values ​​published by all nodes with a preset target value. The replica node whose pseudo-random value is closest to the preset target value will be officially elected as the leader of the current view. For example, in a strategy that aims for the minimum value, the node with the smallest pseudo-random value will be elected.

[0037] Figure 2 This is a schematic diagram of the blockchain consensus process in one embodiment of the present invention. Please refer to [link / reference]. Figure 2 The selected leader broadcasts its pseudo-random value and corresponding proof of correctness to the entire network via the Leader broadcast module. Other nodes, upon receiving this information, can immediately verify the validity of the proof using the leader's public key and the known input seed. Only when the verification passes and it is confirmed that the replica node's random value is indeed closest to the target value will the entire network recognize its leadership.

[0038] Subsequently, the leader of this view is mapped from the set of valid validators based on the random output value. For example, the node with the smallest random value is either elected as the leader or a consensus committee is elected according to predefined rules. The selected leader broadcasts its random number proof for other nodes to verify. This ensures the randomness and fairness of leader selection and prevents any node from monopolizing proposal rights for a long time. It is especially suitable for cross-regional value networks where nodes are widely distributed and network conditions vary greatly, where traditional rotation schemes can easily lead to uneven performance or security risks.

[0039] The fast path consensus module detects the network status and, when the network is synchronized and there is no Byzantine fault, the leader initiates a proposal for a new block and submits the new block to the blockchain based on the voting results of each replica node in the set of valid validators for the proposal.

[0040] The Fast Path consensus module aims to significantly reduce block confirmation time under ideal conditions of network synchronization and no Byzantine faults. In value networks, transaction throughput and confirmation latency directly impact user experience.

[0041] The fast path consensus module achieves efficient block submission through the following steps: The Fast Path consensus module continuously monitors network latency and node behavior. When it determines that the network is in a synchronized state (i.e., message transmission latency is bounded) and no Byzantine fault is detected, it enables Fast Path.

[0042] The selected leader collects the transaction commands submitted by clients and encapsulates them into a new block. The new block contains transaction data, hash references to previous blocks, and other metadata, forming a complete block structure. The leader then broadcasts the new block proposal to all replica nodes.

[0043] Please see Figure 2After receiving a proposal, the replica nodes verify the legitimacy of the new block. Upon successful verification, each replica node replies with a single-round vote message, attaching a partial signature. Once the leader collects a majority (e.g., two times the fault tolerance plus one node out of a total of three times the fault tolerance plus one node) of unanimous votes, it aggregates these signatures to form a confirmation certificate. This confirmation certificate serves as proof that the block has received majority approval, triggering a fast-commit mechanism that directly appends the new block to the blockchain ledger, bypassing the traditional three-phase commit process.

[0044] In one optional implementation, the fast path consensus module is specifically used for: Receive and verify the votes from each replica node for the proposal, and determine the votes that pass verification as valid votes.

[0045] Upon receiving a block proposal from the leader, each replica node in the valid validator set initiates a local verification process. Verification includes, but is not limited to: checking if the block data structure conforms to the protocol specifications, verifying the validity of the digital signatures of all transactions, confirming that the block is correctly linked after the current highest-quality block (i.e., avoiding forks), and confirming the legitimacy of the leader's identity within the current view. Once verification is successful, the replica node generates a voting message containing its approval of the block, along with a partial digital signature generated using its private key, and then sends this vote to the leader of the current view.

[0046] The leader's fast path consensus module, upon receiving voting messages from each replica, does not immediately adopt them but initiates a verification process. This verification primarily targets two levels: First, check whether the node sending the vote is within the current set of valid validators to ensure that it is a legitimate consensus participant.

[0047] Second, using the public key of the replica node, a partial digital signature in its voting message is cryptographically verified to confirm that the vote was indeed issued by the replica node and has not been tampered with during transmission. Simultaneously, the block proposal and view number corresponding to the vote are checked to ensure that the vote is for the currently ongoing consensus process.

[0048] Only votes that pass all of the above checks will be considered valid and counted in subsequent statistics. Any vote that fails verification will be discarded immediately to prevent malicious or invalid information from interfering with the consensus process.

[0049] If valid votes are collected from more than a preset proportion of replica nodes in the set of valid validators, a confirmation certificate is generated and broadcast to each replica node in the set of valid validators. The confirmation certificate carries the corresponding view number.

[0050] The fast path consensus module continuously receives and verifies votes, while dynamically counting the number of valid votes collected. The preset ratio represents how many honest nodes in the entire set of valid validators need to reach a consensus to ensure the security and activity of the system. It can be set to more than half of the total number of validators to ensure that the consensus formed represents the will of the vast majority of the network and can tolerate a certain number of node failures or malicious behavior.

[0051] Once the Fast Path consensus module detects that the number of valid votes has reached or exceeded the preset proportion, it aggregates a portion of the signatures from all collected valid votes into a complete confirmation certificate. This certificate proves that the new block proposal under the current view has received sufficient approval and authorization from the network's nodes. The confirmation certificate carries its corresponding view number and explicitly binds to the consensus round in which it took effect, to prevent replay attacks or obfuscation.

[0052] Based on the confirmation certificate, the new block is submitted to the blockchain.

[0053] After generating the confirmation certificate, construct a decision message containing this confirmation certificate and broadcast it to all replica nodes in the set of valid validators.

[0054] For the leader and all replica nodes that receive this decision message, the arrival of the confirmation certificate triggers the final commit logic for the block. The node quickly verifies the authenticity and validity of the confirmation certificate again (e.g., verifying the correctness of its aggregate signature). Once verified, the node appends the new block to its local blockchain ledger. Subsequently, the node can execute the transactions in the block, update the world state, and notify relevant clients that the transactions have been successfully processed.

[0055] The dual-signature detection and penalty module generates and broadcasts dual-signature evidence for the same replica node when it detects that the same replica node has signed different blocks at the same height, and removes the replica node from the set of valid verifiers.

[0056] The double-signature detection and penalty module monitors and penalizes malicious behavior among consensus participants in real time, especially targeting double-voting behavior (i.e., double-signature behavior) that may undermine the uniqueness and consistency of the blockchain. Through an automated, verifiable, and non-repudiable detection and penalty process, the module ensures that the system's security and chain stability are not compromised while pursuing high-performance, fast-path consensus.

[0057] Within each replica node of the valid validator set, the double-signature detection and penalty module maintains a dedicated local voting record ledger indexed by block height. This is a structured database whose core fields include, but are not limited to: voter identity, the cryptographic hash value of the block voted for, the partial digital signature generated during the vote, and the corresponding block height and view number.

[0058] Whenever a replica node prepares to vote on a block proposal at a certain height, or when it receives a voting message from another replica node in the network, the double-signature detection and penalty module first archives the voting information to its local voting ledger according to the block height to which it belongs. This record constitutes the basic data for determining whether a node's voting behavior is honest.

[0059] As voting information is continuously fed in, the double-signature detection and penalty module initiates a parallel, real-time detection logic to scan for potential malicious behavior. The double-signature behavior defined by the double-signature detection and penalty module specifically refers to the same replica node voting on two or more different block proposals at the same block height, and providing valid digital signatures for each. This behavior is called "equivocation" in consensus protocols and is a typical Byzantine attack technique used to attempt to create a chain fork.

[0060] The core of the detection logic lies in cross-referencing all voting records of the same node at the same block height. Specifically, the double signature detection and penalty module checks whether there is an instance in the local voting ledger where a specific node identity is associated with more than one different block hash value at a specific block height.

[0061] Once a conflict is identified—that is, when the same node is found to have valid signatures for at least two different blocks (e.g., block A and block B) at the same height—the double-signature detection and penalty module determines that a double-signature violation has occurred. After detecting the violation, the double-signature detection and penalty module generates a structured double-signature evidence data packet, pointing to the replica node that performed the double-signature action, and listing the hash values ​​of all inconsistent blocks voted by that replica node at the same height, demonstrating its contradictory behavior. Simultaneously, it attaches all partial digital signatures generated by the replica node for these conflicting blocks, which serves as direct cryptographic proof of its violation.

[0062] After generating the double-signature evidence, the double-signature detection and penalty module constructs a special penalty message that encapsulates this double-signature evidence and broadcasts it to the entire set of valid verifiers. This broadcasting action aims to expose the malicious behavior of the violating node, notify all honest nodes, and initiate the subsequent collective penalty process.

[0063] Upon receiving the broadcast double-signature evidence, honest nodes in the network independently verify its authenticity, including confirming that all signatures were indeed issued by the violating node. Because the evidence itself is verifiable, honest nodes can quickly reach a consensus on the violation. Once the double-signature evidence is verified and accepted by a majority of honest nodes, the penalty logic is automatically triggered. The core operation of this logic is to immediately and permanently remove the violating replica node from the current set of valid validators. In other words, this replica node loses its eligibility to participate in any subsequent consensus rounds (including proposals, voting, etc.), effectively preventing the malicious node from continuing to consume network resources or commit further damage, thus isolating security threats outside the system. The updated set of valid validators is synchronized throughout the network through the consensus mechanism, ensuring that all honest nodes continue to run the consensus protocol based on the updated, more secure participant list.

[0064] In one alternative implementation, it further includes: The rollback module determines whether there is a delay in the voting of each replica node in the set of valid validators on the proposal, and whether the double signature detection and penalty module generates double signature evidence.

[0065] The rollback module continuously monitors key metrics in the consensus process and automatically triggers process switching and strategy adjustments when anomalies are detected, thus balancing efficiency and reliability in complex real-world application environments. The internal working mechanism of the rollback module will be explained in detail below.

[0066] The rollback module is not activated only at specific times, but runs continuously throughout the fast-path consensus process. Its judgment is based on the progress of vote collection and voting delay. After the leader initiates a fast-path proposal, the rollback module immediately starts a countdown timer adapted to the current network conditions. The rollback module monitors the vote returns from each replica node in the valid validator set in real time. If the leader fails to collect the minimum number of valid votes required for fast commit before the timer expires, and if the number of valid votes received remains below a preset proportion within a preset time window, the rollback module determines that voting delay has occurred.

[0067] The rollback module works in conjunction with the dual-signature detection and penalty module to continuously monitor the network for broadcast penalty messages and corresponding dual-signature evidence regarding dual-signature behavior.

[0068] Once valid double-signature evidence is received (i.e., the evidence has been locally verified and confirmed to be authentic), the fallback module treats it as a strong anomaly. This is not merely an isolated violation; it indicates the presence of active Byzantine nodes in the current consensus environment, attempting to create a fork through double voting. In this situation, the ideal premise of "no Byzantine faults" upon which the fast path relies has been violated, and continuing to adhere to the fast path will face extremely high security risks.

[0069] If there is a delay in the voting of the valid validator set on the proposal, or if the double signature detection and penalty module generates double signature evidence, the process will revert to the classic three-phase consensus process and update the failure count of the fast path consensus. The classic three-phase consensus process includes a preparation phase, a pre-commit phase, and a commit phase.

[0070] When any of the above-mentioned abnormal conditions is met (voting delay or double-signature evidence generation), the rollback module sends an interruption signal, suspending the currently ongoing fast path consensus process. Whether it is the leader node or a replica node, upon receiving this internal signal or observing external conditions sufficient to trigger a rollback (such as timeout or penalty messages), it will synchronously stop the relevant operations of the fast path.

[0071] Then it switches to the classic three-phase consensus process, which has stronger fault tolerance. Please see Figure 2 The classic three-phase consensus process includes: In the Prepare phase, the leader constructs a new block proposal based on the latest view state information collected and broadcasts it. Replica nodes perform rigorous security checks on the proposal and vote on whether to accept it as a candidate for the current view.

[0072] In the Pre-Commit phase, after a proposal receives enough prepared votes, the leader aggregates these votes into a prepared certificate and broadcasts it, pushing consensus into a higher-level commitment phase. Replica nodes then participate in the pre-commit vote.

[0073] During the Commit phase, the leader gathers enough pre-commit votes, generates a pre-commit certificate, and broadcasts it. Replica nodes then lock the block and vote on the commit. Finally, the leader aggregates the commit votes to form a CommitQC, completing the final confirmation of the block and executing the commands within it.

[0074] Even in situations of network instability or the presence of malicious nodes, the system proposed in this invention can still steadily advance consensus based on the majority principle and ultimately complete the block submission, thereby ensuring the liveness of the protocol.

[0075] In one optional implementation, the rollback module is specifically used for: If a timeout period is obtained and no votes for the proposal are received from a preset number of replica nodes in the set of valid validators within the timeout period, it is determined that there is a delay in the voting of the set of valid validators for the proposal.

[0076] When initiating a round of fast path consensus, the fallback module obtains an initial timeout baseline value from configuration parameters or system status. This baseline value is not fixed, but rather a time window set based on an assessment of historical network latency or a pre-set conservative estimate, representing the maximum time expected to complete a round of vote collection under the assumption of a synchronous network.

[0077] Once the leader broadcasts the block proposal, the rollback module starts a countdown timer, with the initial duration being the timeout period obtained above. Simultaneously, the rollback module begins real-time counting of the number of valid votes returned by each replica node from the valid validator set.

[0078] The preset threshold represents the minimum number of valid votes required to achieve fast path consensus. The minimum number of valid votes is pre-calculated based on the total size of the valid validator set and the security model.

[0079] The rollback module compares the remaining time of the timer with the number of valid votes collected. If, at the moment the timer reaches zero, i.e., the timeout period is completely exhausted, the number of valid votes collected is still lower than the aforementioned preset threshold, then the rollback module determines that there is a delay in the voting of the current set of valid validators on the proposal. This indicates that the current network conditions cannot meet the requirements of the fast path for low latency and high response, and continuing to wait is likely to be futile and will impair the activity of the system.

[0080] The timeout period is updated using an exponential backoff strategy based on the number of failures in the fast path consensus.

[0081] After determining that a delay has caused a rollback, future behavior is adjusted to avoid repeating invalid attempts under adverse conditions. The rollback module internally maintains a counter for the number of fast-path consensus failures. This counter is incremented each time a rollback to the classic process is triggered due to voting delays (or double-signature evidence).

[0082] The exponential backoff strategy is the core algorithm for the adaptive backoff module. The core idea of ​​the exponential backoff strategy is: the more consecutive failures there are, the more cautious the next attempt should be, allowing the system a longer recovery or waiting time. Specifically, its operation regarding timeout updates is as follows: The rollback module dynamically calculates a new, longer timeout based on the latest number of failures. The calculation rule essentially doubles the initial timeout baseline value (or increases it by another fixed multiple greater than one), and the number of times it is doubled is directly determined by the number of failures.

[0083] For example, after the first failure, the new timeout is double the initial time; after the second failure, the new timeout is four times the initial time; after the third failure, it is eight times, and so on. This growth pattern causes the timeout to increase exponentially with the number of consecutive failures, hence the name exponential backoff.

[0084] In this way, when encountering brief network fluctuations, the system will only temporarily increase the waiting time (doubling it after one failure) and can quickly resume attempting the fast path. However, when the network is persistently unstable or has long-term problems, the system will automatically and significantly extend the waiting period (four times, eight times, or even longer after multiple failures), thereby effectively reducing the frequency of initiating fast path consensus under suboptimal conditions and avoiding getting caught in an ineffective cycle of attempt-failure-immediate retry-failure.

[0085] In one alternative implementation, a heartbeat module and a view switching module are also included.

[0086] The heartbeat module is used to periodically send heartbeat signals from the leader to each replica node in the set of valid validators.

[0087] After any replica node is elected as the leader of the current view, the heartbeat module periodically generates heartbeat signal messages within the leader node. These heartbeat signals are essentially lightweight, special protocol messages that do not contain transaction data; their primary purpose is to announce to the network that "the leader is active." Heartbeat signals are sent at preset, relatively stable time intervals. These intervals are much shorter than the consensus timeout to ensure timely detection of leader failures. The leader continuously and periodically broadcasts these heartbeat signals to all replica nodes in the set of valid validators.

[0088] By continuously receiving heartbeat signals, replica nodes can be certain that the current consensus process is being driven by a surviving leader.

[0089] The view switching module, upon the heartbeat signal timeout, switches the current view to a new view and identifies a new leader from the set of valid validators.

[0090] At each replica node, the view switching module monitors the heartbeat signal from the leader. The view switching module sets a heartbeat timeout threshold. If no valid heartbeat signal is received locally from the current view leader within a time window exceeding the heartbeat timeout threshold, the view switching module determines that a heartbeat signal timeout event has occurred.

[0091] The first step in the switchover process is to generate a new view number. This new view number is monotonically incremented based on the current view number, thus clearly indicating that the consensus process has entered a new iteration cycle. After the switchover is triggered, all replica nodes will synchronously update their local view state to this new number.

[0092] After a new view begins, a new leader is elected to take over the consensus process. The view switching module calls or coordinates with the view initialization and leader selection module to fairly and unpredictably determine a new leader from the current set of valid validators according to a predetermined mechanism (e.g., a random selection algorithm based on a verifiable random function). The elected new leader collects state synchronization information sent by other replica nodes (e.g., the latest confirmed block or highest readiness certificate known to them), and then initiates a new block proposal based on this, thereby restarting the consensus process within the new view.

[0093] In one optional implementation, the view switching module is specifically used for: In the event of a timeout in the heartbeat signal, new view messages sent by each replica node in the set of valid verifiers are collected. The new view message carries a confirmation certificate for the highest view number stored locally by the corresponding replica node.

[0094] As mentioned earlier, when a replica node fails to receive a valid heartbeat signal from the current view leader within the expected time, the view switching module will determine that the current view leader may have failed or lost connection with the network, causing the consensus process to be unable to continue.

[0095] After determining that a view switch is needed, each replica node independently prepares and broadcasts a new view message. This message serves as the credential for a node to participate in the view switch. Its content carries the confirmation certificate with the highest view number stored locally by the replica node. Here, the confirmation certificate can be a confirmation certificate achieved through a previous fast path, or it can be a decision certificate ultimately formed by the classic three-phase process. It represents the latest blockchain state known to the replica node and recognized by the majority of the network.

[0096] The election of a new leader and subsequent operations depend on an understanding of the overall network state. Therefore, the view switching module (or in a collaborative leader election mechanism) collects these new view messages from as many replica nodes as possible from the set of valid validators.

[0097] A new leader is determined from the set of valid validators.

[0098] After successfully collecting a sufficient number of new view messages, a new leader is determined from the current set of valid validators according to a pre-defined leader selection mechanism (e.g., a fair random election algorithm incorporating a verifiable random function). This ensures that leadership is transferred fairly and randomly, prevents malicious nodes from controlling proposal rights for extended periods, and avoids predictive attacks that might arise from a fixed rotation order.

[0099] Once the new leader is determined, the confirmation certificate with the highest view number is selected from all the new view messages collected. This selection process follows the principle of "highest view number priority" because view numbers are monotonically increasing, and a higher view number indicates a closer consensus state.

[0100] The selected confirmation certificate with the highest view number will become the secure starting point and driving force for the new round of consensus. The block pointed to by the confirmation certificate is the latest stable state in the current network that has been recognized by the majority of honest nodes. Using this as a starting point ensures that newly generated blocks can be securely linked to the correct end of the chain, effectively avoiding forks and guaranteeing the consistency of state machine replication.

[0101] The new leader selects the confirmation certificate with the highest view number from the collected new view messages as the starting point to drive consensus and begin a new round of consensus.

[0102] After establishing a secure starting point, the new leader will formally take over the consensus process. Based on the confirmation certificate with the selected highest view number, the new leader will construct new block proposals. These proposals will explicitly extend from the block corresponding to that confirmation certificate, thus continuing the existing, secure blockchain history.

[0103] Subsequently, the new leader broadcasts the message containing the new block proposal to the entire network, officially initiating a new round of consensus process. At this point, the system view number has been incremented and updated, and all replica nodes will participate in a new round of voting and consensus based on the new view number and the new leader's identity, according to the protocol rules (possibly choosing the fast path or the classic path depending on the network state), allowing the blockchain generation process to resume and continue.

[0104] Figure 3 This is a schematic diagram illustrating the end-to-end interaction of the consensus algorithm in one embodiment of the present invention. Please refer to [link / reference]. Figure 3The process begins with a client submitting a transaction and generating unpredictable random numbers using a Verifiable Random Function (VRF) random source. These random numbers are then used to fairly elect a leader (or proposer) for the current view from the set of replica nodes. The elected leader encapsulates the collected transactions into a new block proposal and broadcasts it to all replica nodes, thus initiating the core consensus process. The following describes two parallel execution paths: In an ideal scenario (network synchronization and no Byzantine faults), a fast path single-round consensus is enabled, where replica nodes vote on the proposal in a single round. Once the leader collects a supermajority of valid votes, it aggregates and generates a confirmation certificate (FastQC) and broadcasts it, then directly submits the block, achieving low-latency confirmation. Simultaneously, the system continuously runs a double-signature detection mechanism, monitoring voting behavior in real time. If the same node is found to have signed different blocks at the same height (i.e., double-signature), penalty evidence is generated and the processing flow is triggered. If the fast path fails due to vote collection timeout (projection missing / inconsistency) or detection of double signature behavior, the system will automatically fall back to the more fault-tolerant classic three-stage consensus process (passing through Prepare, Pre-Commit, and Commit stages in sequence). Through multiple rounds of voting interaction, a Commit Certificate (CommitQC) is finally formed to complete the block confirmation, achieving a dynamic balance between efficiency and security in value network scenarios of high-frequency trading and cross-regional collaboration.

[0105] In this invention, the leader-driven view initialization and leader selection module ensures the randomness and unpredictability of the leader at the start of each view, laying a fair foundation for fast path consensus, avoiding malicious manipulation, and thus improving robustness in cross-regional networks. Based on this, the fast path module dynamically detects network status and enables single-round voting under fault-free synchronization conditions, optimizing consensus latency from three latency units in the classic three-phase consensus to one latency unit. Meanwhile, the double-signature detection module monitors voting records in real time, generating evidence and penalizing violating nodes upon detecting double signatures, preventing fork risks that may arise from the fast path and forming a secure closed loop. This maximizes system efficiency under ideal network conditions and maintains robustness under non-ideal environments, reducing network latency in unnecessary situations.

[0106] Figure 4 This is a schematic diagram illustrating the steps of a blockchain consensus method for value networks according to an embodiment of the present invention, as shown below. Figure 4 As shown, it includes: Step S11: At the beginning of each view, determine the leader of the current view from the set of valid validators.

[0107] At the start of each view (i.e., consensus round), a leader or consensus committee member responsible for proposing blocks is determined. Fairness in leader selection is crucial in a value network because malicious nodes that maintain control over proposal rights for an extended period could launch censorship attacks, delay critical transactions, or manipulate block content.

[0108] Step S12: Detect the network status, and if the network is synchronized and there is no Byzantine fault, the leader initiates a proposal for a new block, and submits the new block to the blockchain according to the voting results of each replica node in the set of valid validators for the proposal.

[0109] Under ideal conditions of network synchronization and no Byzantine faults, block confirmation time can be significantly reduced. In value networks, transaction throughput and confirmation latency directly impact user experience. Efficient block submission can be achieved through the following steps: Continuously monitor network latency and node behavior. When the network is determined to be in a synchronized state (i.e., message transmission latency is bounded) and no Byzantine fault is detected, enable the fast path.

[0110] The selected leader collects the transaction commands submitted by clients and encapsulates them into a new block. The new block contains transaction data, hash references to previous blocks, and other metadata, forming a complete block structure. The leader then broadcasts the new block proposal to all replica nodes.

[0111] After receiving a proposal, the replica nodes verify the legitimacy of the new block. Upon successful verification, each replica node replies with a single-round vote message, attaching a partial signature. Once the leader collects a majority (e.g., two times the fault tolerance plus one node out of a total of three times the fault tolerance plus one node) of unanimous votes, it aggregates these signatures to form a confirmation certificate. This confirmation certificate serves as proof that the block has received majority approval, triggering a fast-commit mechanism that directly appends the new block to the blockchain ledger, bypassing the traditional three-phase commit process.

[0112] Step S13: If the same replica node is detected to have signed different blocks at the same height, generate and broadcast the double-signature evidence of the replica node, and remove the replica node from the set of valid validators.

[0113] The system monitors and penalizes malicious behavior among consensus participants in real time, particularly targeting double-signature (or double-voting) behavior that could undermine the uniqueness and consistency of the blockchain. The double-signature detection and penalty module employs an automated, verifiable, and non-repudiable detection and penalty process to ensure that system security and chain stability are not compromised while pursuing high-performance, fast-path consensus.

[0114] Within each replica node of the valid validator set, the double-signature detection and penalty module maintains a dedicated local voting record ledger indexed by block height. This is a structured database whose core fields include, but are not limited to: voter identity, the cryptographic hash value of the block voted for, the partial digital signature generated during the vote, and the corresponding block height and view number.

[0115] Whenever a replica node prepares to vote on a block proposal at a certain height, or when it receives a voting message from another replica node in the network, the double-signature detection and penalty module first archives the voting information to its local voting ledger according to the block height to which it belongs. This record constitutes the basic data for determining whether a node's voting behavior is honest.

[0116] As voting information is continuously fed in, a parallel, real-time detection logic is initiated to scan for potential malicious behavior. The core of the detection logic lies in cross-referencing all voting records of the same node at the same block height. Specifically, the double-signature detection and penalty module checks whether there is an instance in the local voting ledger where a specific node identity is associated with more than one different block hash value at a specific block height.

[0117] Once a conflict is identified—that is, the same node is found to have valid signatures for at least two different blocks (e.g., block A and block B) at the same height—a double-signature violation is immediately determined. Upon detection, the double-signature detection and penalty module generates a structured double-signature evidence data packet pointing to the replica node that performed the double-signature action. It lists the hashes of all inconsistent blocks voted by that replica node at the same height, demonstrating its contradictory behavior. Simultaneously, it attaches all partial digital signatures generated by the replica node for these conflicting blocks, serving as direct cryptographic proof of its violation.

[0118] After generating the double-signature evidence, a special penalty message is constructed, encapsulating this evidence, and broadcast to the entire set of valid validators. This broadcasting action aims to expose the malicious behavior of the violating node, notify all honest nodes, and initiate the subsequent collective penalty process.

[0119] Upon receiving the broadcast double-signature evidence, honest nodes in the network independently verify its authenticity, including confirming that all signatures were indeed issued by the violating node. Because the evidence itself is verifiable, honest nodes can quickly reach a consensus on the violation. Once the double-signature evidence is verified and accepted by a majority of honest nodes, the penalty logic is automatically triggered. The core operation of this logic is to immediately and permanently remove the violating replica node from the current set of valid validators. In other words, this replica node loses its eligibility to participate in any subsequent consensus rounds (including proposals, voting, etc.), effectively preventing the malicious node from continuing to consume network resources or commit further damage, thus isolating security threats outside the system. The updated set of valid validators is synchronized throughout the network through the consensus mechanism, ensuring that all honest nodes continue to run the consensus protocol based on the updated, more secure participant list.

[0120] This invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the various processes described above in an embodiment of a blockchain consensus method for a value network, and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0121] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the processes described above in an embodiment of a blockchain consensus method for a value network, achieving the same technical effects. To avoid repetition, these processes will not be repeated here. The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to mutually.

[0122] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0123] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0124] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. A blockchain consensus system for value networks, characterized in that, include: The view initialization and leader selection module determines the leader of the current view from the set of valid validators at the beginning of each view. The fast path consensus module detects the network status and, when the network is synchronized and there is no Byzantine fault, the leader initiates a proposal for a new block and submits the new block to the blockchain based on the voting results of each replica node in the set of valid validators for the proposal. The dual-signature detection and penalty module generates and broadcasts dual-signature evidence for the same replica node when it detects that the same replica node has signed different blocks at the same height, and removes the replica node from the set of valid verifiers.

2. The system according to claim 1, characterized in that, Also includes: The rollback module determines whether there is a delay in the voting of each replica node in the set of valid validators on the proposal, and whether the double signature detection and penalty module generates double signature evidence. If there is a delay in the voting of the valid validator set on the proposal, or if the double signature detection and penalty module generates double signature evidence, the process will revert to the classic three-phase consensus process and update the failure count of the fast path consensus. The classic three-phase consensus process includes a preparation phase, a pre-commit phase, and a commit phase.

3. The system according to claim 2, characterized in that, The rollback module is specifically used for: If a timeout period is obtained and no votes for the proposal are received from a preset number of replica nodes in the set of valid validators within the timeout period, it is determined that there is a delay in the voting of the set of valid validators for the proposal. The timeout period is updated using an exponential backoff strategy based on the number of failures in the fast path consensus.

4. The system according to claim 1, characterized in that, It also includes a heartbeat module and a view switching module; The heartbeat module is used to periodically send heartbeat signals from the leader to each replica node in the set of valid validators; The view switching module, upon the heartbeat signal timeout, switches the current view to a new view and identifies a new leader from the set of valid validators.

5. The system according to claim 4, characterized in that, The view switching module is specifically used for: In the event of a timeout in the heartbeat signal, new view messages sent by each replica node in the set of valid verifiers are collected. The new view message carries a confirmation certificate for the highest view number stored locally by the corresponding replica node. A new leader is determined from the set of valid validators; The new leader selects the confirmation certificate with the highest view number from the collected new view messages as the starting point to drive consensus and begin a new round of consensus.

6. The system according to claim 1, characterized in that, The view initialization and leader selection module is specifically used for: At the beginning of each view, the hash value of the current highest quality block is combined with the current view number to obtain the input seed for a verifiable random function; Based on the input seed, the pseudo-random values ​​and corresponding proofs of correctness of each replica node in the set of valid verifiers are calculated using a verifiable random function. The replica node whose pseudo-random value is closest to the preset target value is elected as the leader of the current view.

7. The system according to claim 1, characterized in that, The fast path consensus module is specifically used for: Receive and verify the votes from each replica node for the proposal, and determine the votes that pass verification as valid votes; If valid votes are collected from more than a preset proportion of replica nodes in the set of valid validators, a confirmation certificate is generated and broadcast to each replica node in the set of valid validators. The confirmation certificate carries the corresponding view number. Based on the confirmation certificate, the new block is submitted to the blockchain.

8. A blockchain consensus method for value networks, characterized in that, include: At the start of each view, the leader of the current view is determined from the set of valid validators; The network status is detected, and if the network is synchronized and there is no Byzantine fault, the leader initiates a proposal for a new block, and submits the new block to the blockchain based on the voting results of each replica node in the set of valid validators for the proposal; If the same replica node is detected signing different blocks at the same height, double-signature evidence for that replica node is generated and broadcast, and that replica node is removed from the set of valid validators.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as claimed in claim 8.

10. A readable storage medium, characterized in that, A program or instructions are stored on the readable storage medium, which, when executed by a processor, implement the steps of the method as described in claim 8.

Images