An adaptive byzantine fault-tolerant collaboration method for lightweight heterogeneous blockchain network

Abstract

The application discloses a self-adaptive Byzantine fault-tolerant coordination method for a lightweight heterogeneous blockchain network. The method comprises the following steps: collecting the capability parameters of each node and dynamically dividing the nodes into two types of roles, i.e., full-consensus nodes and lightweight verification nodes; in the sorting stage, a master node dynamically determines the batch size according to the load of the lightweight nodes, full nodes participate in complete voting, and lightweight nodes participate in verifying block headers and signatures; in the execution stage, full nodes execute transactions to generate a state root, lightweight nodes verify the matching of the state root digest and the Merkle root, and the two types of nodes vote to confirm the execution result according to a preset weight; a cross-stage scheduler monitors the execution delay and error rate, sends a back pressure signal to the sorting stage, and dynamically adjusts the batch size and assembly interval; the capability of the nodes is periodically re-estimated, and the roles of the nodes are adjusted, and a faulty node participates again after being recovered through state synchronization. The application effectively improves the throughput and resource utilization efficiency of the lightweight heterogeneous blockchain network.

Description

Technical Field

[0001] This invention relates to the field of computer blockchain technology, and more specifically to an adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks. Background Technology

[0002] Blockchain technology ensures the consistency and immutability of ledger data maintained by each node in a distributed network through a consensus mechanism. With the rise of applications such as the Internet of Things (IoT) and edge computing, blockchain systems are gradually evolving towards lightweight and heterogeneous architectures. Network nodes now include not only high-performance servers but also a large number of terminal devices with limited computing, storage, and communication capabilities. These heterogeneous networks present new challenges to consensus protocols: they need to balance system throughput and resource utilization efficiency while tolerating Byzantine faults.

[0003] Traditional methods fall into two categories: one is the serial consensus scheme based on the Practical Byzantine Fault-Tolerant (PBFT) algorithm and its variants. This type of scheme typically employs a chained block structure, where block generation, consensus ordering, and state execution follow a strict sequence. While this design ensures data consistency, the serialized processing leads to idle system resources, and consensus latency accumulates with chain length, limiting the overall system throughput. It is particularly ill-suited to the characteristics of lightweight heterogeneous networks with significant node performance differences and frequent network fluctuations. The other category is the two-stage parallel Byzantine consensus method proposed in recent years. This method decouples the consensus process into two stages: parallel block batch ordering consensus and pipelined consensus of block execution results. It transforms serial block processing into parallel processing, thus improving system throughput to some extent.

[0004] However, existing two-stage parallel solutions still have several shortcomings when applied to lightweight heterogeneous networks: On the one hand, they were originally designed primarily for homogeneous high-performance server clusters, and their batch assembly strategies, verification processes, and pipeline scheduling mechanisms do not take into account the significant differences in computing power, storage capacity, and communication bandwidth among nodes in heterogeneous networks; on the other hand, existing solutions lack an adaptive mechanism to dynamically adjust batch size and pipeline depth based on the real-time load of nodes. When high-performance nodes and resource-constrained nodes coexist in the network, the overall system throughput is still limited by the worst-performing node, failing to truly solve the consensus efficiency problem in heterogeneous network environments.

[0005] To address the aforementioned issues, this application provides an adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks. Summary of the Invention

[0006] In view of this, the present invention provides an adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks, which solves the technical problem that existing two-stage parallel Byzantine consensus schemes fail to consider the differences in capabilities of heterogeneous nodes, resulting in resource-constrained nodes becoming performance bottlenecks and the overall system throughput being limited by the weakest node. The method realizes an adaptive consensus process based on dynamic layering of real-time node load, which significantly improves throughput and resource utilization efficiency in heterogeneous network environments while maintaining Byzantine fault-tolerant security.

[0007] The technical problem to be solved by this invention is: how to dynamically divide the roles of full consensus nodes and lightweight verification nodes in a lightweight heterogeneous blockchain network by sensing the differences in computing power, storage capacity and communication bandwidth of each node, and introduce adaptive batch assembly strategy, hierarchical verification mechanism and cross-stage collaborative scheduling in the block sorting consensus stage and the execution result pipeline consensus stage respectively, so that the two-stage consensus process can be dynamically adjusted according to the real-time load changes of the nodes, thereby eliminating the bottleneck effect in the heterogeneous network.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: An adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks includes: Node capability awareness and role classification: Construct a lightweight heterogeneous blockchain network. Each node collects its own computing, storage and network parameters and is dynamically classified into two roles: full consensus nodes and lightweight verification nodes. Adaptive batch sorting consensus: The master node dynamically determines the batch size based on the load of the lightweight verification nodes, all consensus nodes participate in the full voting, and the lightweight verification nodes participate in verifying the header and signature; Layered pipeline execution verification: Full consensus nodes execute transactions to generate state roots, lightweight verification nodes verify the matching of state root digests with Merkle roots, and full consensus nodes and lightweight verification nodes participate in weighted voting according to their respective preset weights to confirm the block execution result; Cross-stage collaborative scheduling: The scheduler accompanies the execution of the verification stage of the hierarchical pipeline, monitors the latency and error rate of this stage, and sends a backpressure signal to the adaptive batch sorting consensus stage based on the monitoring results. The backpressure signal is used to dynamically adjust the batch size and batch assembly interval of the adaptive batch sorting consensus stage. Dynamic role updates and fault recovery: Periodically reassess the operational capabilities of each node and adjust node roles. After an offline faulty node reconnects to the network, it restores the latest ledger data through status synchronization and re-participates in the node capability awareness and role allocation process during the next periodic reassessment.

[0009] Preferably, in the node capability awareness and role classification stage, a lightweight heterogeneous blockchain network is constructed. Each node collects its own capability parameters upon startup, including CPU clock speed, available memory, network bandwidth, and historical consensus response latency, and broadcasts these capability parameters to the entire network. Each node independently calculates and determines its type based on the role classification threshold, dynamically classifying it into two roles: full consensus nodes and lightweight verification nodes. Full consensus nodes are used to undertake the complete sorting and execution tasks, while lightweight verification nodes are used to participate in partial verification and signature confirmation work.

[0010] Preferably, in the adaptive batch sorting consensus phase, the master node dynamically determines the size of the block batch based on the average load of the lightweight verification nodes and the network congestion level, assembles multiple unconfirmed blocks into a batch, and then broadcasts it; the full consensus nodes perform a three-stage voting process of batch pre-notification, preparation for confirmation, and finalization submission for all blocks within the block batch; the lightweight verification nodes only verify the legality of the block header digest and signature, without caching the complete block body; when more than two-thirds of the total number of full nodes have submitted finalization messages, a global sorting consensus is reached.

[0011] Preferably, in the layered pipeline execution verification phase, the full consensus nodes execute the transactions of each block within the batch in the order determined by the global sorting consensus in claim 3, generating a complete state root and execution result summary; the lightweight verification nodes only receive and verify the matching of the state root summary with the transaction Merkle root, without executing the specific transaction logic; after each block is executed, the execution node broadcasts the execution result confirmation message, and other nodes use a weighted voting mechanism for verification, wherein the voting weight of the full consensus nodes is higher than that of the lightweight verification nodes.

[0012] Preferably, the cross-stage collaborative scheduling stage uses a collaborative scheduler to monitor the confirmation latency and error rate of the lightweight verification nodes within the hierarchical pipeline execution verification stage in real time; when at least one of the confirmation latency and error rate exceeds its corresponding performance warning threshold, the collaborative scheduler sends a backpressure signal to the adaptive batch sorting consensus stage to reduce the number of blocks in the next batch or extend the batch assembly interval; when the load of the hierarchical pipeline execution verification stage is lower than the performance warning threshold, the adaptive batch sorting consensus stage increases the block batch size to improve network throughput.

[0013] Preferably, during the dynamic role update and fault recovery phase, each node periodically reassesses its own and other nodes' capability parameters. When the computing resources of a lightweight verification node are improved or the network conditions are improved, it is upgraded to a full consensus node. When a full consensus node experiences performance degradation or frequent timeouts, it is downgraded to a lightweight verification node. When a faulty node rejoins after going offline, it restores the latest ledger from other nodes through a state synchronization protocol and re-participates in the node capability awareness and role allocation process.

[0014] As can be seen from the above technical solution, compared with the prior art, the present invention discloses an adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks, which has the following beneficial effects: 1. To address the issue that the homogeneous participation of all nodes in existing solutions leads to lightweight nodes becoming a performance bottleneck, this invention adaptively divides nodes into full consensus nodes and lightweight verification nodes through node capability awareness and dynamic role division. Lightweight nodes only verify the block header digest and state root, significantly reducing their computation and communication overhead and eliminating the bottleneck effect in heterogeneous networks.

[0015] 2. To address the issues of fixed batch size and lack of collaborative feedback between the two stages in existing solutions, this invention adopts a dynamic batch assembly strategy based on real-time load. It monitors the confirmation delay in the execution stage through a cross-stage collaborative scheduler and adaptively adjusts the batch size and rhythm of the adaptive batch sorting consensus stage using backpressure signals. This achieves a dynamic balance between the pressure of the sorting and execution stages, avoiding resource idleness or congestion.

[0016] 3. To address the issue of undifferentiated processing of nodes in the existing execution verification phase, this invention adopts a hierarchical pipeline verification and weighted voting mechanism. All nodes perform complete state transitions, while lightweight nodes only verify the state root digest. Voting weights are allocated based on the node's role, which significantly improves the overall throughput and resource utilization efficiency of heterogeneous networks while ensuring Byzantine fault tolerance and security. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0018] Figure 1 The method flowchart provided by the present invention.

[0019] Figure 2 The structural block diagram provided for this invention. Detailed Implementation

[0020] 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 embodiments of the present invention, and not all embodiments. 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.

[0021] like Figure 2 As shown, this embodiment provides a specific implementation of an adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks. The network environment applicable to the embodiment provided by this invention includes 4 high-performance full consensus nodes (such as servers) and 12 resource-constrained lightweight verification nodes (such as IoT gateway devices). The nodes communicate with each other through a TLS secure channel, the network topology is partially connected, and the maximum number of Byzantine nodes tolerated is f=1.

[0022] like Figure 1 As shown, this invention discloses an adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks, comprising: Node capability awareness and role classification: Construct a lightweight heterogeneous blockchain network. Each node collects its own computing, storage and network parameters and is dynamically classified into two roles: full consensus nodes and lightweight verification nodes. Adaptive batch sorting consensus: The master node dynamically determines the batch size based on the load of the lightweight verification nodes, all consensus nodes participate in the full voting, and the lightweight verification nodes participate in verifying the header and signature; Layered pipeline execution verification: Full consensus nodes execute transactions to generate state roots, lightweight verification nodes verify the matching of state root digests with Merkle roots, and full consensus nodes and lightweight verification nodes participate according to their respective preset weights and use weighted voting to confirm the block execution result; Cross-stage collaborative scheduling: The scheduler accompanies the execution of the verification stage of the hierarchical pipeline, monitors the latency and error rate of this stage, and sends a backpressure signal to the adaptive batch sorting consensus stage based on the monitoring results. The backpressure signal is used to dynamically adjust the batch size and batch assembly interval of the adaptive batch sorting consensus stage. Dynamic role updates and fault recovery: Periodically reassess the operational capabilities of each node and adjust node roles. After an offline faulty node reconnects to the network, it restores the latest ledger data through status synchronization and re-participates in the node capability awareness and role allocation process during the next periodic reassessment.

[0023] Specifically, in the node capability awareness and role allocation phase, a lightweight heterogeneous blockchain network is constructed. Each node, upon startup, collects its own capability parameters, including CPU frequency, available memory, network bandwidth, and historical consensus response latency, and broadcasts these parameters to the entire network. Each node (in a decentralized network, role allocation should not be determined by a single centralized entity, but rather by all nodes independently judging according to common rules or reaching consensus) independently determines its own type and the type of other nodes based on role allocation thresholds (e.g., CPU frequency weight 40%, available memory weight 30%, network bandwidth weight 20%, historical consensus response latency weight 10%), dynamically assigning two roles: full consensus nodes and lightweight verification nodes. Full consensus nodes are used to undertake complete sorting and execution tasks, while lightweight verification nodes participate in partial verification and signature confirmation work.

[0024] In one specific embodiment of the present invention, during system initialization, each node starts a capability detection thread to collect the following parameters: CPU clock speed (GHz), available memory (GB), network uplink / downlink bandwidth (Mbps), and the average response latency (ms) of the last 10 consensus messages. Each node encapsulates the capability parameters into a CapabilityReport message, attaches its node ID and digital signature, and broadcasts it to the entire network.

[0025] The role classification thresholds are as follows: nodes with CPU ≥ 2.0GHz, memory ≥ 4GB, bandwidth ≥ 50Mbps, and average latency ≤ 100ms are marked as "full consensus nodes," and the remaining nodes are marked as "lightweight verification nodes." In this embodiment, nodes A, B, C, and D meet the conditions to become full consensus nodes, and nodes E1~E12 are lightweight verification nodes. The role classification results are written to the local configuration and synchronized to all nodes.

[0026] Specifically, in the adaptive batch sorting consensus phase, the master node dynamically determines the size of the block batch based on the average load of the lightweight verification nodes and the network congestion level, assembles multiple unconfirmed blocks into a batch, and then broadcasts it. The full consensus nodes perform a three-stage voting process for all blocks within the block batch: batch pre-notification, preparation for confirmation, and finalization submission. The lightweight verification nodes only verify the validity of the block header digest and signature, without caching the complete block body. When more than two-thirds of the total number of full nodes have submitted finalization messages, a global sorting consensus is reached.

[0027] In a specific embodiment of the present invention, the master node is rotated among all consensus nodes. In this embodiment, the current master node is node A. Node A first extracts transactions to be confirmed from the transaction pool and packages them into 8 candidate blocks (Block1~Block8). Subsequently, node A broadcasts a load query message to all lightweight verification nodes to collect the current CPU utilization and the length of the message queue to be processed of each lightweight node. Based on the feedback, the average load index L_avg = 0.6 (range 0~1) is calculated, and the batch size B = max(4, min(8, floor(8)) is dynamically determined. (1-L_avg))))=4, meaning that this batch assembles 4 blocks (Block1~Block4).

[0028] Node A assembles the header digests, transaction Merkle roots, parent hashes, and timestamps of the four blocks into a BatchProposal message (i.e., "batch pre-notification") and broadcasts it to all full consensus nodes and lightweight validator nodes. Upon receiving the BatchProposal, the full consensus nodes (B, C, and D) perform a full verification of each block within the batch (transaction signatures, double-spending checks, dependencies). Once verification is successful, they generate a Prepare Confirm message (i.e., "ready to confirm") and broadcast it. Upon receiving the BatchProposal, the lightweight validator nodes only verify the validity of the block header signatures and the continuity of the batch sequence. Once verification is successful, they directly broadcast a Light Confirm message without verifying the specific transactions.

[0029] Node A collects Prepare Confirm and Light Confirm messages. According to preset rules, the confirmation message weight of a full consensus node is 2, and the confirmation message weight of a light verification node is 1. When Node A's accumulated weight reaches 2 / 3 of the total weight of all nodes (4×2=8), i.e., 6, it generates a Final Commit message (i.e., "finalize commit") broadcast. After each full node collects a Final Commit message with a weight ≥ 6, it submits Blocks 1 to 4 to the execution queue in sequence, completing the ordering consensus.

[0030] Specifically, in the layered pipeline execution verification phase, the full consensus nodes execute the transactions of each block in the batch in the order determined by the global sorting consensus, generating a complete state root and execution result digest; the lightweight verification nodes only receive and verify the matching of the state root digest with the transaction Merkle root, without executing the specific transaction logic; after each block is executed, the execution node broadcasts the execution result confirmation message, and other nodes use a weighted voting mechanism for verification, in which the voting weight of the full consensus node is higher than that of the lightweight verification node.

[0031] In one specific embodiment of the present invention, a node retrieves Block1 from the queue to be executed. All consensus nodes (A, B, C, D) execute all transactions within the block, generating a new StateRoot1 and an Execution Result Digest1, and broadcasting an Exec Confirm message. Upon receiving the Exec Confirm message, the lightweight verification node compares the received StateRoot1 with the root hash quickly calculated locally using a Merkle tree. If a match is found, it broadcasts a Light ExecAck message without executing any specific transactions.

[0032] The final confirmation of the execution result uses a weighted voting system: all nodes have a voting weight of 2, and lightweight nodes have a weight of 1. When the cumulative weight of the Exec Confirm and Light ExecAck of a block reaches 2 / 3 (i.e., 14) of the total weight (8+12=20), the execution result of that block is considered final. After Block1 is confirmed, its state root is written to the local database, and the execution of Block2 begins immediately, without waiting for the confirmation process of Block1 to be completely completed, forming a pipeline.

[0033] Specifically, the cross-stage collaborative scheduling stage uses a collaborative scheduler to monitor the confirmation latency and error rate of lightweight verification nodes in the hierarchical pipeline execution verification stage in real time. When the confirmation latency or error rate exceeds the performance warning threshold, the collaborative scheduler sends a backpressure signal to the adaptive batch sorting consensus stage to reduce the number of blocks in the next batch or extend the batch assembly interval. When the load of the hierarchical pipeline execution verification stage is lower than the performance warning threshold, the adaptive batch sorting consensus stage (sorting stage) increases the block batch size to improve network throughput.

[0034] In one specific embodiment of the present invention, the system sets up a collaborative scheduler (running on each full consensus node, maintaining state consistency through consensus). The scheduler calculates the confirmation latency of each block in real time during the execution phase. In this embodiment, when executing Block 3, the average confirmation latency of the lightweight verification node increases from 100ms to 300ms, and the error rate increases to 5%. The scheduler determines that the execution phase is congested and sends a back pressure signal to the adaptive batch sorting consensus phase, which includes a suggested batch size reduction factor α=0.5. After receiving the signal, master node A adjusts the number of blocks in the next batch from 4 to 2 and extends the batch assembly interval from 100ms to 200ms. When the execution phase latency returns to normal (below 150ms) and the error rate is below 1%, the scheduler sends a recovery signal, and the batch size gradually recovers.

[0035] Specifically, during the dynamic role update and fault recovery phase, each node periodically reassesses its own and other nodes' capability parameters. When the computing resources of a lightweight verification node are improved or the network conditions are better, it is upgraded to a full consensus node. When a full consensus node experiences performance degradation or frequent timeouts, it is downgraded to a lightweight verification node. When a faulty node rejoins after going offline, it restores the latest ledger from other nodes through a state synchronization protocol and re-participates in the node capability awareness and role allocation process.

[0036] In one specific embodiment of the present invention, after every 100 block cycles, the system triggers a role reassessment process. Each node re-reports its capability parameters. If a lightweight validator node (e.g., E1) has CPU, memory, and bandwidth all exceeding the threshold and has no timeouts for 50 consecutive cycles, it is upgraded to a full consensus node, and the role table is updated synchronously. If a full consensus node (e.g., D) experiences three consecutive voting timeouts or a response delay exceeding 500ms, it is downgraded to a lightweight validator node. When a faulty node (e.g., E3) rejoins after going offline, it obtains the state root and transaction logs of the most recent 100 blocks from other nodes through a fast state synchronization protocol. After verification, it resumes participation, and the system automatically assigns it a lightweight validator role.

[0037] As can be seen from the above embodiments, this invention dynamically divides the roles of full consensus and lightweight verification through node capability awareness, enabling lightweight nodes to verify only the block header and state root, significantly reducing their computational and communication burden; it adopts adaptive batch assembly based on real-time load to avoid the efficiency loss of fixed batches; the cross-stage cooperative scheduler adjusts the sorted batch size according to the execution delay backpressure to achieve dynamic matching of the two-stage pressure; and periodic role promotion and demotion enhance the system's robustness. This invention achieves significant improvements in heterogeneous network throughput and substantial reductions in lightweight node resource overhead while maintaining Byzantine fault tolerance security.

[0038] 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 interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0039] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks, characterized in that, include: Node capability awareness and role classification: Construct a lightweight heterogeneous blockchain network. Each node collects its own computing, storage and network parameters and is dynamically classified into two roles: full consensus nodes and lightweight verification nodes. Adaptive batch sorting consensus: The master node dynamically determines the batch size based on the load of the lightweight verification nodes, all consensus nodes participate in the full voting, and the lightweight verification nodes participate in verifying the header and signature; Layered pipeline execution verification: Full consensus nodes execute transactions to generate state roots, lightweight verification nodes verify the matching of state root digests with Merkle roots, and full consensus nodes and lightweight verification nodes participate in weighted voting according to their respective preset weights to confirm the block execution result; Cross-stage collaborative scheduling: The scheduler accompanies the execution of the verification stage of the hierarchical pipeline, monitors the latency and error rate of this stage, and sends a backpressure signal to the adaptive batch sorting consensus based on the monitoring results. The backpressure signal is used to dynamically adjust the batch size and batch assembly interval of the adaptive batch sorting consensus stage. Dynamic role updates and fault recovery: Periodically reassess the operational capabilities of each node and adjust node roles. After an offline faulty node reconnects to the network, it restores the latest ledger data through status synchronization and re-participates in the node capability awareness and role allocation process during the next periodic reassessment.

2. The adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks according to claim 1, characterized in that, In the node capability awareness and role classification phase, a lightweight heterogeneous blockchain network is constructed. Each node collects its own capability parameters upon startup, including CPU clock speed, available memory, network bandwidth, and historical consensus response latency, and broadcasts these parameters to the entire network. Each node independently calculates and determines its type based on the role classification threshold, dynamically classifying it into two roles: full consensus nodes and lightweight verification nodes. Full consensus nodes are used to undertake the complete sorting and execution tasks, while lightweight verification nodes are used to participate in partial verification and signature confirmation work.

3. The adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks according to claim 1, characterized in that, In the adaptive batch sorting consensus phase, the master node dynamically determines the size of the block batch based on the average load of the lightweight verification nodes and the network congestion level, assembling multiple unconfirmed blocks into a batch and broadcasting it. The full consensus nodes perform a three-stage voting process for all blocks within the block batch: batch pre-notification, preparation for confirmation, and finalization submission. The lightweight verification nodes only verify the validity of the block header digest and signature, without caching the complete block body. When more than two-thirds of the full nodes have submitted finalization messages, a global sorting consensus is reached.

4. The adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks according to claim 1, characterized in that, In the layered pipeline execution verification phase, the full consensus nodes execute the transactions of each block in the batch sequentially according to the order determined by the global sorting consensus in claim 3, generating a complete state root and execution result digest; the lightweight verification nodes only receive and verify the matching of the state root digest with the transaction Merkle root, without executing the specific transaction logic; after each block is executed, the execution node broadcasts the execution result confirmation message, and other nodes use a weighted voting mechanism for verification, in which the voting weight of the full consensus nodes is higher than that of the lightweight verification nodes.

5. The adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks according to claim 1, characterized in that, The cross-stage collaborative scheduling phase uses a collaborative scheduler to monitor the confirmation latency and error rate of lightweight verification nodes within the hierarchical pipeline execution verification phase in real time. When at least one of the confirmation latency and error rate exceeds its corresponding performance warning threshold, the collaborative scheduler sends a backpressure signal to the adaptive batch sorting consensus phase to reduce the number of blocks in the next batch or extend the batch assembly interval. When the load of the hierarchical pipeline execution verification phase is lower than the performance warning threshold, the adaptive batch sorting consensus phase increases the block batch size to improve network throughput.

6. The adaptive Byzantine fault-tolerant collaborative method for lightweight heterogeneous blockchain networks according to claim 1, characterized in that, During the dynamic role update and fault recovery phase, each node periodically reassesses its own and other nodes' capability parameters. When the computing resources of a lightweight verification node are improved or the network conditions are improved, it is upgraded to a full consensus node. When a full consensus node experiences performance degradation or frequent timeouts, it is downgraded to a lightweight verification node. When a faulty node rejoins after going offline, it restores the latest ledger from other nodes through the state synchronization protocol and re-participates in the node capability awareness and role assignment process.

Images